Database Reference
In-Depth Information
consistent and not-consistent is not truly reflected in practice. There are instead degreesof con-
sistency, and in the real world they are very susceptible to external circumstance.
Eventual consistency is one of several consistency models available to architects. Let's take a
look at these models so we can understand the trade-offs:
Sttriict c
t consiisttency
This is sometimes called sequential consistency, and is the most stringent level of consistency.
It requires that any read will always return the most recently written value. That sounds per-
fect, and it's exactly what I'm looking for. I'll take it! However, upon closer examination,
what do we find? What precisely is meant by “most recently written”? Most recently to
whom? In one single-processor machine, this is no problem to observe, as the sequence of
operations is known to the one clock. But in a system executing across a variety of geograph-
ically dispersed data centers, it becomes much more slippery. Achieving this implies some
sort of global clock that is capable of timestamping all operations, regardless of the location
of the data or the user requesting it or how many (possibly disparate) services are required to
determine the response.
Causal c
l consiisttency
This is a slightly weaker form of strict consistency. It does away with the fantasy of the single
global clock that can magically synchronize all operations without creating an unbearable
bottleneck. Instead of relying on timestamps, causal consistency instead takes a more semant-
ic approach, attempting to determine the cause of events to create some consistency in their
order. It means that writes that are potentially related must be read in sequence. If two dif-
ferent, unrelated operations suddenly write to the same field, then those writes are inferred
not to be causally related. But if one write occurs after another, we might infer that they are
causally related. Causal consistency dictates that causal writes must be read in sequence.
Weak (e
k (eventtual) c
l) consiisttency
Eventual consistency means on the surface that all updates will propagate throughout all of
the replicas in a distributed system, but that this may take some time. Eventually, all replicas
will be consistent.
Eventual consistency becomes suddenly very attractive when you consider what is required to
achieve stronger forms of consistency.
When considering consistency, availability, and partition tolerance, we can achieve only two of
these goals in a given distributed system (we explore the CAP Theorem in the section
Brewer's
CAP Theorem
)
. At the center of the problem is data update replication. To achieve a strict con-
sistency, all update operations will be performed synchronously, meaning that they must block,
locking all replicas until the operation is complete, and forcing competing clients to wait. A side
