undefined | Better HN

0 pointsjoncrocks9y ago0 comments

From what I understand of CAP (and I'm no expert by any means), 'partition tolerance' is the ability of a system to reconcile itself in the event of the system being split into partitions.

In these types of scenarios, different sections of the system are still working as normal, and each have a different view of the network of available nodes.

In a scenario where a set of homogeneous nodes in a system is split in two, both are equally 'available' and so the system as a whole has to decide what to do in that scenario. If both sides present themselves as available then they will be making decisions based only on interactions with half of the nodes in the system and their view of the system as a whole will start to drift apart.

This is bad because at the point where they get reconnected again they may well realise that the system as a whole is now not internally consistent. If you think about a distributed database, then you can start to having conflicting commits and now your DB is FUBAR.

You are right in thinking that from the point of view of a partition that it can't know if the rest of the system is just partitioned away or has crashed and will never come back.

But what that simplifying assumption is saying is that if you can ensure that you are much much more likely to have the nodes go down completely rather than actually be partitioned, then things are easy because you don't have to consider diverging system views and how you might re-integrate them.

Or something like that, I ended up writing more than I was planning!

0 comments

6 comments · 1 top-level

oillio9y ago· 5 in thread

Right. My understanding is that the clever bit of CAP is that, from the perspective of a single node, a true network partition is indistinguishable from a bunch of nodes failing simultaneously. If, as a node, you find yourself in a minority network (and cannot make quorum) you need to decide what to do.

Maybe you are on the losing side of a split, and there is a set of nodes out there that can make quorum.

Or maybe 51% of the nodes crashed and what you see is all that is left of the cluster.

Whatever you decide, it has to work for both those possibilities.

So are you interpreting Brewer as saying, in practice we never have a split. Just assume what you see is all there is of the network. However, Spanner is a CP system. If you are willing to assume you will never need to merge inconsistent data, wouldn't you go for AP?

joncrocksOP9y ago

Would have replied sooner, but I had to sleep...

What he's saying is that it's strictly CP, as it will handle partitions (there's a section further down the paper describing how it would be handled). But as P's hardly ever ever happen, because Google, then it's pretty much CA (always consistent and available).

So yes, for all intents and purposes, he's saying "Yeah, CAP does apply but we're so good we can make P 'go away'."

acjohnson559y ago

And what's "quorum" in a system where nodes are free to join and leave?

bdarnell9y ago

There's a lot of complexity here, but the short version is that nodes cannot quite come and go freely. A replica set keeps track of its members; a quorum of the existing members must vote to admit a new node, or to remove one.

Note that in both CockroachDB and Spanner a cluster contains many independent and overlapping replica sets. The data is broken down into "ranges" (to use the terminology of CockroachDB; Spanner calls them "spans"), each of which has its own replica set (typically containing 3 or 5 members).

oillio9y ago

Is the answer, "a really hard problem?"

eternalban9y ago

It is the continuity of 'state' agreed to by a qorum of actors. The identity of these actors is irrelevant.

j / k navigate · click thread line to collapse