Cassandra配置TTL后数据未整行删除仅留空值问题咨询

你对Cassandra TTL特性的认知存在偏差，该现象是Cassandra存储引擎的设计导致的，属于预期行为：

• Cassandra的TTL属性仅作用于非主键列，所有组成主键的字段（分区键、聚类键）本身不存储TTL元数据，不会随TTL到期被标记删除。
• 你配置的default_time_to_live = 2628000只会给写入时的非主键字段默认设置1个月TTL，到期后这些非主键字段会被标记为逻辑删除的墓碑，查询时直接返回null；而主键因为没有TTL标记，会持续存在直到整行数据被compaction（压缩）流程物理清理。
• Cassandra的删除是异步流程：非主键字段全过期的行不会被立刻物理删除，需要等待gc_grace_seconds（默认10天）的墓碑同步周期结束后，在后续compaction过程中才会被整行清理。如果表使用默认的SizeTieredCompactionStrategy压缩策略，且对应SSTable文件长期不满足compaction触发条件，这种“主键残留、其他列全为null”的行骨架会存在很长时间。

你的建表语句中TTL相关配置不存在语法错误，配置是正常生效的，问题本质是TTL默认机制和你的“整行彻底删除”预期不匹配，而非配置写错。

根据你的1个月固定TTL、无长期留存数据的业务场景，推荐按优先级选择以下方案：

• 方案1：调整压缩策略适配TTL场景
  将表的压缩策略修改为TimeWindowCompactionStrategy（TWCS），配置时间窗口大小与TTL匹配（即1个月），同时将gc_grace_seconds调整为259200（3天，适合同批次写入无更新的场景，无需保留默认10天的墓碑同步周期）。TWCS会将同一时间窗口内写入的数据合并为独立的SSTable文件，当窗口内数据全部超过TTL后，会直接整块删除整个SSTable文件，不会残留行骨架，清理效率远高于默认压缩策略，对集群压力最小，是固定TTL时序类数据的官方推荐方案。
  注意：该方案要求窗口内写入的数据不会被更新、删除，否则可能出现数据复活问题，和你的短期合同存储场景完全适配。
• 方案2：按时间分桶建表，物理删表
  按月份（或周/天，根据数据量选择）创建分表，例如contract_202405存2024年5月的合同、contract_202406存2024年6月的合同，业务侧写入、查询时根据合同时间路由到对应分表。配置定时任务在分表数据满1个月留存期后，直接执行DROP TABLE命令删除整表。该方案可以做到100%无残留删除，没有墓碑开销，性能最高，缺点是需要业务侧增加分表路由逻辑，运维侧加定时删表任务。
• 方案3：业务侧定时任务删除
  开发定时任务每日扫描到期的合同主键，批量发起整行DELETE操作。该方案仅适合数据量较小的场景，缺点是会产生大量墓碑，大幅增加compaction压力，删除速率控制不好容易影响集群正常读写，不推荐大数据量场景使用。

补充说明：Cassandra语法层面不支持为主键列设置TTL，不存在通过TTL直接让主键自动到期的配置方式。

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