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

Question

我们正在运行由Cassandra支持的Titan Graph数据库服务器作为持久存储,并且在达到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

听起来问题的根源是您的数据模型.您已经完成了所有可以缓解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天安排修复).