Live data from Hacker News

Please stop calling databases CP or AP

martin.kleppmann.com

21–30 of 35 posts

Re: Please stop calling databases CP or AP

#21

Earlier quoted context omitted.

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

P (partition tolerance) refers to network partitions. There's nothing a distributed system can do to prevent network partitions; they're a property of the network. The question is, in the face of partitions, what does the software do? It basically has two options:

* Respond to requests, even though it may not have the most up to date information. I.e., it sacrifices consistency. These are AP systems.

* Not respond to requests, in which case it sacrifices availability. These are CP systems, of which ZK is one.

In particular with ZK, if you lose quorum (i.e., the cluster has fewer than (n + 1) / 2 active nodes where n is the cluster size) the cluster (or partition thereof) will become unavailable in order to avoid sacrificing consistency.

Re: Please stop calling databases CP or AP

#22
It irks me whenever something trying to clarify CAP insists that you can't choose CA. You can. In the real world you can't avoid partitions, but you don't have to tolerate them.

The rule for Availability is that non-failing nodes must respond. If you detect a partition, you can fail the node. Make a system that shuts down when it loses a connection and you can be CA.

Re: Please stop calling databases CP or AP

#23

It irks me whenever something trying to clarify CAP insists that you can't choose CA. You can. In the real world you can't avoid partitions, but you don't have to tolerate them. The rule for Availability is that non-failing nodes must respond. If you detect a partition, you can fail the node. Make a system that shuts down when it loses a connection and you can be CA.

Good point. Is it theoretically possible to guarantee a node shuts down in time the moment partition is detected? What I mean is: isn't there always a small window?

Re: Please stop calling databases CP or AP

#24
post #21

Earlier quoted context omitted.

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.

P (partition tolerance) refers to network partitions. There's nothing a distributed system can do to prevent network partitions; they're a property of the network. The question is, in the face of partitions, what does the software do? It basically has two options: * Respond to requests, even though it may not have the most up to date information. I.e., it sacrifices consistency. These are AP systems. * Not respond to…

So it should be called the CA theorem, right? You can't choose partition-intolerance.

Re: Please stop calling databases CP or AP

#25
post #24
post #21

Earlier quoted context omitted.

P (partition tolerance) refers to network partitions. There's nothing a distributed system can do to prevent network partitions; they're a property of the network. The question is, in the face of partitions, what does the software do? It basically has two options: * Respond to requests, even though it may not have the most up to date information. I.e., it sacrifices consistency. These are AP systems. * Not respond to…

So it should be called the CA theorem, right? You can't choose partition-intolerance.

Non-distributed databases (like postgres) are sometimes considered to be CA. But I think it's clear that CA doesn't make sense in a distributed system.

Re: Please stop calling databases CP or AP

#26
post #11

Earlier quoted context omitted.

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…

Right now I have no clue what a database means by claiming to be AP or CP, if it doesn't refer to the CAP theorem. Right now it seems to mean "We read a blog article about the CAP theorem and don't understand it"

Re: Please stop calling databases CP or AP

#27

It irks me whenever something trying to clarify CAP insists that you can't choose CA. You can. In the real world you can't avoid partitions, but you don't have to tolerate them. The rule for Availability is that non-failing nodes must respond. If you detect a partition, you can fail the node. Make a system that shuts down when it loses a connection and you can be CA.

Maybe I'm missing the point you're trying to make, but a node that's shut down isn't exactly available.

Re: Please stop calling databases CP or AP

#28
post #27

It irks me whenever something trying to clarify CAP insists that you can't choose CA. You can. In the real world you can't avoid partitions, but you don't have to tolerate them. The rule for Availability is that non-failing nodes must respond. If you detect a partition, you can fail the node. Make a system that shuts down when it loses a connection and you can be CA.

Maybe I'm missing the point you're trying to make, but a node that's shut down isn't exactly available.

It's not the one node that shuts down, the whole system flicks a switch and ceases to be. It's incompatible with partitions.

So while you end up with something that's for most purposes worse than CP, it's still a possible configuration.

Availability does not require uptime. It only requires that if you are up, you are fully functional.

Re: Please stop calling databases CP or AP

#29
post #23

It irks me whenever something trying to clarify CAP insists that you can't choose CA. You can. In the real world you can't avoid partitions, but you don't have to tolerate them. The rule for Availability is that non-failing nodes must respond. If you detect a partition, you can fail the node. Make a system that shuts down when it loses a connection and you can be CA.

Good point. Is it theoretically possible to guarantee a node shuts down in time the moment partition is detected? What I mean is: isn't there always a small window?

Depends on what you mean by window.

If you mean a window for that node to act before it realizes there's a partition, your Consistency protocol should prevent that. Anything that requires all nodes to respond should work.

If you mean a window for the node to receive the request, without acting on it, before it fails, that doesn't really matter. From the outside you can't tell the difference between a node that failed before it got your request, and one that failed immediately after. And note this quote:

"Brewer originally only required almost all requests to receive a response. As allowing probabilistic availability does not change the result when arbitrary failures occur, for simplicity we are requiring 100% availability"

Plus, any other interpretation would make node failure fundamentally incompatible with Availability. You will always lose a request that was lodged one nanosecond before node failure.

Re: Please stop calling databases CP or AP

#30

It irks me whenever something trying to clarify CAP insists that you can't choose CA. You can. In the real world you can't avoid partitions, but you don't have to tolerate them. The rule for Availability is that non-failing nodes must respond. If you detect a partition, you can fail the node. Make a system that shuts down when it loses a connection and you can be CA.

This highlights a further asymmetry in CAP. Yes, P is unavoidable if you have a distributed system. But also, availability is a property of the system when there is a partition. If you're not going to tolerate partitions, what does it mean to be available?
Post reply on HN