Cassandra Tombstoning警告和失败阈值被破坏

Question

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

我们的用例支持：

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

听起来问题的根源是您的数据模型。您已经完成了所有可以缓解TombstoneOverwhelmingException的操作。由于您的数据模型需要频繁更新导致墓碑创建，因此像Cassandra这样的最终一致存储可能不适合您的用例。当我们遇到这些类型的问题时，我们不得不改变我们的数据模型以更好地适应Cassandra的优势。

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

Answer 2

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

Answer 3

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

然而，值得考虑的是，Inserting Nulls等同于删除。这会增加你的墓碑数量。相反，如果您正在使用预准备语句，则需要插入UNSET_VALUE。对你来说可能太迟了，但是如果有其他人来这里的话。

Answer 4

你调整过的变量正在帮助你使墓碑过期，但值得注意的是，虽然墓碑在gc_grace_seconds之前无法清除，但Cassandra并不保证墓碑会在gc_grace_seconds被清除。实际上，在含有墓碑的sstable被压缩之前，墓碑不会被压缩，即便如此，如果有另一个sstable包含被遮蔽的单元格，它也不会被消除。

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