Cassandra删除数据的坑

作者: yangzhe1991 分类: 我是搞技术的 发布时间: 2014-08-15 22:19 ė 6没有评论

最近被某服务折腾,交了点学费但至少对Cassandra删除数据这块的理解更深了一些。总结的经验如下。

Cassandra通过写一条“tombstone”来标记一个数据被删除了。被标记的数据默认要10天(配置文件中的gc_grace_seconds)后且被compaction或cleanup执行到对应的SSTable时才会被真正从磁盘删除,因为如果当时这个delete操作只在3个节点中的2个执行成功,那么一旦2个有tombstone的节点把数据删了,集群上只剩下没tombstone的那个节点,下次读这个key的时候就又返回对应的数据,从而导致被删除的数据复活。Repair操作可以同步所有节点的数据从而保证tombstone在3个节点中都存在,因此如果想确保删除100%成功不会复活需要以小于gc_grace_seconds的周期定期执行repair操作(所以官方建议”weekly”)。

然而在select数据的时候,在每个SSTable遇到的所有符合查询条件的tombstone要放内存中从而在合并每个SSTable文件的数据时判断哪些column数据没被删能最终返回,tombstone太多会导致heap被大量占用需要各种GC从而影响性能,所以cassandra默认读到100000个(可配置)tombstone就强制取消这次读取,因为遇到这种情况一定是你“doing it wrong”。因此如果经常删除一个row key下的column key,同时又有一次select一个row key下多个column key的需求,很容易遇到这种情况,tombstone很多的时候即使不到10w最终成功读取了,这次读取也会很慢,并很快导致触发年轻代GC从而拖慢整个节点的响应速度。

最好的解决方案肯定是设计的时候就避免。但假如在不修改表结构的情况下,解决方案有两种:如果不能接受一个column key被删又复活,先把gc_grace_seconds改成0,然后删除的时候用ALL模式,当然只要有1个节点超时/挂掉删除就会失败;如果能接受被删的数据复活,删除只为了减少磁盘空间使用,那就直接把gc_grace_seconds设成0,复活就复活吧。

本文出自 杨肉的演讲台,转载时请注明出处及相应链接。

本文永久链接: https://yangzhe1991.org/blog/2014/08/cassandra%e5%88%a0%e9%99%a4%e6%95%b0%e6%8d%ae%e7%9a%84%e5%9d%91/

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

 
Ɣ回顶部