Is there any NoSQL that is ACID compliant?

Question

Is there any NoSQL that is ACID compliant?

(Or is that even possible with NoSQL given it's just a bunch of loosely coupled key-value pairs.)

Answer 1

IMHO it is an axiom of NoSql that it is not ACID compliant.

To elaborate: it would be possible to extend one to be ACID but in doing so you'd lose most of the reasons for using one in the first place.

So like always it depends on your case. If you're looking for ACID compliance, it would be hard to look away from the more traditional relational databases. Of course, if you have the resources this could be implemented with a system that has a NoSql store for specifiic parts of the system. That is, it might store the user settings or shopping cart before going to the relational database.

Answer 2

"NoSQL" is not a well-defined term. It's a very vague concept. As such, it's not even possible to say what is and what is not a "NoSQL" product. Not nearly all of the products typcially branded with the label are key-value stores.

Answer 3

Well, according to the Wikipedia article on NoSQL:

NoSQL is a movement promoting a loosely defined class of non-relational data stores that break with a long history of relational databases and ACID guarantees.

and also:

The name was an attempt to describe the emergence of a growing number of non-relational, distributed data stores that often did not attempt to provide ACID guarantees.

and

NoSQL systems often provide weak consistency guarantees such as eventual consistency and transactions restricted to single data items, even though one can impose full ACID guarantees by adding a supplementary middleware layer.

So, in a nutshell, I'd say that one of the main benefits of a "NoSQL" data store is it's distinct lack of ACID properties. Furthermore, IMHO, the more one tries to implement and enforce ACID properties, the further away from the "spirit" of a "NoSQL" data store you get, and the closer to a "true" RDBMS you get (relatively speaking, of course).

However, all that said, "NoSQL" is a very vague term and is open to individual interpretations, and depends heavily upon just how much of a purist viewpoint you have. For example, most modern-day RDBMS systems don't actually adhere to all of Edgar F. Codd's 12 rules of his relation model!

Taking a pragmatic approach, it would appear that Apache's CouchDB comes closest to embodying both ACID-compliance whilst retaining loosely-coupled, non-relational "NoSQL" mentality.

Answer 4

take a look at the CAP theorem

EDIT: RavenDB seems to be ACID compliant

Answer 5

If you are looking for an ACID compliant key/value store, there's Berkeley DB. Among graph databases at least Neo4j and HyperGraphDB offer ACID transactions (HyperGraphDB actually uses Berkeley DB for low-level storage at the moment).

Answer 6

VoltDB is an entrant which claims ACID compliance, and while it still uses SQL, its goals are the same in terms of scalability

Answer 7

db4o

Unlike roll-your-own persistence or serialization, db4o is ACID transaction safe and allows for querying, replication and schema changes during runtime

http://www.db4o.com/about/productinformation/db4o/

Answer 8

I'll post this as an answer purely to support the conversation - Tim Mahy , nawroth , and CraigTP have suggested viable databases. CouchDB would be my preferred due to the use of Erlang, but there are others out there.

I'd say ACID does not contradict or negate the concept of NoSQL... While there seems to be a trend following the opinion expressed by dove , I would argue the concepts are distinct.

NoSQL is fundamentally about document-style schema (collected key-value pairs in a "document" model) as a direct alternative to the explicit schema in classical RDBMSs. It allows the developer to treat things asymmetrically, whereas traditional engines have enforced rigid same-ness across the data model. The reason this is so interesting is because it provides a different way to deal with change, and for larger data sets it provides interesting opportunities to deal with volumes and performance.

ACID provides principals governing how changes are applied to a database. In a very simplified way, it states (my own version):

• (A) when you do something to change a database the change should work or fail as a whole
• (C) the database should remain consistent (this is a pretty broad topic)
• (I) if other things are going on at the same time they shouldn't be able to see things mid-update
• (D) if the system blows up (hardware or software) the database needs to be able to pick itself back up; and if it says it finished applying an update, it needs to be certain

The conversation gets a little more excitable when it comes to the idea of propagation and constraints. Some RDBMS engines provide the ability to enforce constraints (e.g. foreign keys) which may have propagation elements (a la cascade). In simpler terms, one "thing" may have a relationship with another "thing" in the database, and if you change an attribute of one it may require the other be changed (updated, deleted, ... lots of options). NoSQL databases, being predominantly (at the moment) focused on high data volumes and high traffic, seem to be tackling the idea of distributed updates which take place within (from a consumer perspective) arbitrary time frames. This is basically a specialized form of replication managed via transaction - so I would say that if a traditional distributed database can support ACID, so can a NoSQL database.

Some resources for further reading:

• Wikipedia article on ACID
• Wikipedia on propagation constraints
• Wikipedia (yeah, I like the site, ok?) on database normalization
• Apache documentation on CouchDB with a good overview of how it applies ACID
• Wikipedia on Cluster Computing
• Wikipedia (again...) on database transactions