Stupid Question 109: In computer science, what do we mean by ACID?
Ah yes, transactions. I really don’t mind those ;)
The last few weeks I’ve enjoyed the quirks and surprises by stepping outside my comfort zone and embark on a no .Net what-so-ever project. The project is a node.js project, with express, nano, kendoUI, knockout and of course CouchDB (and whole lot of micro frameworks). Needless to say there has been quite a few discussions. I’ve tried out MongoDB, just a playdate project- and the way I understood it is not truly ACID compliant. Although just a proof of concept app, I wanted to know if CouchDB offered ACID transactions when we decided to use it for storing data. I asked around, and actually found myself having to explain what ACID means. So what do we men by ACID? (And there are alternatives, but that is a different question)
The four letters stand for four properties that we need to guarantee that a transaction in a database is reliable. A transaction is an operation, such as a money transfer- and does not have to be limited to just one account.
Let’s have a look at the words
A – Atomic
All or nothing, either everything gets done or nothing happens. It’s all one unit of work.It’s all or nothing baby.
C – Consistency
All data has to pass through the set of rules defined and be consistent from a valid state to another. Either data is committed or rolled back.Consistency is key!
I – Isolation
Each transaction should be independent of another one, they should be executed in total isolation. Do your thing- and do it on your own.
D - Durability
It’s a forever thing. Once a transaction is done,- it should remain there and the data should not be affected in case of system failure.
As for CouchDB, it does seem like it is ACID compliant. I will have to look at it in details, we don’t really need it for our application, but it just got me curious so why not find out.
Comments
I think you do an excellent job of summarizing what ACID is, but a note important question in these days of NoSql DBs is do we really _need_ acid in all situations? And if not when is it requires and when is it not...also, when might it be actually detrimental to have an ACID compliant data store?
Generally speaking, transactional support is not quite as meaningful in NoSQL databases as they are in relational databases. Typically, relational databases are somewhat misused for general object storage. Since RDBs don't map very well to an object model, a typical object is often mapped to several, possibly many, tables. Transactional support then becomes somewhat critical to ensure that the object is consistent. In a NoSQL database, an object is typically stored in the same "document" or whatever, and proper design can avoid some of the issues using atomic operations that are otherwise handled with transactions. This is the old MySQL-before-transactions-support selling point they used to have. Transactions come at a cost, and are often poorly understood and used. Still, if you need to modify multiple objects (separate collections) and need to make sure that everything is consistent, considerations about how to make sure these are consistent in a case of failure is relevant. But you need to have the full picture then, especially if your service is dispatching requests to other services or storing data in several places which is a common scenario, not only whether a particular storage backend is ACID or not.
are there other database which follows ACID rules?
RavenDB is an ACID NoSQL database that is written in C# and is beautifully easy to use from .NET. See http://ravendb.net for more details.
Last modified on 2012-12-21