我有几个 Cassandra 表，上面不断运行逻辑删除压缩，我相信这是 Cassandra 进程 CPU 使用率高的原因。
我的设置包括:
compaction = {'tombstone_threshold': '0.01',
'tombstone_compaction_interval': '1', 'class':
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
default_time_to_live = 1728000
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
在其中一个表中，我每分钟都会向其中写入数据。由于设置了 TTL，整组行也会每分钟过期。
持续压缩是否是由于 tombstone_threshold 和 tombstone_compaction_interval 较低所致？
有人可以详细解释一下tombstone_threshold和tombstone_compaction_interval吗？ Cassandra文档没有解释得太清楚。
最佳答案
因此，假设 SSTable 的历史至少与压缩间隔一样长，墓碑压缩就可以触发。 SStable 是在事物被压缩时创建的。阈值是在仅针对墓碑进行压缩而不是加入 sstable 之前，sstable 中有多少是墓碑。
您正在使用 leveled，并且看起来有 20 天的 ttl。为了跟上，您将进行大量的压缩和墓碑压缩。 Leveled 将是确保旧的墓碑不会占用默认压缩器的磁盘空间的最佳方法。
如果此数据是时间序列(听起来像是这样)，您可能需要考虑使用 TWCS反而。这将创建“存储桶”，一旦压缩，每个“存储桶”都是一个 sstable，因此一旦该表中数据的 ttl 过期，压缩器就可以删除整个 sstable，从而效率更高。
TWCS 作为 jar 提供，您需要将其添加到 2.1 的类路径中，我们目前在生产中使用它。它也已添加到 Cassandra 3.x 系列中。
关于Cassandra 表的常量墓碑压缩，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/39796682/