超过 Cassandra Tombstoning 警告和故障阈值

Question

我们正在运行由 Cassandra 支持的 Titan Graph DB 服务器作为持久存储，并且遇到了达到 Cassandra 墓碑阈值限制的问题，这导致我们的查询随着数据的累积而定期失败/超时。似乎压缩无法跟上正在添加的墓碑数量。

我们的用例支持：

1. 高读/写吞吐量。
2. 读取灵敏度高。
3. Titan 中节点值的频繁更新。导致在 Cassandra 中更新行。

鉴于上述用例，我们已经在优化 Cassandra 以积极完成以下工作：

1. 使用分级压实策略进行积极压实
2. 使用 tombstone_compaction_interval 为 60 秒。
3. 使用 tombstone_threshold 为 0.01
4. 将 gc_grace_seconds 设置为 1800

尽管进行了以下优化，我们仍然在 Cassandra 日志中看到类似于以下内容的警告： [WARN] (ReadStage:7510) org.apache.cassandra.db.filter.SliceQueryFilter: 在 .graphindex 中读取 0 个实时单元和 10350 个墓碑单元（参见 tombstone_warn_threshold）。请求了 8001 列， slices=[00-ff], delInfo={deletedAt=-9223372036854775808, localDeletion=2147483647}

随着时间的推移，我们有时还会看到超出故障阈值并导致错误。

我们的 cassandra.yaml 文件的 tombstone_warn_threshold 为 10000，而 tombstone_failure_threshold 远高于建议的 250000，但没有真正明显的好处。

如果有进一步优化的空间，任何可以为我们指出正确配置的帮助将不胜感激。提前感谢您的时间和帮助。

Answer 1

在给定墓碑的表上的gc_grace_seconds 配置结束之前，不会压缩墓碑。所以即使增加你的压缩间隔，你的墓碑也不会被删除，直到 gc_grace_seconds 已经过去，默认为 10 天。您可以尝试将 gc_grace_seconds 调低到一个较低的值并更频繁地进行修复（通常您希望安排每 gc_grace_seconds_in_days - 1 天进行一次修复）。

Answer 2

听起来问题的根源在于您的数据模型。您已尽一切努力减轻出现 TombstoneOverwhelmingException。由于您的数据模型需要如此频繁的更新，从而导致创建墓碑，因此像 Cassandra 这样的最终一致存储可能不适合您的用例。当我们遇到这些类型的问题时，我们不得不改变我们的数据模型以更好地适应 Cassandra 的优势。

关于删除http://www.slideshare.net/planetcassandra/8-axel-liljencrantz-23204252（幻灯片 34-39）

Answer 3

您已调整的变量可帮助您使墓碑过期，但值得注意的是，虽然墓碑在 gc_grace_seconds 之前无法清除，但 Cassandra 不保证将在 gc_grace_seconds 清除墓碑。事实上，直到包含墓碑的 sstable 被压缩后，墓碑才会被压缩，即使这样，如果另一个 sstable 包含被阴影的单元格，它也不会被删除。

这会导致墓碑可能会持续很长时间，尤其是当您使用不经常压缩的 sstable（例如，非常大的 STCS sstable）时。为了解决这个问题，存在诸如 JMX 端点之类的工具来 forceUserDefinedCompaction - 如果您不擅长使用 JMX 端点，那么自动为您执行此操作的工具存在，例如 http://www.encql.com/purge-cassandra-tombstones/

Answer 4

所以这里的每个人都是对的。如果你经常修复和压缩你的 gc_grace_seconds 数。

然而，插入空值等同于删除也可能值得考虑。这将增加你的墓碑数量。相反，如果您使用准备好的语句，则需要插入 UNSET_VALUE。对你来说可能为时已晚，但如果其他人来这里。