Database Reference
In-Depth Information
partition. Therefore, and since partitions are rare, designers should consider other
tradeoffs that are, arguably, more important. A tradeoff that is more influential, is
the latency-consistency tradeoff. Insuring strong consistency in distributed systems
requires a synchronized replication process where replicas belong to remote nodes
that communicate through a network connection. Subsequently, reads and updates
may be costly in terms of latency. This tradeoff is
CAP-Independent
and
exists per-
manently. Moreover, Abadi
makes a connection between latency and availability.
When latency is higher than a specific timeout the system becomes unavailable.
Similarly, the system is available if the latency is smaller than the timeout. However,
the system can be available and exhibit high latency nonetheless. For these reasons,
system designers should consider this additional tradeoff along with
CAP
.
Abadi
proposes to unify the two in a unified formulation called
PACELC
where
P AC
refers to the
A
(availability) and
C
(consistency) tradeoff
if
a partition
P
exists, and
ELC
refers to
else
(
E
), in the absence of partitions, the latency
L
and consistency
C
tradeoff should be considered.
After they proved the
CAP
theorem, Gilbert and Lynch reexamined the theorem
properties and its implications [16]. The tradeoff within
CAP
is another example
of the more general tradeoff between
safety
and
liveness
in unreliable systems.
Consistency can be seen as a
safety
property for which every response to client
requests is correct. In contrast, availability is a
liveness
property that implies that
every client request would eventually receive a response. Hence, viewing
CAP
in the
broader context of safety-liveness tradeoffs provides insight into the feasible design
space for distributed systems [16]. Therefore, they reformulate the
CAP
theorem as
follows: “CAP states that any protocol implementing an atomic read/write register
cannot guarantee both safety and liveness in a system prone to partitions.” As a
result, the practical implications dictate that designers opt for best-effort availabil-
ity, thus guaranteeing consistency, and best-effort consistency for systems that must
guarantee availability. A pragmatic way to handle the tradeoff is by balancing the
consistency-availability tradeoff in an adaptive manner. We will further explore this
idea in Section 10.5.
10.3 CONSISTENCY MODELS
In this section, we present multiple consistency models. For every model, we show
its specified guarantees to provide consistency at the system side. Eventually, and
considering the strength level of these guarantees, we discuss the potential solutions
to manage updates conflict situations. The consistency models are then summarized
in Table 10.1.
10.3.1 s
trong
C
onsistenCy
In traditional distributed storage and database systems, the instinctive and correct
way to handle replicas consistency was to insure a strong consistency state of all
replicas in the system at all time. For example, the RDBMs were based on ACID
semantics. These semantics are well defined and insure a strong consistency behav-
ior of the RDBM based on the atomicity and consistency properties. Similarly, the
Search WWH ::
Custom Search