Database Reference
In-Depth Information
Tuning consistency
Cassandra's tunable consistency allows us to specify, for each query, how many replicas
must be involved for the request to be considered a success. Consistency is not directly spe-
cified as part of the CQL query; instead, it is provided as an additional parameter given to
the driver when performing a query. Different language drivers handle this differently, but
any CQL driver should provide an interface for specifying the consistency for a given
query.
Cassandra defines eleven different consistency levels, but many of them are for fairly spe-
cialized scenarios. We will explore the three most important and useful consistency levels:
ONE
,
ALL
, and
QUORUM
.
Eventual consistency with ONE
For the remainder of our discussion of consistency, let's assume we're using a replication
factor of three. That means, regardless of the total number of nodes we have in our cluster,
any given piece of data will live on three different nodes.
Let's say we update
alice
's row in the
users
table, changing her email address using the
ONE
consistency level. This means the write should be considered a success as soon as one
copy of the data is written durably. When the request completes, we know that
alice
's
new email address has definitely been written to one node, but we don't know whether the
change has propagated to the other two replicas.
If, immediately after writing
alice
's row, we then attempt to read it back, also using
ONE
consistency, we're telling Cassandra that it can read any one of the three copies of the user
row in the cluster, and return that copy to us. For the sake of illustration, suppose that at the
exact moment we try to read the row, the replicas are in the following states:
• Replica 1 is the replica that acknowledged the write request. By definition, it has
the up-to-date email address.
• Replica 2 has also written the updated email address durably.
• Replica 3 has not yet received the updated email address.
By reading with
ONE
consistency, we're saying that we're fine receiving any of the three
replicas' copies of the user row. If the copy we get back happens to come from Replica 1 or
Replica 2, we'll get back
alice
's record with her up-to-date email address. If it comes
from Replica 3, however, we'll get an outdated record with her old address.
