Re: Key-hash based node selection

[Edward Capriolo]

You can not be /mostly/ consistent readlike you can not be half-pregnant
or half transactional. You either are or you are not.

If you do not have enough nodes for a QUORUM the read fails. Thus you never
get stale reads you only get failed reads.

The dynamic snitch makes reads sticky at READ.ONE. Until a node crosses
the badness_threshold,reads should be routed to the same node. (first
natural endpoint). This is not a guarantee as each node is keeping snitch
scores and routing requests based on its view of the scores.

So at READ.ONE you could argue that Cassandra is mostly consistent based
on your definition.


On Fri, Jan 18, 2013 at 7:23 PM, Timothy Denike ti...@circuitboy.orgwrote:

 /mostly/ consistent reads

Re: Key-hash based node selection

[Timothy Denike]

Hi Folks,

I'm trying to wrap my brain around how one would configure a Cassandra
cluster to support consistent reads in various cluster failure states.
 (IE: Reads must see the most recent write.)

Gracefully handling a single node failure seems easy enough.  Use
QUORUM (RF/2+1) for reads and writes.
This is all fair and good as long as you only lose  50% of your
cluster.  If your cassandra nodes span two switches, or two PDUs, or
two VM host servers, it seems we can't make this guarantee.

I'm curious if it's possible to configure such that a coordinator node
selects a replica node based on a hash of the key.  This sounds like a
function of the snitch, but the snitch configurations seem to revolve
around physical/geo parameters.

If replica selection for a given key was consistent and sticky - it
seems we could achieve /mostly/ consistent reads at lower consistency
levels during a failure of 50% without failing writes.  (Save for
cases of flapping.)

Is this in the stars?  If not, are there any client libs that
implement this by (hashed) selection of a coordinator node that is a
replica for the requested key?  (It seems pycassa does not.)

Timmy