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. |