cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: Does Cassandra use vector clocks
Date Wed, 23 Feb 2011 14:20:23 GMT
On Wed, Feb 23, 2011 at 3:32 AM, Oleg Anastasyev <oleganas@gmail.com> wrote:
>> Basically: vector clocks tell you there was a conflict, but not how to
>> resolve it (that is, you simply don't have enough information to
>> resolve it even if you push that back to the client a la Dynamo).
>> What dynamo-like systems mostly VC for is the trivial case of "client
>> X updated field 1, client Y updated field 2, so I can resolve that
>> into a merged value containing both updates."  But Cassandra already
>> handles that by splitting the row up into column-per-field, so VC
>> doesn't add anything for us.
>
> Still, vector clocks are very useful in read-modify-update scenarios. In these
> scenarios cassandra requies external pessimistic locking servers, which makes
> cassandra almost unusable for these scenarios, because of introduced latency,
> especially when you have low concurrency for a single column, where optimistic
> locking is a perfect fit.

>From the article I linked:

"But wait, some might say, you can avoid all this by using vectors in
a different way – to prevent update conflicts by issuing conditional
writes which specify a version (vector) and only succeed if that
version is still current. Sorry, but no, or at least not generally. In
a partition-tolerant system, nodes on each side of a partition may
simultaneously accept conflicting writes against the same initial
version, and you’ll still have to resolve the conflict when you
resolve the partition."

-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com

Mime
View raw message