卡桑德拉的墓碑
Tombstone in Cassandra
我有一个 TTL 为 60 秒的 Cassandra table，我对此没有什么问题，
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 执行压缩和修复会删除墓碑，我们需要在后台运行 执行此操作的频率如何，它的后果是什么？
这意味着您的查询返回了 76 "live" 或 non-deleted/non-obsoleted 行数据，并且必须筛选 1324 个墓碑（删除标记）才能完成。
在分布式数据库的世界里，删除是很难的。毕竟，如果您从一个节点删除了一条数据，并且您希望该删除操作发生在您的所有节点上，您怎么知道它是否有效？毫不夸张地说，如何复制 nothing？墓碑（删除标记）是该问题的答案。
我。数据消失了（更确切地说，已经过时了）。墓碑将保留 gc_grace_seconds.
二。 "consequence" 是您必须在这段时间内忍受那些墓碑警告消息，或者找到一种方法 运行 您的查询而无需扫描墓碑。
三。 10 天背后的想法是，如果过早收集墓碑，您删除的数据将 "ghost" 返回到某些节点。 10 天让您有足够的时间 运行 进行每周一次的修复，这可确保您的墓碑在移除前得到正确复制。
压缩删除墓碑。修复复制它们。您应该 运行 每周修理一次。而你可以运行压缩on-demand，不要。 Cassandra 有自己的阈值（基于 SSTable 文件的数量和大小）来确定何时进行 运行 压缩，最好不要妨碍它。如果这样做，您将从那里手动 运行ning 压实，因为您可能永远无法有机地达到压实条件。
结果是修复和压缩都会占用计算资源，并且会降低节点处理请求的能力。但它们需要发生。您希望 它们发生。如果压缩没有 运行，你的 SSTable 文件的数量和大小都会增加；最终导致行存在于多个文件中，并且对它们的查询会变慢。如果修复没有 运行，您的数据有可能无法 in-sync。
我有一个 TTL 为 60 秒的 Cassandra table，我对此没有什么问题，
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 执行压缩和修复会删除墓碑，我们需要在后台运行 执行此操作的频率如何，它的后果是什么？
这意味着您的查询返回了 76 "live" 或 non-deleted/non-obsoleted 行数据，并且必须筛选 1324 个墓碑（删除标记）才能完成。
在分布式数据库的世界里，删除是很难的。毕竟，如果您从一个节点删除了一条数据，并且您希望该删除操作发生在您的所有节点上，您怎么知道它是否有效？毫不夸张地说，如何复制 nothing？墓碑（删除标记）是该问题的答案。
我。数据消失了（更确切地说，已经过时了）。墓碑将保留
gc_grace_seconds.二。 "consequence" 是您必须在这段时间内忍受那些墓碑警告消息，或者找到一种方法 运行 您的查询而无需扫描墓碑。
三。 10 天背后的想法是，如果过早收集墓碑，您删除的数据将 "ghost" 返回到某些节点。 10 天让您有足够的时间 运行 进行每周一次的修复，这可确保您的墓碑在移除前得到正确复制。
压缩删除墓碑。修复复制它们。您应该 运行 每周修理一次。而你可以运行压缩on-demand，不要。 Cassandra 有自己的阈值（基于 SSTable 文件的数量和大小）来确定何时进行 运行 压缩，最好不要妨碍它。如果这样做，您将从那里手动 运行ning 压实，因为您可能永远无法有机地达到压实条件。
结果是修复和压缩都会占用计算资源，并且会降低节点处理请求的能力。但它们需要发生。您希望 它们发生。如果压缩没有 运行，你的 SSTable 文件的数量和大小都会增加；最终导致行存在于多个文件中，并且对它们的查询会变慢。如果修复没有 运行，您的数据有可能无法 in-sync。