我对所有插入的行使用LCS和2年的相对较大的TTL，并且我担心在C *时刻会掉下相应的逻辑删除（既不执行显式删除也不进行更新）。
根据Missing Manual for Leveled Compaction Strategy，Tombstone Compactions in Cassandra和Deletes Without Tombstones or TTLs我了解
因此，对于我的特定用例（2年TTL和写入重负载），我可以得出结论：TTL数据将处于最高级别，因此我想知道何时将那些包含TTL数据的SSTable压缩为包含以下内容的SSTable：对应的SSTables。
主要问题将是：在哪里创建了墓碑（来自ttls）？是在0级创建的，所以要花很长时间才能最终达到最高级别（因此磁盘空间需要很长时间才能被释放）？
在About deletes and tombstones阿兰的评论中，
但是使用TTL还是有帮助的，它减少了SSTables之间的数据碎片化的可能性，而这些数据很快就不会被压缩在一起。使用任何压缩策略，如果删除发生在行历史中相对较晚（通常发生），则逻辑删除的“ upsert” /“ insert”将进入新的SSTable。该墓碑可能需要一些时间才能到达正确的压实“桶”（与该行的其余部分一起），而Cassandra最终能够释放空间。
我的理解是，使用TTL可以创建墓碑，因此摆脱TTL的原因通常比许多原因更容易，更安全，这比从删除操作更安全。
探索的另一个线索是，如果合适的话，可以使用TTL作为默认值。在表级别使用“ default_time_to_live”设置的TTL在C * 3.0 +中完全不会生成任何逻辑删除。没有经过我的测试，但是我读到了这件事。
我不确定“就地”的含义，因为SSTable是不可变的。
（我对在How default_time_to_live would delete rows without tombstones in Cassandra?中提出的使用default_time_to_live表示的看法也有疑问。）
我的猜测是，它是指与压缩过程中由以下原因之一触发的TTLed数据处于同一级别（但SStable不同）创建的逻辑删除：
因此，压缩（2）和（3）应该在最高级别创建/删除逻辑删除，因此使用具有大TTL的LCS本身并不是问题。
所谓创建/删除，是指同一种压缩将为过期数据创建逻辑删除和/或如果gc时期已经过去，则删除逻辑删除。
一个澄清这种情况的源代码链接将非常有用。
答案 0 :(得分：0)
Alain Rodriguez从mailing list的答案
要探索的另一个线索是，如果出现以下情况，则将TTL用作默认值 很合适在表级别使用“ default_time_to_live”设置的TTL 在C * 3.0 +中完全不应该生成任何逻辑删除。没有经过我的测试 但是我读到了这个。
如parallel thread所述，这是错误的，是罪魁祸首。我相信我的其余评论仍然有效（希望：））。
我不确定“就地”的含义，因为SSTables是不可变的。 我的猜测是指在相同的地方创建墓碑
是的，我相信在到期日之后的下一次压缩中， 该条目被“转换”为墓碑，并存在于SSTable中， 是压缩的结果，放在此SSTable的级别/存储桶上 入。这就是为什么我说“就地”的原因，这确实有点奇怪 不变的数据。
作为您问题的一个附带想法，在“现代”版本的Cassandra上（我不会 记住版本，这就是“现代”的意思;-)），您可以运行 在执行期间定期（不一定要经常）进行'nodetool垃圾收集' 非高峰期。不需要时可能会使用群集资源 他们要求一些磁盘空间。同时确保2年的记录 不定期进行设计更新肯定会有所帮助。在里面 一次写入数据（从未更新）并且使用TTL的极端情况 例如，我认为没有理由不删除2年的数据 正确地。只要磁盘可以增长，就可以了。
我不会对此太担心，因为有一种“永远”的方法 删除墓碑。但是事先考虑一下设计是一件好事 实际上，通常来说，如果您可以随着时间的推移旋转分区，那是很好的， 例如，不要重用旧分区。
