I think this would add a lot of complexity behind the scenes and be conceptually confusing, particularly for new users. The Cassandra consistency model is pretty elegant and this type of approach breaks that elegance in many ways. It would also only really be useful when the value has a high probability of being updated between a node going down and the value being read. Perhaps the simpler approach which is fairly trivial and does not require any Cassandra change is to simply downgrade your read from ALL to QUORUM when you get an unavailable exception for this particular read.
I think the general answerer for 'maximum consistency' is QUORUM reads/writes. Based on the fact you are using CL=ALL for reads I assume you are using CL=ONE for writes: this itself strikes me as a bad idea if you require 'maximum consistency for one critical operation'. Dan -----Original Message----- From: Ryan King [mailto:r...@twitter.com] Sent: June-16-11 12:05 To: user@cassandra.apache.org Subject: Re: Propose new ConsistencyLevel.ALL_AVAIL for reads On Thu, Jun 16, 2011 at 8:18 AM, AJ <a...@dude.podzone.net> wrote: > Good morning all. > > Hypothetical Setup: > 1 data center > RF = 3 > Total nodes > 3 > > Problem: > Suppose I need maximum consistency for one critical operation; thus I > specify CL = ALL for reads. However, this will fail if only 1 replica > endpoint is down. I don't see why this fail is necessary all of the time > since the data could have been updated since the node became unavailable and > it's data is old anyways. If only one node goes down and it has the key I > need, then the app is not 100% available and it could take some time making > the node available again. > > Proposal: > If all of the *available* replica nodes answer the read operation and the > latest value timestamp is clearly AFTER the time the down node became > unavailable, then this situation can meet the requirements for *near* 100% > consistency since the value in the down node would be outdated anyway. > Clearly, the value was updated some time *after* the node went down or > unavailable. This way, you can have max availability when using read with > CL.ALL... or something CL close in meaning to ALL. > > I say "near" 100% consistency to leave room for some situation where the > unavailable node was only unavailable to the coordinating node for some > reason such as a network issue and thus still received an update by some > other route after it "appeared" unavailable to the current coordinating > node. In a situation like this, there is a chance the read will still not > return the latest value. So, this will not be truly 100% consistent which > CL.ALL guarantees. However, I think this logic could justify a new > consistency level slightly lower than ALL, such as ALL_AVAIL. > > What do you think? Is my logic correct? Is there a conflict with the > architecture or base principles? This fits with the tunable consistency > principle for sure. I don't think this buys you anything that you can't get with quorum reads and writes. -ryan No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.901 / Virus Database: 271.1.1/3707 - Release Date: 06/16/11 02:34:00
