Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Please stop calling databases CP or AP

martin.kleppmann.com

Post reply on HN
Print view View original

11–20 of 35 posts

Re: Please stop calling databases CP or AP

#11

Post by aidenn0 »

jellofiend84 wrote: post #10

What 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 shade…

Nearly no distributed databases are either CP or AP in their default configuration, and CP and AP have very specific meanings, so it's more like saying a house is Pantone 300[1], when it's really some shade of cyan.

1: http://www.pantone.com/pages/pantone/colorfinder.aspx?c_id=6...

Re: Please stop calling databases CP or AP

#12

Post by martinkl »

jellofiend84 wrote: post #10

What 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 shade…

There are some pointers to better terminology at the end of the post — e.g. I like Terry's session guarantees (read-your-writes, monotonic reads, etc) — but they too only cover a small subset of the design space.

In the end, this stuff is still evolving, and we simply don't yet know the best way of describing things. I wouldn't want to propose some alternative classification scheme that would be no better than the one it replaces. But I do want to encourage people to be precise and thoughtful with the terminology they use.

Re: Please stop calling databases CP or AP

#14

Post by seliopou »

haberman wrote: post #6

The 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. I…

> 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.

I duno, I think the two major points of the article were: 1. CAP-centered thinking can be harmful or counterproductive; and 2. by virtue of the fact that most traditional database systems don't fall into CP/AP categories, maybe those categories don't really have much to do with what we expect of databases. One could go a step further and make a case that 1 and 2 imply that CAP-centered thinking for many use-cases is harmful or counterproductive.

But I'm not gonna do that here. I do not want that hot potato.

Re: Please stop calling databases CP or AP

#15

Post by jellofiend84 »

martinkl wrote: post #12
jellofiend84 wrote: post #10

What 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 shade…

There are some pointers to better terminology at the end of the post — e.g. I like Terry's session guarantees (read-your-writes, monotonic reads, etc) — but they too only cover a small subset of the design space. In the end, this stuff is still evolving, and we simply don't yet know the best way of describing things. I wouldn't want to propose some alternative classification scheme that would be no better than the on…

I agree with most everything you've said, but until we have good concise descriptions I think it is unfair to really say: "Never use these".

Quick less-precise overviews serve a real purpose and are very helpful to users and decision makers.

I guess my opinion is projects should never ONLY say it is CP or AP, but I think it is perfectly acceptable in your project overview to say: This database is CP*. Then have a longer technical discussion somewhere else where they use more precise and thoughtful language.

I understand and agree with the sentiment, but we humans need fuzzy short overviews. Then again a blog post titled: "All databases need an in-depth technical discussion page" doesn't quite capture the imagination.

Re: Please stop calling databases CP or AP

#16

Post by tracker1 »

haberman wrote: post #6

The 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. I…

It really depends on the amount of writes your database needs to handle, and the overall quantity of data. There are very strong CAP systems (Zookeeper comes to mind), but I wouldn't want that for very large quantities of data, as it wouldn't be able to keep up.

For example, if you are doing logging for a few million simultaneous users (say 5-8 per resource request across service layers), a single system wouldn't be able to keep up, and definitely a single system that has to coordinate each write as an atomic/consistent state.

The fact is, depending on your needs, you will need to sacrifice something to reach a scale needed by some systems and to minimize down time. It's a trade-off. And any distributed database will have real-world weaknesses.

Re: Please stop calling databases CP or AP

#17

Post by jellofiend84 »

aidenn0 wrote: post #11
jellofiend84 wrote: post #10

What 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 shade…

Nearly no distributed databases are either CP or AP in their default configuration, and CP and AP have very specific meanings, so it's more like saying a house is Pantone 300[1], when it's really some shade of cyan. 1: http://www.pantone.com/pages/pantone/colorfinder.aspx?c_id=6...

Definitions are flexible and communities collectively decide what words actually mean. Sure if you are talking to PhD Data Scientists CAP have incredibly specific meanings.

I think it is clear that the much broader user/marketing/coder community has a much less rigid definition of these terms. In my opinion, fighting against terms or ideas getting watered down is a lost cause. It inevitably happens and there is very little that can be done to stop it.

As I said in another reply really the battle cry should be something along the lines of "Every database needs a real thoughtful precise technical breakdown" not "Stop using terminology that gives a brief, if imprecise, overview of the product". Because the later is almost certainly not going to happen.

Re: Please stop calling databases CP or AP

#18

Post by haberman »

tracker1 wrote: post #16
haberman wrote: post #6

The 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. I…

It really depends on the amount of writes your database needs to handle, and the overall quantity of data. There are very strong CAP systems (Zookeeper comes to mind), but I wouldn't want that for very large quantities of data, as it wouldn't be able to keep up. For example, if you are doing logging for a few million simultaneous users (say 5-8 per resource request across service layers), a single system wouldn't be…

> There are very strong CAP systems

There are not strong CAP systems -- that is the whole point of the CAP theorem. It's impossible. Am I misunderstanding you?

Re: Please stop calling databases CP or AP

#19

Post by antirez »

The article is good, however probably there is some issue here: "so quorum operations are not CAP-available (at least temporarily, until the database sets up additional replicas on the minority side)."

Availability is an eventual property, so technically speaking if the minority partition within a non-infinite amount of time always recovers and is able to provide a reply for our query, it is Available from the POV of CAP. However this requires the DB to be always able to create new replicas in the minority side and eventually reply to the query, and I'm not sure this is the case in Dynamo-alike systems when there is a single-node partition.

Re: Please stop calling databases CP or AP

#20

Post by GauntletWizard »

haberman wrote: post #18
tracker1 wrote: post #16

Earlier quoted context omitted.

It really depends on the amount of writes your database needs to handle, and the overall quantity of data. There are very strong CAP systems (Zookeeper comes to mind), but I wouldn't want that for very large quantities of data, as it wouldn't be able to keep up. For example, if you are doing logging for a few million simultaneous users (say 5-8 per resource request across service layers), a single system wouldn't be…

> There are very strong CAP systems There are not strong CAP systems -- that is the whole point of the CAP theorem. It's impossible. Am I misunderstanding you?

No, zookeeper doesn't do magic. It does, however, create a large enough value for P to be lost that it can be thought of as CAP; The number of failures required is high enough that, in normal use and sane configurations, you won't partition.
Post reply on HN