代码之家 › 专栏 › 技术社区 › Harry

卡桑德拉墓碑

cassandra-3.0 cassandra

Harry · 技术社区 · 7 年前

我有一张卡桑德拉表,TTL为60秒,这方面我没有什么问题,

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\U grace\U秒后删除) i) 那么,直到10天,这是否意味着它不会被删除? ii)等待10天会有什么后果? iii)为什么10天的时间很长?

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

gc\u grace\u seconds 864000[10天]使用墓碑(删除标记)标记数据后,数据符合垃圾收集条件的秒数。在gc\U宽限期内,Cassandra不会对逻辑删除的记录执行提示或成批突变。默认值允许Cassandra在删除之前有大量时间最大化一致性。有关减少此值的详细信息,请参阅下面的垃圾收集。

3) 我读到,使用nodetool执行压缩和修复将删除墓碑,我们需要多久在后台运行一次,结果会怎样?

1 回复 | 直到 5 年前

Aaron 7 年前

这意味着您的查询返回了76行“活动”或未删除/未过时的数据,它必须筛选1324个墓碑(删除标记)才能完成。
在分布式数据库的世界中,删除很困难。毕竟,如果您从一个节点删除一段数据,并且您希望删除会发生在所有节点上,那么您如何知道它是否有效?确切地说,你如何复制 没有什么 ?墓碑(删除标记)就是这个问题的答案。

i、数据不见了(更确切地说,已经过时了)。墓碑将保留 gc_grace_seconds 。

二。“结果”是,您必须在这段时间内忍受那些墓碑警告消息,或者找到一种方法来运行查询,而不必扫描墓碑。

iii.这10天背后的想法是,如果墓碑收集得太早,则删除的数据将“幽灵”返回到某些节点。10天可以让您有足够的时间进行每周修复,从而确保您的墓碑在删除之前得到正确复制。
压缩将删除墓碑。修复复制它们。您应该每周运行一次修复。而你可以按需压实, 不要。Cassandra有自己的阈值(基于SSTable文件的数量和大小)来确定何时运行压缩,最好不要妨碍它。如果这样做,您将从那里开始手动运行压实,因为您可能永远不会有机地达到压实条件。

结果是,修复和压缩都会占用计算资源,并且会降低节点服务请求的能力。但它们需要发生。你希望他们会发生的。如果压缩不运行,SSTable文件的数量和大小将增加;最终导致多个文件上存在行,对这些行的查询将变得缓慢。如果修复未运行,则您的数据有不同步的风险。