为何nodetool status显示的Load远小于实际磁盘占用空间？

核心差异逻辑先明确 #

nodetool status输出的Load是节点负责的原始逻辑数据量（按复制因子前的单份数据计算），而/data目录是磁盘上实际存储的所有物理文件总和，包含SSTable的全量组件、冗余数据、索引等，二者统计维度本身就不同，结合你的集群情况，具体原因可从以下几点排查：

• SSTable多组件与压缩延迟
  Cassandra的SSTable由多个文件组成：data.db（主数据）、index.db（主键索引）、filter.db（布隆过滤器）、statistics.db（统计元数据）等。Load仅统计data.db的原始数据大小，但磁盘会存储所有附加组件。如果Compaction（压缩）未及时执行，旧的SSTable文件不会被合并清理，磁盘会堆积多版本SSTable，导致物理空间远大于逻辑Load值。

• Tombstone（删除标记）堆积
  删除操作不会立即清理数据，而是写入tombstone标记，这些标记会留在SSTable中，直到Compaction结合gc_grace_seconds配置进行清理。Load不统计tombstone的大小，但磁盘会完整存储这些标记。如果gc_grace_seconds设置过长，或Compaction策略不匹配业务场景，会导致大量tombstone占用空间。

• 二级索引膨胀
  若键空间使用了二级索引，索引的index.db文件会单独存储，这部分数据不会被计入Load值。如果索引字段是高基数（如用户ID）或存在大量重复值，索引文件会迅速膨胀，成为磁盘空间占用的大头。

• 副本与逻辑量的计算差
  你的集群复制因子为2，每个数据会存2个副本。Load统计的是节点负责的原始数据量（不足100GB），但磁盘实际存储的是副本数据+SSTable附加文件，理论上磁盘量应接近Load * 2，但你的情况远超这个值，说明叠加了上述压缩延迟、tombstone、索引膨胀等问题。

• 残留文件或系统表异常
  即使重新部署集群，如果未彻底清理旧磁盘数据，可能残留之前的临时文件、未清理的SSTable碎片；另外系统表（如system_distributed、system_auth）若异常写入大量数据，也会占用额外空间。

• 执行tablestats命令查看单表细节：nodetool tablestats <keyspace>.<table>，重点看SSTable数量、tombstone占比、压缩完成状态。
• 检查键空间压缩策略：若为写密集型业务，LeveledCompactionStrategy比默认的SizeTieredCompactionStrategy更能减少SSTable堆积。
• 评估二级索引必要性：执行DESCRIBE INDEX <index_name>查看索引配置，若非必需可删除索引释放空间。
• 调整tombstone清理配置：若业务不需要长周期保留删除标记，可调小gc_grace_seconds，再手动触发Compaction：nodetool compact <keyspace>.<table>。
• 磁盘文件明细排查：执行du -sh /data/<keyspace>/<table>/*，定位是index.db、data.db还是其他文件占用主要空间。

内容的提问来源于stack exchange，提问作者Jayesh Popat