Problem with CAP
Fonte: http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html
Autor: Daniel Abadi (Professor of Computer Science at Yale University)
- Como professor de DBMS e estudioso do CAP acha que há uma falha no
Teorema de CAP.
- Baseado na definição de CAP, há 3 tipos de sistemas distribuídos:
- CA: consistent and available, but not tolerant of partitions
- CP: consistent and tolerant of network partitions, but not
available
- AP: available and tolerant of network partitions, but not
consistent
- Problema 1: pesos da influência de C e A em sistemas CP e AP
- Sistemas AP sacrificam a consistência o tempo todo, funcionam
assim.
- Sistemas CP sacrificam a disponibilidade somente quando ocorre um
problema.
- A e C são assimétricos, ou seja, não tem o mesmo percentual de
influência sobre o sistema.
- Problema 2:
- Não há diferença prática entre sistemas CP e CA.
- CP systems give up availability only when there is a network
partition.
- CA systems are “not tolerant of network partitions”.
- But what if there is a network partition? What does “not
tolerant” mean?
- In practice, it means that they lose availability if there is a
partition.
- Hence CP and CA are essentially identical.
- So in reality, there are only two types of systems: CP/CA and AP.
- If there is a partition, does the system give up availability or
consistency?
- Having three letters in CAP and saying you can pick any two does
nothing but confuse this point.
- Problema 3:
- CAP focuses everyone on a consistency/availability tradeoff
- Resulting in a perception that the reason why NoSQL systems give up
consistency is to get availability.
- But this is far from the case. A good example of this is
Yahoo’s NoSQL system PNUTS or Sherpa.
- PNUTS, rather than giving up just one of consistency or availability,
the system gives up both!
- It relaxes consistency by only guaranteeing “timeline
consistency” where replicas may not be consistent with each other
but updates are guaranteed to be applied in the same order at all
replicas.
- However, they also give up availability --- if the master replica for
a particular data item is unreachable, that item becomes unavailable
for updates.
- Why would anyone want to give up both consistency and availability?
CAP says you only have to give up just one!
- The reason is that CAP is missing a very important letter: L.
- PNUTS gives up consistency not for the goal of improving
availability. Instead, it is to lower latency.
- Keeping replicas consistent over a wide area network requires at
least one message to be sent over the WAN in the critical path to
perform the write
- Unfortunately, a message over a WAN significantly increases the
latency of a transaction (on the order of hundreds of milliseconds), a
cost too large for many Web applications that businesses like Amazon
and Yahoo need to implement.
- Consequently, in order to reduce latency, replication must be
performed asynchronously.
- This reduces consistency (by definition). In Yahoo’s case,
their method of reducing consistency (timeline consistency) enables an
application developer to rely on some guarantees when reasoning about
how this consistency is reduced.
- But consistency is nonetheless reduced.
- Conclusion: Replace CAP with PACELC
- To me, CAP should really be PACELC --- if there is a partition (P)
how does the system tradeoff between availability and consistency (A
and C); else (E) when the system is running as normal in the absence of
partitions, how does the system tradeoff between latency (L) and
consistency (C)?
- Systems that tend to give up consistency for availability when there
is a partition also tend to give up consistency for latency when there
is no partition. This is the source of the asymmetry of the C and A in
CAP. However, this confusion is not present in PACELC.
- For example, Amazon’s Dynamo (and related systems like
Cassandra and SimpleDB) are PA/EL in PACELC --- upon a partition, they
give up consistency for availability; and under normal operation they
give up consistency for lower latency. Giving up C in both parts of
PACELC makes the design simpler --- once the application is configured
to be able to handle inconsistencies, it makes sense to give up
consistency for both availability and lower latency.
- Fully ACID systems are PC/EC in PACELC. They refuse to give up
consistency, and will pay the availability and latency costs to achieve
it.
- In conclusion, rewriting CAP as PACELC removes some confusing
asymmetry in CAP, and, in my opinion, comes closer to explaining the
design of NoSQL systems.