[翻译]关于Cassandra中的删除和墓碑(二)

分布式删除的难题

考虑上面的情况,强一致性是必须的,让我们暂且忘掉墓碑这个东西,假设cassandra删除数据不使用墓碑。如果一次删除操作在一个节点上失败了(总共3个节点,副本为3, RF=3).整个删除操作仍然被认为成功的(因为有两个节点应答成功,使用CL.QUORUM一致性)。接下来如果读发生在该节点上就会变的不明确,因为结果返回是空,还是返回数据,没有办法确定哪一种是正确的。Cassandra总是任务返回数据是对的,那就会发生删除的数据又出现了的事情,这些数据可以叫”僵尸”或者”鬼”,并且他们的表现是不可预见的

赵岩的博客 cassandra的删除

 

注意:这个问题没有完全解决,即便使用了墓碑,所以假设你的集群有删除操作的话我们还要有如下操作: Cassandra运维人员必须在每个gc_grace_seconds周期内对整个集群进行repair操作。

从一个Cassandra节点的视角看待删除

Cassandra使用一旦写入就不再改变的文件来存储数据,像前面描述,墓碑的目的就是为了解决从这样的系统中删除数据的困难的。

Cassanda的一个特种就是使用了一种日志结构合并树(LSM tree),然而大多数关系型数据库(RDBMS)是使用的B树(B-tree)。这样说你可能更容易理解:记住Cassandra写的时候总是往后追加数据,读的时候才会综合这些写入片段,选择每列的最大版本号去返回。

LSM Trees还有一个属性是数据写入文件中就不可以更改(这些文件在Cassandra中叫做SSTables)。正如最初讨论的那样,显然对于这样一个系统,删除只能通过一种特殊的写来实现。读的时候根据墓碑的时间戳,忽略小于这个时间戳之前插入的数据。

  1. ymy说道:

    谢谢分享

留言

提示:你的email不会被公布,欢迎留言^_^

*

验证码 * Time limit is exhausted. Please reload CAPTCHA.