Cassandra分区全删重插场景下的压缩策略选型及磁盘空间预留建议

你的场景是分区全量删除后重新写入，属于批量一次性写入+旧数据快速淘汰的模式，默认的SizeTieredCompactionStrategy (STCS)并不适配，推荐使用TimeWindowCompactionStrategy (TWCS)，理由如下：

• TWCS专为时间序列、批量写入场景设计，会按时间窗口将新写入的数据分组为独立SSTable，窗口关闭后自动完成一次合并。对于你这种全量替换分区的操作，新数据会在单个窗口内形成完整的SSTable，旧分区数据被删除后，合并操作不会产生大量冗余数据，IO开销更低。
• STCS的问题在于，它会持续将小SSTable合并为大SSTable，在旧数据未完全清理时，新写入的小SSTable会和旧的大SSTable合并，生成大量临时数据，既浪费磁盘空间也拖慢写入速度。
• 若你的业务对查询延迟要求极高，也可以考虑LeveledCompactionStrategy (LCS)，但LCS合并开销远高于TWCS，仅适合需要频繁小范围查询的场景，对你的批量替换场景来说性价比很低。

磁盘空间预留需结合场景核心因素确定：

• 基础重叠空间：删除旧数据与写入新数据的阶段可能存在重叠，此时磁盘会同时存储旧分区全量数据和新写入数据，因此至少需要预留单分区全量数据的2倍空间。
• 合并临时空间：使用TWCS时，窗口合并所需临时空间约为当前窗口数据量的1倍；若仍用STCS，合并临时空间可能达到总数据量的1.5-2倍。结合你的场景，用TWCS的话，总预留空间建议为单分区全量数据的2.5-3倍。
• 冗余缓冲：考虑磁盘碎片、commit log临时占用等情况，额外预留10%-20%的冗余空间，避免磁盘满导致写入中断。

举个实例：若单分区全量数据为100GB，预留300GB-350GB磁盘空间是安全的选择。

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