在历史上，我们一直使用stc作为cassandra表的压缩策略，这导致了太多的墓碑。由于表中的数据是仅附加的，并且使用了30天的ttl（没有手动更新或删除），我们使用 compaction_window_size 一天之内。这导致高cpu使用率和livesstablecount，以及来自集群的高读取延迟。
下面是 Jmeter 板快照。
战略变化与图表中的变化一致。



从STC切换到TWC时是否会出现这种情况？我们可以调整这里的参数以确保这不会影响集群的读取吗？
表架构的更多详细信息。

CREATE TABLE Foo (
user_uuid uuid,
ts bigint,
... //skipped a few columns
PRIMARY KEY (user_uuid, ts, event_uuid)
) WITH CLUSTERING ORDER BY (ts DESC, event_uuid ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class': 'org.apache.cassandra.db.compaction.TimeWindowCompactionStrategy', 'compaction_window_size': '24', 'compaction_window_unit': 'HOURS', 'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 2592000
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
AND speculative_retry = '99PERCENTILE';