Scylla/Cassandra设置大默认TTL处理18个月过期记录是否可取？

针对你的业务场景（18个月后删除记录，每日新增200万条），直接设置default_time_to_live = 47304000（对应18个月左右）是完全没问题的，但需要关注以下几个关键点：

• TTL数值合法性：Cassandra和Scylla的TTL最大值受限于32位时间戳（截止到2038年），18个月远低于这个上限，所以你设置的数值在系统允许范围内。
• 墓碑管理压力：记录过期后会生成墓碑（tombstone），每日200万条的规模下，大量墓碑堆积可能影响查询性能和压缩效率。建议：
  • 选择合适的压缩策略，比如Leveled Compaction（适合读多写少或需要稳定读性能的场景），或者Size-Tiered Compaction配合合理的压缩阈值；
  • 合理设置gc_grace_seconds：这个参数控制墓碑被彻底清理前的保留时间，建议根据集群故障恢复的最长时间来设定（比如7天），既避免节点恢复后丢失删除记录，又防止墓碑长期堆积。
• 写入性能影响：设置default_time_to_live不会对写入性能造成明显影响——TTL是随记录一起写入的元数据，额外开销可以忽略，每日200万条的写入量在Cassandra/Scylla的承载范围内。
• 数据分布与热点：如果pet_chip_id是均匀生成的UUID，数据会均匀分散在集群节点上，过期清理的压力会被分摊到各个节点；如果pet_chip_id存在热点（比如某些ID的写入频率极高），则热点节点在记录过期时会承担更大的清理压力，需要提前优化主键设计或调整集群分片策略。

另外补充一个小建议：你的示例表主键仅为pet_chip_id，这意味着每个宠物只能存储一条心率记录，后续写入会直接覆盖旧数据。如果业务需要存储宠物的多条历史心率记录，建议把时间戳加入主键，比如：

CREATE TABLE heartrate_ttl (
    pet_chip_id  uuid,
    record_time timestamp,
    name text,
    heart_rate int,
    PRIMARY KEY (pet_chip_id, record_time))
WITH default_time_to_live = 47304000;

这样每条心率记录都会独立存储，且到期后自动删除，更符合实际业务需求。

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