cassandra - Cassandra 的墓碑

Question

我有一个 TTL 为 60 秒的 Cassandra 表，我对此几乎没有疑问，

1)我收到以下警告

Read 76 live rows and 1324 tombstone cells for query SELECT * FROM xx.yy WHERE token(y) >= token(fc872571-1253-45a1-ada3-d6f5a96668e8) LIMIT 100 (see tombstone_warn_threshold)

这是什么意思？

2)根据我的研究，Tombstone是TTL情况下的标志(将在gc_grace_seconds后删除)
i) 所以直到 10 天这是否意味着它不会被删除？
ii) 等待 10 天会有什么后果？
iii) 为什么是很长的时间 10 天？

https://docs.datastax.com/en/cql/3.1/cql/cql_reference/tabProp.html

gc_grace_seconds 864000 [10 天] 数据被标记为墓碑(删除标记)后，在符合垃圾收集条件之前的秒数。 Cassandra 不会在其 gc_grace_period 内对墓碑记录执行提示或批量突变。默认值允许 Cassandra 在删除之前有大量时间来最大化一致性。有关减小此值的详细信息，请参阅下面的垃圾收集。

3)我读到使用 nodetool 执行压缩和修复会删除墓碑，我们需要在后台多长时间运行一次，它会产生什么后果？

Answer 1

这意味着您的查询返回了 76 行“事件”或未删除/未废弃的数据行，并且必须筛选 1324 个墓碑(删除标记)才能完成此操作。

在分布式数据库的世界里，删除是很困难的。毕竟，如果您从一个节点删除了一段数据，并且您希望该删除发生在您的所有节点上，您怎么知道它是否有效？从字面上看，您如何不复制任何内容？墓碑(删除标记)是该问题的答案。

一世。数据消失了(而是已过时)。墓碑将保留 gc_grace_seconds .

ii. “后果”是您必须在这段时间内忍受这些逻辑删除警告消息，或者找到一种无需扫描逻辑删除即可运行查询的方法。

三、 10 天背后的想法是，如果太早收集墓碑，您删除的数据将“幻影”返回到某些节点。 10 天让您有足够的时间进行每周一次的维修，以确保您的墓碑在移除前得到正确复制。

压实移除墓碑。修复复制它们。您应该每周运行一次维修。虽然您可以按需运行压缩，不要 . Cassandra 有自己的阈值(基于 SSTable 文件的数量和大小)来确定何时运行压缩，最好不要妨碍它。如果这样做，您将从那里开始手动运行压实，因为您可能永远不会有机地达到压实条件。

结果是修复和压缩都会占用计算资源，并且会降低节点处理请求的能力。但它们需要发生。你希望它们发生。如果压缩没有运行，你的 SSTable 文件的数量和大小都会增加；最终导致行存在于多个文件中，并且对它们的查询会变慢。如果修复未运行，您的数据将面临不同步的风险。