ByConity项目中系统表cnch_parts的bytes_on_disk字段异常问题分析

在分布式数据库系统ByConity的使用过程中，用户发现系统表system.cnch_parts中的bytes_on_disk字段存在异常现象：对于包含约2000万行数据的表分区，该字段仅显示730字节，这显然与实际情况不符。本文将从技术角度深入分析这一现象背后的原因。

问题现象

用户在执行查询时发现，system.cnch_parts表中某些分区的bytes_on_disk字段值异常偏小。具体表现为：

• rows_count字段显示约2362万行数据
• bytes_on_disk字段仅显示730字节
• 该分区包含多个不同版本的数据部分(part)

技术背景

在ByConity中，数据存储采用多版本机制，一个逻辑数据部分(logical data part)可能由多个物理数据部分(physical data part)组成。这些物理部分形成一个部分链(part chain)，其中只有最顶层的部分对用户可见。这种设计使得数据修改操作可以通过创建增量部分(delta part)来实现，而不需要直接修改原始数据。

问题原因分析

通过深入分析系统表中的数据，我们发现：

1. 每个分区实际上包含多个数据部分版本，形成一个版本链
2. 最新版本(visible=1)的bytes_on_disk确实显示为730字节
3. 但该分区还包含多个历史版本(visible=0)，它们的bytes_on_disk值从466790字节到1186021093字节不等
4. 730字节的最新版本实际上是一个增量修改部分，只包含变更数据

解决方案

要获取准确的磁盘占用情况，不应仅查询visible=1的记录，而应该：

1. 按分区进行分组统计
2. 汇总所有版本(包括可见和不可见)的bytes_on_disk值
3. 使用类似以下SQL查询获取真实磁盘占用：

SELECT partition, sum(bytes_on_disk)
FROM system.cnch_parts
WHERE (table = '表名') AND (database = '数据库名')
GROUP BY partition

最佳实践建议

1. 理解ByConity的多版本存储机制
2. 进行存储空间分析时考虑所有数据版本
3. 定期清理不再需要的历史版本数据
4. 对于重要操作(如ALTER TABLE)，注意可能产生的增量部分

总结

这个案例展示了理解分布式数据库底层存储机制的重要性。ByConity通过多版本机制实现高效的数据修改操作，但这要求用户在分析存储情况时采用正确的查询方式。系统表显示的单个版本数据大小可能不能反映实际磁盘占用，需要综合考虑版本链中的所有部分。