Database Reference
In-Depth Information
This is a temporary state of affairs: eventually, Replica 3 will also get the update, and at
that point we will get the latest copy of the data regardless of which replica serves the re-
quest. But we don't know when that will be: when we read and write data using consisten-
cy level
ONE
, we are in a scenario of eventual consistency.
On the other hand, by using consistency level
ONE
, we're very resilient to failure. Even if
two of the three machines that hold copies of
alice
's user record are unavailable, Cas-
sandra can still successfully fulfill requests at this consistency level using the one healthy
machine. As long as we're willing to give up immediate consistency, we can sleep very
soundly knowing that our application will continue working even in the case of a multi-
node hardware failure.
Eventual consistency is also beneficial for performance. When reading or writing data at
ONE
consistency, Cassandra doesn't only send the request to one replica; instead, it sends
the request to all the interested replicas, and then fulfills the request as soon as the first
one responds successfully. So the time it takes to service a request at
ONE
consistency is
bounded by the fastest node to respond.
Immediate consistency with ALL
In many scenarios, however, eventual consistency is unacceptable.
alice
may be using
the MyStatus web interface to update her email address. After submitting the form with
her updated information,
alice
's browser is redirected to a page where she can view her
profile. At this point, the web application will need to read the profile data from Cas-
sandra; if it happens to read from an out-of-data replica, it will appear to
alice
that her
email address was not actually updated.
At the other end of the consistency spectrum from
ONE
lies the
ALL
consistency level. At
this level, all interested replicas must respond successfully in order for the request to be
considered a success. If we update
alice
's email address with the
ALL
consistency, our
UPDATE
query won't complete successfully until the new email address has been written
durably to all three replicas. As soon as the request completes, we know that all copies are
up-to-date.
Similarly, if we read the row back with the
ALL
consistency, Cassandra will read all three
replicas' copies of her user record, and compare their timestamps. If the data is different
on different replicas, Cassandra will return the copy with the most recent timestamp, en-
suring that we are getting the most recently written copy of the row.
