Database Reference
In-Depth Information
The CAP theorem
Through tunable consistency, Cassandra allows us to choose where in the tradeoff between
consistency and failure-tolerance we are most comfortable. But the tradeoff is there non-
etheless; this is an unavoidable fact not just about Cassandra, but about all distributed sys-
tems. The tradeoff between consistency and availability is formalized by the
CAP Theor-
em
.
The CAP Theorem concerns the following three properties of a distributed system, from
which it derives its name:
• Consistency in the CAP theorem refers to immediate consistency—the effects of a
successful write operation must be immediately available to any client who wishes
to read the data
• Availability refers to the ability of the system to give every request a response
about whether it succeeded or failed
• Partition tolerance is resilience to a particular kind of hardware failure—the arbit-
rary loss of data in inter-node communication
The CAP theorem states simply that it is impossible for a distributed system to provide all
three of the above properties, but that it is possible to provide any two of them. The CAP
theorem is best treated as a framework from which to think about the properties of distrib-
uted systems, rather than a rigorous description of real-world databases. That said, we can
briefly explore where Cassandra lies within the CAP framework.
When using
ONE
consistency, Cassandra is clearly an AP system; we don't get immediate
consistency, but the cluster can tolerate a complete partition between nodes. If the node that
receives a request is able to communicate with one of the interested replicas, it will give a
successful response; otherwise, it will fail. Note that returning a failed response does not
violate availability as defined in CAP; the only requirement is that the request terminate
with information about whether it succeeded.
When using the
QUORUM
or
ALL
consistency, Cassandra becomes a CA system. Immediate
consistency is guaranteed but only when all nodes in the cluster are able to communicate
with one another. In the event of a partition of the cluster, any request that requires re-
sponses from nodes on both sides of the partition will fail.
