On 6/16/2011 10:58 AM, Dan Hendry wrote:
> I think this would add a lot of complexity behind the scenes and be conceptually confusing,
particularly for new users.
I'm not so sure about this. Cass is already somewhat sophisticated and
I don't see how this could trip-up anyone who can already grasp the
basics. The only thing I am adding to the CL concept is the concept of
available replication nodes, versus total replication nodes. But, don't
forget; a competitor to Cass is probably in the works this very minute
so constant improvement is a good thing.
> 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.
I'm not sure what you mean. A node can be down for days during which
time the value can be updated. The intention is to use the nodes
available even if they fall below the RF. If there is only 1 node
available for accepting a replica, that should be enough given the
conditions I stated and updated below.
> 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.
It's not so trivial, esp since you would have to build that into your
client at many levels. I think it would be more appropriate (if this
idea survives) to put it into Cass.
> 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'.
>
Very true. Specifying quorum for BOTH reads/writes provides the 100%
consistency because of the overlapping of the availability numbers.
But, only if the # of available nodes is not < RF.
Upon further reflection, this idea can be used for any consistency
level. The general thrust of my argument is: If a particular value can
be overwritten by one process regardless of it's prior value, then that
implies that the value in the down node is no longer up-to-date and can
be disregarded. Just work with the nodes that are available.
Actually, now that I think about it...
ALL_AVAIL guarantees 100% consistency iff the latest timestamp of the
value > latest unavailability time of all unavailable replica nodes for
that value's row key. Unavailable is defined as a node's Cass process
that is not reachable from ANY node in the cluster in the same data
center. If the node in question is available to at least one node, then
the read should fail as there is a possibility that the value could have
been updated some other way.
After looking at the code, it doesn't look like it will be difficult.
Instead of skipping the request for values from the nodes when CL nodes
aren't available, it would have to go ahead and request the values from
the available nodes as usual and then look at the timestamps which it
does anyways and compare it to the latest unavailability time of the
relevant replica nodes. The code that keeps track of what nodes are
down simply records the time it went down. But, I've only been looking
at the code for a few days so I'm not claiming to know everything by any
stretch.
> Dan
>
Thanks for your reply. I still welcome critiques.
|