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

【问题标题】：Cassandra - What is difference between TTL at table and inserting data with TTLCassandra - 表中的 TTL 和使用 TTL 插入数据有什么区别
【发布时间】：2018-06-08 20:26:06
【问题描述】：

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

【问题讨论】：

修复不会删除数据，不应该真正进入 TTL 讨论。

标签： cassandra cassandra-3.0 cassandra-2.1

【解决方案1】：

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

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

真正对你有很大帮助的——只是猜测——将是一个合适的压缩策略：

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 应用于未压缩的 SSTables 最近的时间窗口。在时间窗口结束时，TWCS 压缩落入该时间窗口的所有 SSTables 进入单个 SSTable 基于 SSTable 最大时间戳。一旦主要压实一个时间窗口完成后，不会进一步压缩数据曾经发生过。该过程从编写的 SSTables 重新开始下一个时间窗口。

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

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

【讨论】：

只有一个应用程序将数据写入集群，因此如果 TTL 设置在表级别并且提供任何改进，我们可以禁用单个 TTL。我们在 transactionId 是主键的地方插入数据（每个键可以有大约 100 行，跨越大约一周）。因此，如果任何行超过 30 天，我们可以删除该行。我们使用 LeveledCompactionStrategy 进行压缩，切换到 TimeWindowCompactionStrategy 会有帮助吗？我们以增量方式修复。但最近 cron 作业出现了一些问题，因此正在对一些节点进行全面修复。
TWCS 可以帮助您解决问题 - 它通常非常适合将按顺序处理和插入的数据。我可能会建议一个一周的时间窗口，因此 35 天后 sstables 中的旧数据将消失。在一周内，comments 是按大小分层的，并且在时间窗口结束时有一个主要的 compation - 查看 sstable 的数量和您的阅读模式。如需维修，请查看：cassandra-reaper.io/docs/download/install

【解决方案2】：

答案是肯定的。它的实现方式是直接从磁盘中删除 SStable/s。在不需要压缩的情况下删除 SStable 将更快地清理磁盘空间。但是您需要确保特定 sstable 中的所有数据都比表的全局配置 TTL“旧”。

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

【讨论】：