3 ms·

tl;dr. "Eventual consistency" is a b.s. marketing term that actually has nearly no meaning. The easiest way to see just how empty the definition is, is by nega

tl;dr. "Eventual consistency" is a b.s. marketing term that actually has nearly no meaning. The easiest way to see just how empty the definition is, is by negating it and seing what undesirable property a system would have to have in order to fail to be eventually consistent. Take the definition from wikipedia: "Given a sufficiently long period of time over which no changes are sent, all updates can be expected to propagate eventually through the system and all the replicas will be consistent." Negation: "No matter how long you wait without sending changes, updates may not propagate through the system, and disagreement may continue to exist between replicas indefinitely." So basically, saying that something is "eventually consistent" just means "we won't completely ignore you forever". Great.

pbailis 15y ago
Eventual consistency is definitely weak, but it's useful: if we couple eventual convergence with safety properties, then we can describe non-trivial properties. The problem, which I alluded to in my first footnote, is that it's hard to guarantee anything stronger than eventual in the presence of partitions. If you want to make sure your system behaves "correctly" under arbitrary partitioning, you necessarily have to admit the trivial cases. What you also want to guarantee is that, in the absence of partitions, the system still "does the right thing"; this often gets lost in the definition of eventually consistent systems, which is why you should consider both safety and liveness.
- jf271 15y ago
  If you completely understand the weaknesses of eventual consistency you will use is only where it is viable and the risk is justified. There is a reason the relational databases haven't gone away completely.
  - pbailis 15y ago
    As a shameless plug, I might add that if you can model your network delays, you can use some modeling like our work on PBS (Probabilistically Bounded Staleness) to predict staleness: http://pbs.cs.berkeley.edu/#demo http://pbs.cs.berkeley.edu/#demo I'd also add that the consistency related to ACID semantics from relational databases refers to transactional consistency, not replica consistency. Indeed, distributed RDBMSs often opt for strong (replica) consistency models, but there is no reason a distributed relational database can't be weakly (replica) consistent while maintaining ACID semantics on a single machine. Moreover, if the RDBMS must needs to be available in the presence of partitions, it must be weakly (replica) consistent.
Dylan16807 15y ago
The problem isn't really the term "eventual coincistency" but rather neglecting to define "sufficient time", which needs to be done case-by-case. Something like "ram size divided by the slowest connection between servers, plus 40% margin". That gives you a useful and predictable model that even handles partitions (treat as speed 0).

pbailis 15y ago

Eventual consistency is definitely weak, but it's useful: if we couple eventual convergence with safety properties, then we can describe non-trivial properties. The problem, which I alluded to in my first footnote, is that it's hard to guarantee anything stronger than eventual in the presence of partitions. If you want to make sure your system behaves "correctly" under arbitrary partitioning, you necessarily have to admit the trivial cases. What you also want to guarantee is that, in the absence of partitions, the system still "does the right thing"; this often gets lost in the definition of eventually consistent systems, which is why you should consider both safety and liveness.

jf271 15y ago
If you completely understand the weaknesses of eventual consistency you will use is only where it is viable and the risk is justified. There is a reason the relational databases haven't gone away completely.
- pbailis 15y ago
  As a shameless plug, I might add that if you can model your network delays, you can use some modeling like our work on PBS (Probabilistically Bounded Staleness) to predict staleness: http://pbs.cs.berkeley.edu/#demo http://pbs.cs.berkeley.edu/#demo I'd also add that the consistency related to ACID semantics from relational databases refers to transactional consistency, not replica consistency. Indeed, distributed RDBMSs often opt for strong (replica) consistency models, but there is no reason a distributed relational database can't be weakly (replica) consistent while maintaining ACID semantics on a single machine. Moreover, if the RDBMS must needs to be available in the presence of partitions, it must be weakly (replica) consistent.

Dylan16807 15y ago

The problem isn't really the term "eventual coincistency" but rather neglecting to define "sufficient time", which needs to be done case-by-case. Something like "ram size divided by the slowest connection between servers, plus 40% margin". That gives you a useful and predictable model that even handles partitions (treat as speed 0).