卡桑德拉的墓碑

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

1. 这意味着您的查询返回了 76 个“实时”或未删除/未过时的数据行，并且它必须筛选 1324 个墓碑（删除标记）才能完成。

2. 在分布式数据库的世界中，删除很困难。毕竟，如果您从一个节点中删除了一条数据，并且您希望删除发生在您的所有节点上，您怎么知道它是否有效？从字面上看，你如何复制nothing？墓碑（删除标记）是该问题的答案。

   我。数据消失了（而是过时了）。墓碑将保留gc_grace_seconds。

   二。 “后果”是您将不得不在这段时间内忍受那些墓碑警告消息，或者找到一种无需扫描墓碑即可运行查询的方法。

   三。这 10 天背后的想法是，如果过早收集墓碑，您删除的数据将“重影”回到某些节点。 10 天让您有足够的时间进行每周修复，从而确保您的墓碑在移除之前得到正确复制。

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

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