我有一个Cassandra 2.1集群，我们使用TTL通过Java插入数据，因为持久化数据的要求是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，因此我是否必须升级到更新版本才能获得任何好处？
设置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。一旦完成时间窗口的主要压缩，就不会再发生数据压缩。该过程从下一个时间窗口中写入的SSTable开始。
这对于正确选择时间窗口有很大帮助。最后一个压缩的sstable中的所有数据都具有大致相等的ttl值（提示：不要执行无序插入或手动ttl！）。 Cassandra在sstable元数据中保留最年轻的ttl值，当时间过去后，cassandra只删除整个表，因为所有数据现在都已过时。无需压实。
你是如何进行维修的？增加的？充分？死神？您的群集在节点和数据方面有多大？
快速回答是肯定的。它的实现方式是直接从磁盘中删除SStable / s。删除SStable而不需要压缩将更快地清理磁盘空间。但是您需要确保特定sstable中的所有数据都比表的全局配置TTL“更旧”。
这是你引用的段落中提到的feature。它是为Cassandra 2.0实现的，所以它应该是2.1的一部分