Apache Cassandra 0.6 Documentation

Consistency

The ability to tune consistency levels per query is a powerful feature of Cassandra because it gives the developer complete control of managing the trade-off of availability versus consistency. This means that Cassandra queries can be configured to exhibit strongly consistent behavior (but there is no row-level locking) if the developer is willing to sacrifice latency.

The consistency levels offered by Cassandra, which have different meanings for reads and writes, are detailed in the tables below.

Write Consistency

Level Description
ZERO Ensure nothing. A write happens asynchronously in background. Using this carries the risk of exhausting the messaging service queue.
ANY A write must have been written to at least one node (can include hinted handoff recipients)
ONE A 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 N / 2 + 1 replicas before responding to the client.
DCQUORUM Similar to QUORUM but uses RackAwareStrategy
ALL All replicas must have received the write otherwise the operation will fail.

Read Consistency

Level Description
ONE Returns the response from the first replica causing a consistency check in a background thread. This check ensures that subsequent calls will eventually have correct data even if the initial read gets an older value.
QUORUM Returns the record with the most recent timestamp once a majority of replicas (N / 2 + 1) has reported. Similarly to ONE, remaining replicas will be checked in the background.
DCQUORUM Keeps the reads within a data center via RackAwareStrategy to avoid the latency of inter-data center communication.
ALL Return the record with the most recent timestamp once all replicas have replied, failing the operation if any replicas are unresponsive.
Powered by Rackspace
Apache, Apache Cassandra, Cassandra, Apache Hadoop, Hadoop and the eye logo are trademarks of the Apache Software Foundation.