Cassandra执行nodetool compact后存储空间增大的原因咨询

问题场景 #

在Cassandra 3.11.6中执行三次nodetool compact操作后，存储空间均出现增大现象，统计数据如下：

Start Finish Size before COMPACT (mb) Size after COMPACT (mb)
16.06.2023 21:00:06 17.06.2023 00:53:56 1 381 270   1 605 130
17.06.2023 00:53:57 17.06.2023 04:47:46 1 381 250   1 589 390
17.06.2023 04:47:46 17.06.2023 08:41:38 1 381 290   1 597 210

存储空间统计使用命令：

nodetool cfstats | grep 'Space used (total)' | awk -F ": " '{s+=$2}END{print s/1000000}'

核心原因分析 #

• 原有SSTable压缩率更高：若原有SSTable已采用高压缩比算法（如LZ4、Snappy），手动触发compact合并多个小SSTable时，新生成的大SSTable压缩效率可能下降——小文件的压缩字典针对性更强，合并后大文件的数据分布更复杂，压缩比降低导致体积增大。
• 未过期墓碑被合并保留：Cassandra的删除操作仅生成墓碑标记，若compact执行时墓碑的GC grace period尚未到期，所有未过期墓碑会被合并到新SSTable中。如果之前多个小SSTable存在大量重复或未清理的墓碑，合并后集中存储会额外占用空间。
• 大SSTable的索引开销更高：合并多个小SSTable为单个大文件时，新文件的分区索引、行索引等元数据总开销会超过原有多个小文件的索引总和。尤其当数据分区键分布零散时，大SSTable的索引体积会显著增加，推高整体存储空间。
• 临时文件与统计时机偏差：compact执行过程中会生成临时SSTable，旧SSTable需等新文件完全写入后才会被标记删除。若统计命令在旧文件未被文件系统彻底清理（如ext4的延迟删除机制）时执行，会统计到新旧文件共存的体积。不过从三次操作前的体积一致性来看，该可能性较低，可检查数据目录确认旧SSTable是否已删除。
• 重复数据合并的额外开销：若原有多个SSTable存在同一分区的重复数据，compact会合并为最新版本，但合并时会保留时间戳、状态标记等额外信息，若这些开销加合并后数据的体积超过原有多个压缩小文件的总大小，就会出现空间增大。

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