我有一张Tss为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执行压缩和修复会删除墓碑，我们需要在后台运行它的频率，它的后果是什么？
答案 0 :(得分：4)
这意味着您的查询返回了76个“实时”或未删除/未过时的数据行，并且必须通过1324个墓碑（删除标记）进行筛选才能完成此操作。
< / LI>在分布式数据库的世界中，删除很难。毕竟，如果您从一个节点删除一段数据，并且您希望在所有节点上发生删除，那么您如何知道它是否有效？从字面上看，你如何复制没有？墓碑（删除标记）就是这个问题的答案。
我。数据消失了（过时了）。墓碑将留在gc_grace_seconds。
II。 “后果”是你必须在这段时间内忍受那些墓碑警告信息，或者找到一种方法来运行你的查询而不必扫描墓碑。
III。 10天背后的想法是，如果过早收集墓碑，那么您删除的数据将“重新”回到某些节点。 10天为您提供足够的时间进行每周修复，确保您的墓碑在移除前得到正确复制。
压缩删除墓碑。修复复制它们。你应该每周修一次。虽然可以按需运行压缩，但 不 。 Cassandra有自己的阈值（基于SSTable文件的数量和大小）来确定何时运行压缩，最好不要妨碍它。如果你这样做，你将从那里手动运行压缩，因为你可能永远无法有机地达到压实条件。
结果是，修复和压缩都会占用计算资源，并且会降低节点提供请求的能力。但他们需要发生。你希望它们发生。如果压缩没有运行，您的SSTable文件的数量和大小将会增加;最终导致行存在于多个文件上，对它们的查询将变慢。如果未运行修复，则您的数据可能无法同步。