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

Question

我有一个Cassandra 2.1集群，我们在其中通过带有TTL的Java插入数据，因为持久存储数据的要求是30天。 但这会导致问题，因为具有逻辑删除的具有旧数据的文件将保留在磁盘上。 这导致磁盘空间被不需要的数据占用。 维修需要大量时间来清除此数据（在单个节点上最多需要3天），是否有更好的方法来删除数据？

我在datastax上遇到了这个

Cassandra允许您为整个表设置default_time_to_live属性。 标记有常规TTL的列和行如上所述进行处理； 但是当记录超过表级TTL时，Cassandra会立即删除它，而不会导致逻辑删除或压缩。 https://docs.datastax.com/zh-CN/cassandra/3.0/cassandra/dml/dmlAboutDeletes.html?hl=tombstone

如果我在表级别设置TTL，而不是每次插入时都进行设置，会更有效地删除数据。 此外，文档是针对Cassandra 3的，因此我是否必须升级到较新版本才能获得任何好处？

Answer 1

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

但请记住以下几点：您的应用程序仍然能够为表中的单行设置特定的ttl-然后将应用常规处理。 最重要的是，即使数据不可靠，它也不会立即被删除-sstable仍然是不变的，但是在压缩过程中，逻辑删除将被删除。

可以猜测的是，实际上可以真正帮助您的是一种适当的压缩策略：

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

TimeWindowCompactionStrategy（TWCS）建议用于时间序列和TTL工作负载过期。

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

这很有帮助-正确选择时间窗口时。 最后一个压缩的sstable中的所有数据将具有大致相等的ttl值（提示：请勿乱序插入或手动进行ttls！）。 Cassandra将最年轻的ttl值保留在sstable元数据中，并且在这段时间过后，cassandra会删除整个表，因为现在所有数据都已过时。 无需压实。

您如何进行维修？ 增加的？ 充分？ 收割吗 您的集群在节点和数据方面有多大？

Answer 2

快速答案是肯定的。 它的实现方式是直接从磁盘上删除SStable。 无需压缩即可删除SStable将更快地清理磁盘空间。 但是，您需要确保特定sstable中的所有数据都比该表的全局配置TTL“旧”。

这是您引用的段落中提到的功能 。 它是为Cassandra 2.0实现的，因此应该成为2.1的一部分