3 ms·
Eventual consistency is definitely weak, but it's useful: if we couple eventual convergence with safety properties, then we can describe non-trivial properties.
by 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 agoIf 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 agoAs 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.