Please stop calling databases CP or AP
martin.kleppmann.com
Please stop calling databases CP or AP
1–10 of 35 posts
Re: Please stop calling databases CP or AP
#2It's natural to reduce things to simple terms. I think CAP theorem caught on because previously people didn't know how to characterize distributed systems in an easy way and this gave them a framework and vocabulary to do it.
It's the same reason why companies create some index in their product (like New Relic AppDex), to take something complex and simplify it so it can be compared.
Re: Please stop calling databases CP or AP
#3very broad theorems like CAP (and e.g. The halting problem) are still very useful for proving things by reduction.
Instead of talking about nodes failing, you could talk about a network partition isolating just that one node (sure, the node might process some things on its own, without input, or not --because it crashed-- but for CAP that is totally out of scope, and part of the underlying algorithm).
Instead of talking about multi object transactions, it talks about anything that implements a register - which includes multi object transaction systems.
CAP therefore shows what real-life trade offs are feasible in the first place ( of course, there are still systems allowed by CAP that might be impossible for other reasons).
Re: Please stop calling databases CP or AP
#4very broad theorems like CAP (and e.g. The halting problem) are still very useful for proving things by reduction. Instead of talking about nodes failing, you could talk about a network partition isolating just that one node (sure, the node might process some things on its own, without input, or not --because it crashed-- but for CAP that is totally out of scope, and part of the underlying algorithm). Instead of talk…
Exactly.
CAP is one of the borders of the space. It's popular because it's relatively easy to look at a claim and see if it's on the "possible" or "impossible" side of the border. Tools like that (as in your halting problem example) are extremely useful, because they can be used to cut through a lot of bullshit masquerading as subtlety.
On the other hand, as OP's post does a good job of explaining, CAP is not a good tool for exploring the area inside the boundary. We often use it to do that, and it leads to all sorts of awkwardness and miscommunication. I think OP captured that well, and it's an area I'd really like to see some alternatives getting popularized (harvest and yield, PACELC, etc). Simplified rules are useful in this space, because while it would be very useful for all practitioners to understand the whole taxonomy, there's a lot of material to understand there.
Re: Please stop calling databases CP or AP
#5very broad theorems like CAP (and e.g. The halting problem) are still very useful for proving things by reduction. Instead of talking about nodes failing, you could talk about a network partition isolating just that one node (sure, the node might process some things on its own, without input, or not --because it crashed-- but for CAP that is totally out of scope, and part of the underlying algorithm). Instead of talk…
My beef with CAP is not that it's so broad, but that it's so narrow. It actually only proves a fairly small class of systems as impossible, and it's kinda obvious. Literature going back to the 1970s suggests that the trade-off was well known back then -- just not under such a catchy name.
Impossibility results are great, but misinterpreting them and using them to argue stuff to which they simply don't apply is not so great.
Re: Please stop calling databases CP or AP
#6The article convinced me that talking about databases as CP or AP is not very useful.
The article did not convince me that CAP-centered thinking is itself harmful or counterproductive. It's true that C-Consistency and A-Availability are relatively blunt definitions in a landscape of diverse and subtle possible semantics. But their usefulness is that they represent our intuitive notions of what a database should do.
If it were possible and had good performance, every single database system would provide C, A, and P, because it would make distributed databases much easier to reason about and program against. Intuitively, it really seems like a database ought to read the data that was most recently written. And it sure would be nice if a distributed database could somehow magically remain available and consistent even in the presence of a partition.
C, A, and P are useful because they are a yardstick against which we can measure a distributed database's actual capabilities against what a distributed database could do in an ideal world. The real world will fall short of that, and the CAP theorem gives a vocabulary for which part(s) of the ideal world real databases cannot satisfy.
For example, even in this article CAP terminology is used to describe interesting edge cases in ZooKeeper which, despite having generally strong consistency guarantees, does not always guarantee full capital-C Consistency.
Re: Please stop calling databases CP or AP
#7I agree. I feel it's time for a better, modern, clear elucidation of these issues- something of which the CAP theorem would be a subset.
And on top of that, I'd love a simple test harness that will run a distributed database thru its paces and produce a report.
Call it Bender, or something and then we can talk about the Bender characteristics and the Bender Report and say "this database passed the Bender report" or "bender found this database fails in this way during partitions: A & B".
This would make it relatively easy to compare systems relatively objectively.
Too often well meaning people have chosen poor databased for production systems (including bitcoin financial transactions companies!) because they didn't understand the issues well enough.
Such an open source project would be open to criticism and improvement and hopefully reasonable objective, and thus take it out of the realm of vendor propaganda and into the realm of broad understanding.
Re: Please stop calling databases CP or AP
#8I agree. I feel it's time for a better, modern, clear elucidation of these issues- something of which the CAP theorem would be a subset. And on top of that, I'd love a simple test harness that will run a distributed database thru its paces and produce a report. Call it Bender, or something and then we can talk about the Bender characteristics and the Bender Report and say "this database passed the Bender report" or "…
Jepson seems to do a lot of what you want in Bender: https://github.com/aphyr/jepsen and https://aphyr.com/tags/jepsen
Re: Please stop calling databases CP or AP
#9I agree. I feel it's time for a better, modern, clear elucidation of these issues- something of which the CAP theorem would be a subset. And on top of that, I'd love a simple test harness that will run a distributed database thru its paces and produce a report. Call it Bender, or something and then we can talk about the Bender characteristics and the Bender Report and say "this database passed the Bender report" or "…
Exactly saying something isn't CA or CP isn't as good as quantifying what happens. Two letters doesn't cut it--show me the numbers.
Re: Please stop calling databases CP or AP
#10What I dislike about articles like this is the author doesn't really talk about what we should be calling databases.
While calling one CP or AP may not correctly capture all the nuance of what those terms really mean it does give the user a quick idea of the capabilities of the database without having to go into a mutli-paragraph technical breakdown.
It's like describing a house as "orange", there are a million shades of "orange" and it might actually be closer to red or yellow but it gives a quick idea of what the house looks like. I feel the description CP and AP does the same, it gives a quick overview of the capabilities and if that interests you, one should be able to dig in deeper to the more technical details.