Cassandra从STCS切换到TWCS后CPU及LiveSSTableCount异常升高的调优咨询

先给你吃个定心丸：切换到TWCS后出现的短期CPU飙升、LiveSSTableCount升高和读延迟增加，完全是正常的过渡期现象，但如果长期维持这个状态，就需要调整参数来优化了。

为什么会出现这些性能波动？ #

• 初始compaction洗牌：TWCS是按时间窗口管理SSTables的，而之前STCS生成的SSTables是跨时间窗口的（不同日期的数据混在一起）。切换策略后，Cassandra会启动大量compaction任务，把历史SSTables拆分到对应的1天窗口里——这个过程会占用大量CPU和IO资源，直接导致CPU使用率飙升。
• LiveSSTableCount临时暴涨：compaction过程中，旧的跨窗口SSTables还没被清理，新的窗口化SSTables已经生成，所以活跃SSTable数量会暂时增加。而Cassandra读数据时需要扫描所有相关的SSTables，数量越多，读延迟自然越高。
• 好在你的场景是纯追加写入+TTL30天，等所有历史数据都整理到对应时间窗口后，这些临时性能问题会逐渐缓解，TWCS的优势也会体现出来：后续每天的数据只会在当天窗口内合并，到期后直接删除整个窗口的SSTables，从根源上减少墓碑问题。

怎么调整参数避免影响集群读取性能？ #

结合你的表结构（纯追加、TTL30天、按ts倒序的分区键），给你几个针对性的参数调整建议：

1. 控制compaction资源占用，减少对业务的冲击 #

• 限制compaction吞吐量：修改compaction_throughput_mb_per_sec参数（默认是16），适当调低到8或4（根据集群IO能力调整）。这个参数控制compaction每秒处理的数据量，调低后可以避免compaction占用过多CPU和IO，给读操作留出资源。
• 调整窗口内的compaction阈值：当前你的min_threshold:4、max_threshold:32，可以改成min_threshold:2、max_threshold:16。因为你的数据是纯追加，每天的SSTables主要来自memtable flush，数量不会太多，降低阈值可以让同窗口内的SSTables更早合并，减少每个窗口的SSTable数量，从而降低读操作需要扫描的SSTables数量。

2. 优化TTL相关参数，配合TWCS特性 #

• 降低过期SSTable检查频率：设置expired_sstable_check_interval_seconds: 3600（默认是60）。因为你的TTL是30天，不需要每分钟检查SSTables是否过期，改成每小时检查一次可以减少不必要的后台开销。
• 启用过期SSTable直接删除：确保unchecked_tombstone_compaction: true（Cassandra 3.10+支持）。当某个时间窗口的所有数据都过期后，TWCS可以直接删除整个SSTable，不需要做compaction，进一步减少资源消耗。

3. 针对读性能的专项优化 #

• 调整缓存策略：当前你的caching: {'keys': 'ALL', 'rows_per_partition': 'NONE'}，可以把rows_per_partition改成'100'（或根据业务常用的最新行数调整）。因为你的数据是按ts倒序存储，用户大概率经常读取每个用户的最新事件，缓存这些最新行可以大大减少磁盘读取次数，降低读延迟。
• 调整投机重试策略：把speculative_retry: '99PERCENTILE'改成'NONE'或'50PERCENTILE'。过高的重试阈值会导致高延迟时触发大量重试，反而增加集群负载，适当调低可以减少不必要的重试开销。

4. 过渡期的临时应对措施 #

• 如果当前业务受影响严重，可以暂时把compaction_throughput_mb_per_sec调到很低（比如2），优先保证业务读性能，等pending_compactions指标降到0（初始整理完成）后再调回合适的值。
• 密切监控compaction_progress、live_sstable_count和read_latency指标，当这些指标稳定下来，就说明TWCS已经进入正常运行状态了。

长期收益 #

等过渡期结束后，TWCS会比STCS更适合你的场景：它会自动按天合并SSTables，避免跨时间的数据混在一起，而且当数据到期后直接删除整个窗口的SSTables，彻底解决STCS带来的墓碑过多问题，长期来看读性能会更稳定。

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