cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Cassandra Wiki] Update of "API" by AmichaiRothman
Date Mon, 01 Mar 2010 17:00:55 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.

The "API" page has been changed by AmichaiRothman.
The comment on this change is: clarified consistency level context and behavior.
http://wiki.apache.org/cassandra/API?action=diff&rev1=39&rev2=40

--------------------------------------------------

  
  == Structures ==
  === ConsistencyLevel ===
- The `ConsistencyLevel` is an `enum` that controls both read and write behavior based on
`<ReplicationFactor>` in your `storage-conf.xml`. The different consistency levels have
different meanings, depending on if you're doing a write or read operation.  Note that if
`W` + `R` > `ReplicationFactor`, where W is the number of nodes to block for on write,
and R the number to block for on reads, you will have strongly consistent behavior; that is,
readers will always see the most recent write.  Of these, the most interesting is to do `QUORUM`
reads and writes, which gives you consistency while still allowing availability in the face
of node failures up to half of `ReplicationFactor`.  Of course if latency is more important
than consistency then you can use lower values for either or both.
+ Write operations are always propagated to all replica nodes for a given key. Read operations
are also always propagated to all replicas, so that the most up to date data amongst them
can be returned, and at the same opportunity the older replicas can be updated with it (this
is called read repair). These mechanisms provide eventual consistency of the data. However,
a client doesn't have to wait for all this to happen - it can choose to reduce an operation's
latency by agreeing to receive its response before all replicas have completed the operation,
at the cost of possibility reading older data (for reads) or that subsequent operations will
not immediately see the newly written data (for writes).
+ 
+ The `ConsistencyLevel` is an `enum` that controls the read and write behavior based on the
`ReplicationFactor` specified in `storage-conf.xml`. The `ConsistencyLevel` constants have
different meanings for reads than for writes (see tables below).  Note that if `W` + `R` >
`ReplicationFactor`, where W is the number of nodes to block on for write, and R the number
to block on for  reads, you will have strongly consistent behavior; that is, readers will
always see the most recent write.The most common choice is `QUORUM` reads and writes, which
gives you consistency while still allowing availability in the face of node failures up to
half of `ReplicationFactor`.  Of course if latency is more important than consistency then
you can use lower values for either or both.
  
  All discussion of "nodes" here refers to nodes responsible for holding data for the given
key; "surrogate" nodes involved in HintedHandoff do not count towards achieving the requested
!ConsistencyLevel.
  

Mime
View raw message