6

我们正在运行由 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: Read 0 live and 10350 tombstoned cells in .graphindex（参见 tombstone_warn_threshold ）。请求了 8001 列，slices=[00-ff]，delInfo={deletedAt=-9223372036854775808，localDeletion=2147483647}

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

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

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

4

4 回答 4

7

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

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

于 2015-03-10T20:37:42.483 回答
6

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

于 2015-03-10T19:54:46.997 回答
2

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

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

于 2017-04-18T18:56:32.963 回答
1

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

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

于 2015-04-25T20:57:36.303 回答