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. A “quorum” of replicas is essentially a majority of replicas, or RF / 2 + 1 with any resulting fractions rounded down.
|ANY||Ensure that the write has been written to at least one node (can include hinted handoff recipients). Note that if all replica nodes are down at write time, an ANY write may not be readable until nodes have recovered.|
|ONE||Ensure that the write has been written to at least one replica’s commit log and memory table before responding to the client.|
|QUORUM||Ensure that the write has been written to a quorum of replicas before responding to the client.|
|LOCAL_QUORUM||Ensure that the write has been written to a quorum of replicas in the datacenter local to the coordinator before responding to the client. This setting avoids the latency of inter-data center communication.|
|EACH_QUORUM||Ensure that the write has been written to a quorum of replicas in each datacenter in the cluster before responding to the client.|
|ALL||All replicas must have received the write; otherwise the operation will fail.|
|ONE||Returns the response from the closest replica, as determined by the snitch configured for the cluster. When read repair is enabled, Cassandra may perform a consistency check in a background thread.|
|QUORUM||Returns the record with the most recent timestamp once a quorum of replicas has reported.|
|LOCAL_QUORUM||Returns the record with the most recent timestamp once a quorum of replicas in the datacenter local to the coordinator has reported. This setting avoids the latency of inter-data center communication.|
|EACH_QUORUM||Returns the record with the most recent timestamp once a quorum of replicas in each datacenter in the cluster has reported.|
|ALL||Return the record with the most recent timestamp once all replicas have replied, failing the operation if any replicas are unresponsive.|
LOCAL_QUORUM and EACH_QUORUM are designed for use in clusters with rack-aware replica placement strategies such as NetworkTopologyStrategy. Used with SimpleStrategy, these consistency levels may lead to unpredictable results.
In choosing the consistency level for particular operations, developers should consider the relative importance of consistency, latency, and availability.
For instance, in a case where availability is top priority it may make sense to choose a level of ONE over QUORUM. If the replication factor for the cluster is 3, a QUORUM operation tolerates the loss of only one node (or, one copy of the data) while ONE allows the operation to complete even if two nodes are unavailable.
Clusters spanning multiple data centers may present further questions regarding local latency and durability. For a examples of consistency level settings used in such scenarios, see Multiple Data Centers.
For specialized cases where the replication factor is higher than three, Cassandra provides consistency levels of TWO and THREE for both read and write operations. These levels are considered experimental, and may be replaced in a future release by custom pluggable consistency levels.