我有一个Cassandra 2.1集群，我们通过Java使用TTL插入数据，因为持久化数据的要求是30天。 但这会导致问题，因为带有墓碑的旧数据的文件保留在磁盘上。这导致磁盘空间被不需要的数据占用。修复需要花费大量时间来清除这些数据（单个节点上最多3天） 有没有更好的方法来删除数据？
我在datastax上遇到过这个问题
Cassandra允许您为整个表设置default_time_to_live属性。标有常规TTL的列和行如上所述进行处理;但是当记录超过表级TTL时，Cassandra会立即删除它，而不会进行墓碑或压缩。 https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlAboutDeletes.html?hl=tombstone
如果我在表级设置TTL而不是在插入时每次设置，那么数据是否会被更有效地删除。 此外，文档适用于Cassandra 3，因此我是否需要升级到更新版本以获得任何好处？
答案 0 :(得分：3)
设置default_time_to_live将默认ttl应用于表中的所有行和列 - 如果没有设置单独的ttl（并且cassandra在所有节点上都有正确的ntp时间），cassandra可以轻松地安全地删除这些数据。
但请记住一些事项：您的应用程序仍然能够为表中的单行设置特定的ttl - 然后将应用正常处理。最重要的是，即使数据被清除，它也不会立即被删除 - sstables仍然是不可变的，但是在压缩过程中会丢弃墓碑。
什么可以帮助你真正很多 - 只是猜测 - 将是一个适当的压缩策略：
TimeWindowCompactionStrategy（TWCS） 推荐用于时间序列和即将到期的TTL工作负载。
TimeWindowCompactionStrategy（TWCS）与DTCS类似 更简单的设置。 TWCS使用一系列时间窗口对SSTable进行分组。 在压缩过程中，TWCS将STCS应用于未压缩的SSTable中 最近的时间窗口。在时间窗口结束时，TWCS压缩 落入该时间窗口的所有SSTable都成为单个SSTable 基于SSTable最大时间戳。一旦主要压实为 时间窗口完成，数据不再进一步压缩 永远发生。该过程从使用SSTables编写的过程重新开始 下一次窗口。
这对于正确选择时间窗口有很大帮助。最后一个压缩的sstable中的所有数据都具有大致相等的ttl值（提示：不要执行无序插入或手动ttl！）。 Cassandra在sstable元数据中保留最年轻的ttl值，当时间过去后，cassandra只删除整个表，因为所有数据现在都已过时。无需压实。
你如何进行维修？增加的？充分？死神？节点和数据在群集方面有多大？
答案 1 :(得分：0)
快速回答是肯定的。它的实现方式是直接从磁盘中删除SStable / s。删除SStable而不需要压缩将更快地清理磁盘空间。但是你需要确保特定sstable中的所有数据都比表的全局配置TTL“更旧”。
这是您引用的段落中提到的feature。它是为Cassandra 2.0实现的，所以它应该是2.1
的一部分