
The confusing CAP and ACID wording - nkeywal
http://thislongrun.blogspot.com/2015/03/the-confusing-cap-and-acid-wording.html
======
AlisdairO
Generally interesting article, so I was struck by the ending:

> Also, the confusion does not only come from the overlaps in the wording, but
> in the necessity to go into the implementation details to understand the
> difference in a real-life concurrent application. In practice, this is one
> of the difficulties that had led many people (me included) to look at the
> ‘NoSQL’ world.

Consistency in database systems is a hard topic because maintaining
consistency in any concurrent system is hard. Traditional systems provide you
with a set of tools (isolation levels, foreign keys) that make a decent
programmer capable of building a safe concurrent application.

Throwing away those tools and replacing them with nothing does not make life
easier. The tool is easier to understand, but the problem is harder to solve.

This is not to say that NoSQL systems do not have a place - of course they do
- but I feel like a lot of people adopting them talk about 'eventual
consistency' while what they maintain is actually inconsistency.

Maintaining consistency in NoSQL systems when the application is nontrivial is
_really_ hard - and if the developer is not up to understanding the locking
model of a traditional DB, I'd be pretty surprised if they were up to working
with an eventually consistent system.

~~~
threeseed
Maintaining strong consistency in some NoSQL databases e.g Cassandra is merely
a config parameter away. Really isn't that hard.

~~~
misframer
Are you talking about the same kind of consistency as the parent post?

~~~
threeseed
There's only one type of consistency in the CAP theorem. The OP is probably
just inexperienced with NoSQL databases since Cassandra, Riak and HBase all
support strongly consistent operations.

~~~
kasey_junk
But there is a second consistency he could be talking about, ie ACID
consistency. Thus the article...

~~~
threeseed
Let me clarify then. Strong consistency = ACID consistency.

If I write the data and then immediately read it I will get the new data under
all circumstances.

~~~
Retric
And ACID DB solves a tiny fraction of consistency issues.

Most of the really difficult problems show up when you have multiple users and
still need consistency.

Granted, ACID databases make solving most of these far simpler.

------
mjb
Very good post. The two meanings of "consistent", and the generally different
ways database literature and distributed systems literature approach the
world, are a really common source of confusion.

One way out of the confusion is to use different words. For example, using
"linearizability", "serializability" and "strict serializability" may cut down
confusion. These terms have complex-sounding names, but generally very
approachable definitions. Aphyr's blog post on different models is a good
place to start: [https://aphyr.com/posts/313-strong-consistency-
models](https://aphyr.com/posts/313-strong-consistency-models)

Another set of terms that approaches a different part of this problem is
Harvest and Yield, which can help explain real-world availability and
consistency ([http://codahale.com/you-cant-sacrifice-partition-
tolerance/](http://codahale.com/you-cant-sacrifice-partition-tolerance/)).
Unfortunately, the original paper just seems to add to the term confusion
([http://brooker.co.za/blog/2014/10/12/harvest-
yield.html](http://brooker.co.za/blog/2014/10/12/harvest-yield.html)).

------
marknadal
Hallelujah somebody wrote this article. I write a distributed database
([http://github.com/amark/gun](http://github.com/amark/gun)) and have
repeatedly gotten into discussions where everybody is confused about ACID.
This article actually takes the time and effort to attempt to delineate
between some of the ideas. Thank you so much, I'll be quoting this in the
future.

------
takeda
>Available: “every request received by a non-failing node in the system must
result in a response” [C2]

This is also confusing to people. It means successful response, you can't for
example respond with an error and claim the system is still available. I've
seen some NoSQL databases claim they were still available because the user was
getting an error message back.

~~~
nkeywal
Yes, I agree. It's not 'eventually consistent' but it's nearly available-in-
CAP.

There are some elements on the CAP definition traps in the first post:
[http://thislongrun.blogspot.com/2015/03/comparing-
eventually...](http://thislongrun.blogspot.com/2015/03/comparing-eventually-
consistent-and-cp_11.html). I also plan to do another post on this subject.

------
eranation
Great article, although I am not an expert in both CAP and ACID, it looks very
reliable to me.

I was surprised this was not mentioned yet:
[http://www.infoq.com/articles/cap-twelve-years-later-how-
the...](http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-
have-changed)

(Eric Brewer revisits the CAP theorem and explains why it's not always a
"black or white" case of "choose only two" triangle...)

~~~
nkeywal
There is a kind of opposition between 'CAP as a theorem' and 'CAP as a tool to
think about distributed systems'. The theorem does not leave much room for
something else than black and white. But in the (great) paper you mention,
there is a lot about "what is the future for distributed systems", it's more
CAP-as-a-tool.

In the post (and in the blog) I stick to the theorem. It's not 'right' or
'wrong', it's a choice. I made this choice because a lot of people are
deciding their trade-offs with CAP-as-a-theorem, while actually CAP-as-a-
theorem cannot be applied to the problem they're working on.

------
grogers
This article also makes it even more complicated by calling the C in CAP
"atomic consistency". While technically correct as that means the same thing
as linearizability, that term is rarely used in comparison. When comparing the
overlapping terms in CAP and ACID it just seems excessive.

~~~
nkeywal
'Atomic Consistency' is used in the CAP proof. YMMV, but I've seen it more
used than 'linearizability' (it's easier to pronounce...). Agreed, there is no
confusion when you use linearizability.

