This sounds like a CP system to me. There's nothing wrong with that btw, I don't know why people are so reluctant to admit this.
AP systems have some useful properties, but they're also (typically) more difficult to reason about.
The "hiccups" you describe are periods of unavailability. The increased latency is caused by an element of the system waiting for the data to become available again, a totally valid strategy for coping with transient failures/partitions.
Your argument about intra-datacenter partitions being unlikely are true, but they do happen. You also make a good point about such partitions also affecting client applications. Both of these are indicative of CP systems and, like I said: there's nothing wrong with that.
Personally, I think both AP and CP distributed systems are equally interesting. What I consider a red flag is attempting to rationalize how a system "beats CAP".
That's what I was getting at. It's appears to be a CP system. I wish all new distributed databases would have a nice little badge that says, "CP", "AP" or "CA".
Whenever they claim to be distributed but not subject to CAP, I automatically become skeptical.
There's nothing wrong with a CP database; HBase is a CP database and it's quite popular.
To be precise, I would argue this is actually a CA system.
"C" because there are consistency guarantees, which are upheld even in the face of failures / partition.
"A" because the system will continue making progress even after a node failure. What I called a "hiccup" can be made arbitrarily short, in principle at least. The system can work around failed nodes, it does not need to wait for them to be repaired.
Not "P", because if the network falls apart sufficiently, the system will generally not be able to progress.
You cannot guarantee consistency and availability simultaneously in the face of network partitions. Once the line of communications is cut or overloaded (slow enough = a partition), you have to pick one or the other. It's basic physics.
If two entities can't communicate, they can't synchronize state, so one (or both) of them have to quit acting like they have a consistent view of the data.
It's not exactly clear from the paper what CA should mean.
I've seen people claim it means "you guarantee both consistency and availability, as long as there are no network partitions (you don't have to handle those because you haven't chosen P)". That's a supportable claim. So you can do that, but it's kind of a useless choice, because as long as there are no network partitions, both CP and AP systems can also guarantee full consistency and availability.
I lay the CAP family out thus:
* CP: on network partition, lose availability
* AP: on network partition, lose consistency
* CA: on network partition, lose both
It seems to be a common thread among distributed systems engineers who claim to have beaten CAP: "network partitions don't matter for whatever reason, so therefore I can always guarantee both availability and consistency and so CAP must be wrong yaaay!!"
> If two entities can't communicate, they can't synchronize state, so one (or both) of them have to quit acting like they have a consistent view of the data.
With the exception of quantum entanglement, of course.
That blog is quite wrong about partition tolerance. First, the definition is just bizarre:
"Handling a crashed machine counts as partition-tolerance. (Update: I was wrong about this part."
He then goes on to give Stonebraker crap about claiming that "failures" never happen, simply because he doesn't understand the difference between failures and partitions.
Look, the point of "CAP" is this: if you assume nothing about the network, then you can not guarantee CA in the presence of ARBITRARY network partitions. It doesn't say that you can't provide CA under some or even many network partition scenarios. So, the question you should be asking is "what kinds of network partitions happen in practice?". Stonebraker's point was that network partitions are such rare and wholly catastrophic events that worrying about them pulls focus away from much more practical concerns. Hyperdex' point on partition tolerance (admittedly not clearly spelled out) is much more subtle. They offer tolerance of a specific class of partitions. To simply say they are "AP" or "CP" ignores the very important fact that they do in fact tolerate partitions and maintain the CA. This whole "CAP" pick any two is a gross over-simplification that obscures very real distinctions like this.
Comments
This sounds like a CP system to me. There's nothing wrong with that btw, I don't know why people are so reluctant to admit this.
AP systems have some useful properties, but they're also (typically) more difficult to reason about.
The "hiccups" you describe are periods of unavailability. The increased latency is caused by an element of the system waiting for the data to become available again, a totally valid strategy for coping with transient failures/partitions.
Your argument about intra-datacenter partitions being unlikely are true, but they do happen. You also make a good point about such partitions also affecting client applications. Both of these are indicative of CP systems and, like I said: there's nothing wrong with that.
Personally, I think both AP and CP distributed systems are equally interesting. What I consider a red flag is attempting to rationalize how a system "beats CAP".
That's what I was getting at. It's appears to be a CP system. I wish all new distributed databases would have a nice little badge that says, "CP", "AP" or "CA".
Whenever they claim to be distributed but not subject to CAP, I automatically become skeptical.
There's nothing wrong with a CP database; HBase is a CP database and it's quite popular.
To be precise, I would argue this is actually a CA system.
"C" because there are consistency guarantees, which are upheld even in the face of failures / partition.
"A" because the system will continue making progress even after a node failure. What I called a "hiccup" can be made arbitrarily short, in principle at least. The system can work around failed nodes, it does not need to wait for them to be repaired.
Not "P", because if the network falls apart sufficiently, the system will generally not be able to progress.
> Not "P", because if the network falls apart sufficiently, the system will generally not be able to progress.
Not be able to progress means it is not available.
There is no CA.
You cannot guarantee consistency and availability simultaneously in the face of network partitions. Once the line of communications is cut or overloaded (slow enough = a partition), you have to pick one or the other. It's basic physics.
If two entities can't communicate, they can't synchronize state, so one (or both) of them have to quit acting like they have a consistent view of the data.
It's not exactly clear from the paper what CA should mean.
I've seen people claim it means "you guarantee both consistency and availability, as long as there are no network partitions (you don't have to handle those because you haven't chosen P)". That's a supportable claim. So you can do that, but it's kind of a useless choice, because as long as there are no network partitions, both CP and AP systems can also guarantee full consistency and availability.
I lay the CAP family out thus:
* CP: on network partition, lose availability
* AP: on network partition, lose consistency
* CA: on network partition, lose both
It seems to be a common thread among distributed systems engineers who claim to have beaten CAP: "network partitions don't matter for whatever reason, so therefore I can always guarantee both availability and consistency and so CAP must be wrong yaaay!!"
Sorry, no, nice try.
> If two entities can't communicate, they can't synchronize state, so one (or both) of them have to quit acting like they have a consistent view of the data.
With the exception of quantum entanglement, of course.
You don't get to sacrifice the P. http://codahale.com/you-cant-sacrifice-partition-tolerance/
That blog is quite wrong about partition tolerance. First, the definition is just bizarre:
"Handling a crashed machine counts as partition-tolerance. (Update: I was wrong about this part."
He then goes on to give Stonebraker crap about claiming that "failures" never happen, simply because he doesn't understand the difference between failures and partitions.
Look, the point of "CAP" is this: if you assume nothing about the network, then you can not guarantee CA in the presence of ARBITRARY network partitions. It doesn't say that you can't provide CA under some or even many network partition scenarios. So, the question you should be asking is "what kinds of network partitions happen in practice?". Stonebraker's point was that network partitions are such rare and wholly catastrophic events that worrying about them pulls focus away from much more practical concerns. Hyperdex' point on partition tolerance (admittedly not clearly spelled out) is much more subtle. They offer tolerance of a specific class of partitions. To simply say they are "AP" or "CP" ignores the very important fact that they do in fact tolerate partitions and maintain the CA. This whole "CAP" pick any two is a gross over-simplification that obscures very real distinctions like this.