如何知道Cassandra（CQL）中的受影响的行？ [英] How to know affected rows in Cassandra(CQL)?
问题描述
似乎没有任何直接的方式来知道cassandra中的受影响的行更新和删除语句。
例如，如果我有一个像这样的查询：
DELETE FROM xyztable WHERE PKEY IN（1,2,3,4,5,6）;
现在，由于我已经传递了6个键，受影响。
>。
除了我通过google没有看到有关此主题的任何其他讨论。 >
在最终一致的世界中，你可以看看这些操作，就像它保存一个删除请求，并根据请求的一致性级别，等待来自多个节点的确认，已被接受。然后，请求异步地传递给其他节点。
因为没有对外键的依赖，所以如果请求被集群成功接受，没有什么可以阻止数据被删除。
然而，有很多ifs。例如，删除具有一致性级别1的数据，一个节点成功接受后，紧接着立即节点硬故障可能会导致该删除的丢失，如果它在故障之前未被复制。
另一个例子 - 删除过程中，一个节点关闭，并且停留了大量的时间，比gc_grace_period更长，即比删除数据时删除的墓碑所需的时间更多。然后，如果该节点恢复，则所有突然被从群集的其余部分删除但不从该节点删除的所有数据将被带回到群集。
因此，为了避免这些情况，并考虑操作成功和最终，cassandra管理员需要实施一些措施，包括定期维修作业（以确保所有节点是最新的）。此外，应用程序需要决定什么是更好 - 更快的性能，一致性级别一以牺牲可能的数据丢失为代价，与更低的性能，更高的一致性级别，但更少的数据丢失的可能性。
There doesn't seem to be any direct way to know affected rows in cassandra for update, and delete statements.
For example if I have a query like this:
DELETE FROM xyztable WHERE PKEY IN (1,2,3,4,5,6);
Now, of course, since I've passed 6 keys, it is obvious that 6 rows will be affected.
But, like in RDBMS world, is there any way to know affected rows in update/delete statements in datastax-driver?
I've read cassandra gives no feedback on write operations here.
Except that I could not see any other discussion on this topic through google.
If that's not possible, can I be sure that with the type of query given above, it will either delete all or fail to delete all?
In the eventually consistent world you can look at these operations as if it was saving a delete request, and depending on the requested consistency level, waiting for a confirmation from several nodes that this request has been accepted. Then the request is delivered to the other nodes asynchronously. Since there is no dependency on anything like foreign keys, then nothing should stop data from being deleted if the request was successfully accepted by the cluster.
However, there are a lot of ifs. For example, deleting data with a consistency level one, successfully accepted by one node, followed by an immediate node hard failure may result in the loss of that delete if it was not replicated before the failure.
Another example - during the deletion, one node was down, and stayed down for a significant amount of time, more than the gc_grace_period, i.e., more than it is required for the tombstones to be removed with deleted data. Then if this node is recovered, then all suddenly all data that has been deleted from the rest of the cluster, but not from this node, will be brought back to the cluster.
So in order to avoid these situations, and consider operations successful and final, a cassandra admin needs to implement some measures, including regular repair jobs (to make sure all nodes are up to date). Also applications need to decide what is better - faster performance with consistency level one at the expense of possible data loss, vs lower performance with higher consistency levels but with less possibility of data loss.
这篇关于如何知道Cassandra（CQL）中的受影响的行？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
