我有一个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）根据我的研究，墓碑是TTL的标志（在gc_grace_seconds之后将被删除）i）因此，直到10天，这表示它不会被删除吗？ii）等待10天会有什么后果？iii）为什么要花很长时间10天？
https://docs.datastax.com/zh-CN/cql/3.1/cql/cql_reference/tabProp.html
gc_grace_seconds 864000 [10天]在数据被标记为逻辑删除（删除标记）之后，可以进行垃圾收集的秒数。Cassandra不会在其gc_grace_period内的逻辑删除记录上执行提示或批量更改。默认值为Cassandra留出了很多时间来使删除之前的一致性最大化。有关降低此值的详细信息，请参见下面的垃圾回收。
3）我读到使用nodetool执行压缩和修复将删除该逻辑删除，我们需要多久在后台运行一次逻辑删除，这会有什么后果？
这意味着您的查询返回了76条“实时”或未删除/未废弃的数据行，并且它必须筛选1324个墓碑（删除标记）才能完成此操作。
在分布式数据库的世界中，删除是很难的。毕竟，如果您从一个节点上删除了一条数据，并且希望该删除操作在所有节点上进行，您怎么知道它是否有效？从字面上看，您如何不复制任何内容？墓碑（删除标记）是该问题的答案。
一世。数据不见了（而是过时了）。墓碑将保留为gc_grace_seconds。
ii。“后果”是您必须在这段时间内忍受那些墓碑警告消息，或者找到一种方法来运行查询而不必扫描墓碑。
iii。10天后的想法是，如果墓碑收集得太早，则删除的数据将“重影”其方式回到某些节点。10天为您提供了每周进行一次维修的时间，可确保您的墓碑在移除前得到正确的复制。
压实去除墓碑。修复会复制它们。您应该每周进行一次维修。虽然可以按需运行压缩，但不要运行。Cassandra有自己的阈值（基于SSTable文件的数量和大小）来确定何时运行压缩，最好不要妨碍它。如果这样做，您将要从那里开始手动运行压缩，因为您可能永远无法有机地达到压缩条件。
结果是，修复和压缩都会占用计算资源，并且会降低节点处理请求的能力。但是它们需要发生。您希望它们发生。如果不执行压缩，则SSTable文件的数量和大小都会增加；最终导致行存在于多个文件中，对它们的查询将变慢。如果修复未运行，则您的数据可能不同步。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句