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