Cassandra - 表中的 TTL 和使用 TTL 插入数据有什么区别

Question

我有一个 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，所以我是否必须升级到新版本才能获得任何好处？

Answer 1

设置default_time_to_live将默认 ttl 应用于表中的所有行和列 - 如果没有设置单独的 ttl（并且 cassandra 在所有节点上都有正确的 ntp 时间），cassandra 可以轻松安全地删除这些数据。

但请记住一些事情：您的应用程序仍然能够为表中的单行设置特定的 ttl - 然后将应用正常处理。最重要的是，即使数据被告知，它也不会立即被删除——稳定表仍然是不可变的，但逻辑删除会在压缩过程中被删除。

什么可以真正帮助你 - 只是猜测 - 将是一个适当的压缩策略：

http://docs.datastax.com/en/archived/cassandra/3.x/cassandra/dml/dmlHowDataMaintain.html#dmlHowDataMaintain__twcs-compaction

TimeWindowCompactionStrategy (TWCS) 建议用于时间序列和到期 TTL 工作负载。

TimeWindowCompactionStrategy (TWCS) 与 DTCS 类似，但设置更简单。TWCS 使用一系列时间窗口对 SSTable 进行分组。在压缩过程中，TWCS 将 STCS 应用于最近时间窗口中未压缩的 SSTable。在时间窗口结束时，TWCS 根据 SSTable 最大时间戳将落入该时间窗口的所有 SSTable 压缩为单个 SSTable。一旦时间窗口的主要压缩完成，就不会再发生数据的进一步压缩。该过程从下一个时间窗口中写入的 SSTable 重新开始。

这对正确选择时间窗口有很大帮助。最后压缩的 sstable 中的所有数据将具有大致相等的 ttl 值（提示：不要执行无序插入或手动 ttl！）。Cassandra 将最新的 ttl 值保留在 sstable 元数据中，当该时间过去后，cassandra 会简单地删除整个表，因为所有数据现在都已过时。无需压实。

您如何进行维修？增加的？满的？收割者？您的集群的节点和数据有多大？