cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremiah Jordan <>
Subject Re: Second Cassandra users survey
Date Mon, 07 Nov 2011 16:07:48 GMT
Actually, the data will be visible at QUORUM as well if you can see it 
with ONE.  QUORUM actually gives you a higher chance of seeing the new 
value than ONE does.  In the case of R=3 you have 2/3 chance of seeing 
the new value with QUORUM, with ONE you have 1/3...  And this JIRA fixed 
an issue where two QUORUM reads in a row could give you the NEW value 
and then the OLD value.

So quorum read on fail for a single row always gives consistent results 
now.  For multiple rows your still have issues, but you can always 
mitigate that in app with something like giving all of the changes the 
same time stamp, and then on read checking to make sure the time stamps 
match, and reading the data again if they don't.

I'm not arguing against atomic batch operations, they would be nice =).  
Just clarifying how things work now.


On 11/06/2011 02:05 PM, Pierre Chalamet wrote:
>>> - support for atomic operations or batches (if QUORUM fails, data should
> not be visible with ONE)
>> zookeeper is solving that.
> I might have screwed up a little bit since I didn't talk about isolation;
> let's reformulate: support for read committed (using DB terminology).
> Cassandra is more like read uncommitted.
> Even if row mutations in one CF for one key are atomic on one server , stuff
> is not rolled back when the CL can't be satisfied at the coordinator level.
> Data won't be visible at QUORUM level, but when using weaker CL, invalid
> data can appear imho.
> Also it should be possible to tell which operations failed with batch_mutate
> but unfortunately it is not

View raw message