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 NickTelford
Date Mon, 16 Aug 2010 14:22:10 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 NickTelford.
The comment on this change is: Clarified terminology in ConsistencyLevel section to define
the difference between a "node" and a "replica" especially when dealing with HH..
http://wiki.apache.org/cassandra/API?action=diff&rev1=63&rev2=64

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

  === 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.
  
- 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.
+ Terminology: "N" is the ReplicationFactor; "replicas" are the `N` nodes that are directly
responsible for the data; "nodes" are any/all nodes in the cluster, including HintedHandoff
participants.
  
  ==== Write ====
  ||'''Level''' ||'''Behavior''' ||
  ||`ZERO` ||Ensure nothing. A write happens asynchronously in background. Until [[https://issues.apache.org/jira/browse/CASSANDRA-685|CASSANDRA-685]]
is fixed: If too many of these queue up, buffers will explode and bad things will happen.
||
- ||`ANY` ||(Requires 0.6) Ensure that the write has been written to at least 1 node, including
hinted recipients. ||
+ ||`ANY` ||(Requires 0.6) Ensure that the write has been written to at least 1 node, including
HintedHandoff recipients. ||
- ||`ONE` ||Ensure that the write has been written to at least 1 node's commit log and memory
table before responding to the client. ||
+ ||`ONE` ||Ensure that the write has been written to at least 1 replica's commit log and
memory table before responding to the client. ||
- ||`QUORUM` ||Ensure that the write has been written to `<ReplicationFactor> / 2 +
1` nodes before responding to the client. ||
+ ||`QUORUM` ||Ensure that the write has been written to `N / 2 + 1` replicas before responding
to the client. ||
  ||`DCQUORUM` ||As above but takes into account the rack aware placement strategy. See https://issues.apache.org/jira/browse/CASSANDRA-492
||
- ||`ALL` ||Ensure that the write is written to all `<ReplicationFactor>` nodes before
responding to the client.  Any unresponsive nodes will fail the operation. ||
+ ||`ALL` ||Ensure that the write is written to all `N` replicas before responding to the
client.  Any unresponsive replicas will fail the operation. ||
  
  
  ==== Read ====
  ||'''Level''' ||'''Behavior''' ||
  ||`ZERO` ||Not supported, because it doesn't make sense. ||
  ||`ANY` ||Not supported. You probably want ONE instead. ||
- ||`ONE` ||Will return the record returned by the first node to respond. A consistency check
is always done in a background thread to fix any consistency issues when `ConsistencyLevel.ONE`
is used. This means subsequent calls will have correct data even if the initial read gets
an older value.  (This is called `read repair`.) ||
+ ||`ONE` ||Will return the record returned by the first replica to respond. A consistency
check is always done in a background thread to fix any consistency issues when `ConsistencyLevel.ONE`
is used. This means subsequent calls will have correct data even if the initial read gets
an older value.  (This is called ReadRepair) ||
- ||`QUORUM` ||Will query all nodes and return the record with the most recent timestamp once
it has at least a majority of replicas reported.  Again, the remaining replicas will be checked
in the background. ||
+ ||`QUORUM` ||Will query all replicas and return the record with the most recent timestamp
once it has at least a majority of replicas (`N / 2 + 1`) reported.  Again, the remaining
replicas will be checked in the background. ||
  ||`DCQUORUM` ||When using rack aware placement strategy reads are keept within a data center.
See https://issues.apache.org/jira/browse/CASSANDRA-492 ||
- ||`ALL` ||Will query all nodes and return the record with the most recent timestamp once
all nodes have replied.  Any unresponsive nodes will fail the operation. ||
+ ||`ALL` ||Will query all replicas and return the record with the most recent timestamp once
all replicas have replied.  Any unresponsive replicas will fail the operation. ||
  
  
  '''Note: '''Thrift prior to version 0.6 defaults to a Write Consistency Level of ZERO. Different
language toolkits may have their own Consistency Level defaults as well. To ensure the desired
Consistency Level, you should always explicitly set the Consistency Level.

Mime
View raw message