我们正在运行由 Cassandra 支持的 Titan Graph DB 服务器作为持久存储，并且在达到 Cassandra 逻辑删除阈值限制时遇到了问题，这导致我们的查询随着数据的积累而定期失败/超时。似乎压实无法跟上添加的墓碑数量。
我们的用例支持：
- 高读/写吞吐量。
- 对读取的高灵敏度。
- 频繁更新 Titan 中的节点值。 导致 Cassandra 中的行更新。
鉴于上述用例，我们已经在优化 Cassandra 以积极执行以下操作：
- 使用分级压实策略进行强力压实
- 使用 tombstone_compaction_interval 作为 60 秒。
- 使用tombstone_threshold为 0.01
- 将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，localDelete=2147483647}
有时，随着时间的推移，我们也会看到故障阈值被突破并导致错误。
我们的 cassandra.yaml 文件的tombstone_warn_threshold为 10000，tombstone_failure_threshold远高于建议的 250000，没有真正明显的好处。
如果有进一步优化的空间，任何可以指向我们正确配置的帮助将不胜感激。提前感谢您的时间和帮助。
听起来问题的根源是数据模型。你已经做了你能做的一切来缓解TombstoneOverwhelmingException。由于您的数据模型需要如此频繁的更新，从而导致逻辑删除创建，因此像 Cassandra 这样的最终一致存储可能不适合您的用例。当我们遇到这些类型的问题时，我们不得不改变我们的数据模型，以更好地适应Cassandra的优势。
关于删除 http://www.slideshare.net/planetcassandra/8-axel-liljencrantz-23204252（幻灯片 34-39）
给定逻辑删除的表上的gc_grace_seconds配置经过之前，不会压缩逻辑删除。 因此，即使增加压缩间隔，您的墓碑也不会被删除，直到gc_grace_seconds过去，默认值为 10 天。 您可以尝试将gc_grace_seconds调低到较低的值并更频繁地进行维修（通常您希望将维修安排为每 gc_grace_seconds_in_days - 1 天进行一次）。
所以这里的每个人都是对的。 如果您经常维修和压薄，则会减少gc_grace_seconds数量。
但是，可能也值得考虑插入 Null 等效于删除。 这将增加您的墓碑数量。 相反，如果您使用的是预准备语句，则需要插入UNSET_VALUE。 对你来说可能太晚了，但如果其他人来这里。
您调整的变量正在帮助您使逻辑删除过期，但值得注意的是，虽然逻辑删除在gc_grace_seconds之前无法清除，但 Cassandra 不保证逻辑删除将在gc_grace_seconds时清除。事实上，在包含墓碑的马厩被压实之前，墓碑不会被压缩，即使这样，如果还有另一个包含阴影细胞的马厩也不会被消除。
这会导致逻辑删除可能会持续很长时间，尤其是在使用不经常压缩的 sstable（例如，非常大的 STCS sstables）时。为了解决这个问题，存在一些工具，例如 JMX 端点来强制用户定义压缩 - 如果您不擅长使用 JMX 端点，则会自动存在为您执行此操作的工具，例如 http://www.encql.com/purge-cassandra-tombstones/