如何知道Cassandra(CQL)中受影响的行？

Question

似乎没有任何直接的方法来了解cassandra中受影响的行以进行更新和删除语句.

例如,如果我有这样的查询:

DELETE FROM xyztable WHERE PKEY IN (1,2,3,4,5,6);

当然,现在,因为我已经通过了6个密钥,很明显会有6行受到影响.

但是,就像在RDBMS世界中一样,有没有办法知道datastax-driver中更新/删除语句中受影响的行？

我读过cassandra在这里没有给出写操作的反馈.

除了我通过谷歌看不到关于这个主题的任何其他讨论.

如果那是不可能的,我可以确定使用上面给出的查询类型,它会删除全部还是不能删除全部？

Answer 1

在Cassandra中无法做到这一点,因为Cassandra中的写入,删除和更新模型基本相同.在所有这些情况下,将一个单元格添加到表中,该单元具有新信息或有关删除的信息.这是在不检查当前DB状态的情况下完成的.

在不检查其余副本并在行上执行完全合并的情况下,无法判断任何操作是否会实际影响数据库的当前读取状态.

这导致了经常引用的"写作前阅读"的反模式.在Cassandra中,您应该尽可能快地编写,如果您需要有历史记录,请使用数据结构来保留修改日志而不仅仅是当前状态.

使用CAS语法进行这样的查询有一个选项,IF value THEN do other thing但与普通写入相比,这是一个非常昂贵的操作,应该谨慎使用.

Answer 2

在最终一致的世界中,您可以将这些操作视为保存删除请求,并根据请求的一致性级别,等待来自多个节点的确认已接受此请求.然后,请求以异步方式传递给其他节点.由于不依赖外键等任何内容,因此如果集群成功接受请求,则不应阻止数据被删除.

但是,有很多ifs.例如,删除具有一致性级别1的数据,一个节点成功接受,然后立即节点硬故障,如果在失败之前未复制,则可能导致丢失该删除.

另一个例子 - 在删除期间,一个节点关闭,并且停留了很长时间,超过了gc_grace_period,即超过了删除的数据删除墓碑所需的时间.然后,如果恢复此节点,则突然所有已从群集的其余部分删除但未从该节点删除的所有数据都将返回到群集.

因此,为了避免这些情况,并考虑操作成功和最终,cassandra管理员需要实施一些措施,包括定期修复工作(以确保所有节点都是最新的).应用程序还需要决定什么是更好的 - 一致性一级的性能更快,代价是可能的数据丢失,而性能更低,一致性级别更高,但数据丢失的可能性更小.