The CAP theorem. The Bad, the Bad, & the Ugly
blog.dtornow.com
The CAP theorem. The Bad, the Bad, & the Ugly
1–10 of 81 posts
Re: The CAP theorem. The Bad, the Bad, & the Ugly
#2The CAP theorem expands to the PACELC theorem. PACELC stands for Partition, Availability, Consistency, Else, Latency, and Consistency. The theorem states that in the event of a network partition, a distributed system must choose between availability and consistency; otherwise, it must choose between latency and consistency.
Re: The CAP theorem. The Bad, the Bad, & the Ugly
#3Whenever I see questions about CAP as a useful thought exercise in distributed systems, it seems to originate from people trying to defend database systems that don't respond well to the realities of partition inevitably.
That is people doing implicit or explicit marketing of some enterprise data landgrab telling you things like they can scale arbitrary SQL joins across distributed tables. Because large data sets do not teleport across the wire for merging.
Foundation db, Cassandra, and kinda dynamo (I don't trust their new global replication) actually scale, but I've never used gcps db techs.
CAP is imo one of the best distributed systems principles ever stated. It is simply state, compare to say the nitty gritty of say paxos vs raft. It is a very useful first principles exercise for deconstructing whatever harebrained claim some marketroid is foisting upon you.
Re: The CAP theorem. The Bad, the Bad, & the Ugly
#4In my opinion this dead horse is beat. Anyone working on distributed systems knows that CAP is not useful in isolation. See Eric Brewer's followup article from 2012: https://www.infoq.com/articles/cap-twelve-years-later-how-th...
Re: The CAP theorem. The Bad, the Bad, & the Ugly
#5In my opinion this dead horse is beat. Anyone working on distributed systems knows that CAP is not useful in isolation. See Eric Brewer's followup article from 2012: https://www.infoq.com/articles/cap-twelve-years-later-how-th...
I had an interview question about it, I tried to cite Kleppmann from the distributed systems book and the interview manager got quite offended.
Re: The CAP theorem. The Bad, the Bad, & the Ugly
#6The CAP theorem expands to the PACELC theorem. PACELC stands for Partition, Availability, Consistency, Else, Latency, and Consistency. The theorem states that in the event of a network partition, a distributed system must choose between availability and consistency; otherwise, it must choose between latency and consistency. https://en.wikipedia.org/wiki/PACELC_theorem
It seems like people make this really complicated.
There will occasionally be network partitions. When there are, a given node can either respond (potentially inconsistently) or not. So you pick some balance between consistency and availability. Latency is really just a proxy for availability - as latency tends towards infinite, availability tends towards zero. Of course you can wait until the network partition is resolved and the nodes are caught up - but I think it's simpler to consider that as not being available for a period of time rather than as having a high latency at that time.
Consistency or Availability - you don't have to pick one, but the more consistent you want to be (in the case of network partitions) the less available you'll be.
Re: The CAP theorem. The Bad, the Bad, & the Ugly
#7The ‘network partitions are not optional’ interpretation of CAP is forgetting about the fact that non-distributed-systems are a thing.
Sure, as soon as you decided to distribute your system across a network you opted into a world where partition can happen, and you will have to give up consistency or availability.
Mainframes, though, provide consistency and availability by being unpartitionable except through use of a chainsaw.
Re: The CAP theorem. The Bad, the Bad, & the Ugly
#8This conflict comes up everywhere:
Newtonian physics/mechanics: good enough in a lot of cases.
Einstein accurate, but unnecessary in most cases.
In many cases CAP is good enough for us to have the conversation about how the system works. One can then formulate plan for when it doesn't. The fact that it's imperfect at a formal level is academically interesting, but technically irrelevant for a LOT of conversations where it has utility.
Re: The CAP theorem. The Bad, the Bad, & the Ugly
#9This conflict comes up everywhere: Newtonian physics/mechanics: good enough in a lot of cases. Einstein accurate, but unnecessary in most cases. In many cases CAP is good enough for us to have the conversation about how the system works. One can then formulate plan for when it doesn't. The fact that it's imperfect at a formal level is academically interesting, but technically irrelevant for a LOT of conversations whe…
Agreed. Sure, you can expand it with PACELC, but the important part is that you have something which starts the conversation/thinking about the fact that distributed systems have specific requirements and challenges. And CAP is sufficient for that.
Re: The CAP theorem. The Bad, the Bad, & the Ugly
#10In my opinion this dead horse is beat. Anyone working on distributed systems knows that CAP is not useful in isolation. See Eric Brewer's followup article from 2012: https://www.infoq.com/articles/cap-twelve-years-later-how-th...
I had an interview question about it, I tried to cite Kleppmann from the distributed systems book and the interview manager got quite offended.
Same, but I actually forgot why he didn't like it, so I didn't.