5 ms·
The posted article briefly discusses PACELC and Kleppmann says he doesn't find it any more enlightening than CAP. PACELC is an improvement over CAP in some sen
by maxov 6y ago
The posted article briefly discusses PACELC and Kleppmann says he doesn't find it any more enlightening than CAP.
PACELC is an improvement over CAP in some sense because it is a finer-grained characterization of distributed systems, but it still suffers from the problem that the stated properties are too strong. As Kleppmann explains in the article, there are systems that strictly only fulfill the partition tolerance part of the equation, yet are still very practically useful. This is because while they may not satisfy strict linearizability and availability, they have softer guarantees (e.g. defining "availability" as "99% of requests complete in 1 second") that we can rely on in practice. This reasoning extends to PACELC as well.
I am inclined to agree with Kleppmann. CAP, and by consequence PACELC are useful mental models in the extreme, but their characterizations are really strong. It seems to me that e.g. probabilistic guarantees based on actual failure statistics are much more useful for the real world, because they aren't as strong as CAP/PACELC guarantees.
Edit: I am also not sure if I agree with calling CAP "dumb". It's a very useful theoretical result in a particular model. I think the problem is when people try to extend the implications of the theorem beyond the restricted model it operates in.
- georgewfraser 6y agoKlepmann is a wannabe thought-leader, who repackages old ideas into pseudo-profound “insights”, designed to capture the attention of amateurs rather than move the state of the art forward. He’s the Nassim Taleb of distributed systems. If you’re looking for enlightenment, read Daniel Abadi or Andy Pavlo.
- maxov 6y agoThat seems really unfair to Kleppmann. I know of all three, and all three are, at the very least, accomplished distributed systems researchers with several peer-reviewed publications. (They still have different levels of expertise/publications depending on the area, of course) In a different arena, I also know of no better book at the interface of distributed systems theory and practice than Kleppmann's. It's useful for engineers while being enriched by deep references to the literature. If that doesn't demonstrate mastery, I don't know what does.
- georgewfraser 6y agoOK, my comment was over the top, apologies to Kleppmann if you’re still reading. He is a thought leader, and he’s the first introduction to distributed systems for a lot of people, and sometimes people stop with his work and don’t learn how much depth this field has. But that’s not really a criticism of him. And nobody should be compared to Nassim Taleb, I was clearly letting the heat wave get to me ;)
- kronski 6y agoTo anyone cutting their distributed-systems teeth on Kleppmann's excellent Designing Data-Intensive Applications: each chapter ends with an essential references section (which include multiple citations to Abadi and Pavlo!). The book chapters do an solid job laying the ground-work for those papers. The depth is in those references. Read them if you can!
- srtjstjsj 6y agoAre you proposing a KAP theorem, that we can't have all of Klepman, Abadi, and Pablo?
- georgewfraser 6y agoYES!
- barbecue_sauce 6y agoI like Kleppmann, but I also like Pavlo. I have only seen Pavlo's database courses on YouTube, though. Does he have any books?
- georgewfraser 6y agoNot that I know of. His lectures are amazing though.
- rubiquity 6y agoAnd what does that make you, exactly?
- teej 6y agoI've lost a lot of respect for you after this comment.
- deleted 6y ago[deleted]
- TechBro8615 6y agoI feel like if you’re the CEO of a (barely) unicorn startup, you shouldn’t be making comments like this.
- vii 6y agoIt's not surprising that a simple theorem doesn't deal with practical trade-offs. In my experience if you feel you are running up against the CAP theorem you need to take a moment to think about the real needs of your application and looking for a more detailed theorem isn't going to guide you well, instead you need to think about what you actually want to happen when various kinds of failure occur. In finance for example, often trading systems will choose to be available and accept transactions when there is a failure and then reconcile afterwards - swapping the risk of making mistakes but in a trusted environment to prevent the potentially catastrophic condition of not being able to trade. The article claims that the CAP theorem only prohibits linearisability as a consistency model. The original CAP paper talks about "Atomic consistency" which is clearly at least linearisability. However as the proof formalizes, it's obvious that if you accept writes to totally split and separated systems which cannot communicate together (network partition), you cannot be consistent across the two parts. This is confusing because this kind of consistency only loosely matches the definitions in the ACID acronym which are geared around invalid database states in a single machine database, not about different requests to different database machines giving inconsistent answers. Linearizability versus serialisability (and strict serialisability) are explained well by Peter Bailis http://www.bailis.org/blog/linearizability-versus-serializability/ http://www.bailis.org/blog/linearizability-versus-serializab...
- maxov 6y agoThat link is really great, thanks! I was actually looking for a clear comparison between consistency definitions. I did not realize that consistency and atomicity also are overloaded between databases and distributed systems. That certainly adds to the confusion! I must have missed it when reading the original article. More real-world experience is also really valuable, and an application-first approach to handling distributed systems works really well. I guess my hope is that eventually the theory becomes robust, matching the real world enough so that we won't have the problems of mis-applied theorems. IMO the best theories are intuitive and help us expose holes we could not catch in the real world.
- 1DRACOSEA8 6y agoCap’n’Protos has time traveling gRPCs to fiddle with the payload, the grace period, and retry’s a server does when unresponsive; in some ways, I liken them to futures with locks.