Hacker News Reader

Comment by cx01 | Hacker News Reader

It's unfortunate, but a lot of people participating in these discussions have no clue. They read that CouchDB claims to support "ACID" and then conclude that it fulfills the C in CAP. Now in reality, CouchDB isn't ACID compliant because it doesn't even support transactions. Additionally the C in ACID is not equivalent to the C in CAP.

Or take a look at this sentence from the article "Consistent, Available (CA) Systems have trouble with partitioning and typically deal with it with replication and sharding.". I assume that instead of "partitioning" he meant "partitions". Even then, partitions can not be dealt with by sharding in any sense. And mentioning "replication" is totally misplaced here because obviously all of these data stores use some kind of replication.

View on HN

"Additionally the C in ACID is not equivalent to the C in CAP."

It would help if the people writing papers about CAP knew what the C in ACID meant before they wrote their papers.

Here is the relevant paragraph from the paper "Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services" Created: 10/08/2003 14:42 http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pd...

"Most web services today attempt to provide strongly consistent data. There has been significant research designing ACID2 databases, and most of the new frameworks for building distributed web services depend on these databases. Interactions with web services are expected to behave in a transactional manner: operations commit or fail in their entirety (atomic), committed transactions are visible to all future transactions (consistent), uncommitted transactions are isolated from each other (isolated), and once a transaction is committed it is permanent (durable). It is clearly important, for example, that billing information and commercial transaction records be handled with this type of strong consistency."

Notice it says "... committed transactions are visible to all future transactions (consistent), ..."

This is not correct because the data can be overwritten by a subsequent transaction.

In this version of the same paper http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.20.... Created: 09/11/2007 01:17 the paragraph is the same except it says

"... transactions never observe or result in inconsistent data (consistent), ..."

If we go back to the people who seem to have coined 'ACID' in this paper "Principles of Transaction-Oriented Database Recovery" Theo Haerder and Adreas Reuter 1983. http://www.minet.uni-jena.de/dbis/lehre/ws2005/dbs1/HaerderR...

We see

"Consistency. A transaction reaching its normal end (EOT, end of transaction), thereby committing its results, preserves the consistency of the database. In other words, each successful transaction by definition commits only legal results."

and later they say

"... a database is consistent if and only if it contains the results of successful transactions. Such a state will hereafter be called 'transaction consistent' or 'logically consistent'. A transaction, in turn, must not see anything but effects of complete transactions (i.e., a consistent database in those parts that it uses), and will then, by definition, create a consistent update of the database."

that is for consistency the trasaction only has to have isolation and to commit consistent results, not 'observe' consistent data. This is because the database up to the point where the transaction starts has been created by a number of committed transactions against an originally empty database. By induction the data the transaction 'observes' must be consistent because the previous transactions have only committed consistent results.

I do not know what the C in CAP means.

> Notice it says "... committed transactions are visible to all future transactions (consistent), ..." > This is not correct because the data can be overwritten by a subsequent transaction.

It seems the paper is completely wrong here. AFAIK the C in ACID means that the integrity constraints in the database will always hold, i.e. no foreign key may reference a non-existing row. This would explain why they changed it in the later version of the paper.

Your reference to the Haerder, Reuter paper is interesting. It seems they kept the definition of consistency pretty vague.

Yes, that seems correct. The Wikipedia entry explained consistency best for me

http://en.wikipedia.org/wiki/ACID#Consistency

which is as you say with the keys for normal databases.

It made clear for me the distinction between application level consistency, the bits that have to be enforced by the program, and database level consistency, which can vary depending on the sophistication of the database, and is enforced by the database. I hadn't really thought about that before. I suppose you could have a database that was less clever and left most of the consistency to the application but still be ACID compliant so long as you defined the scope of the database consistency carefully.

Reply on news.ycombinator.com