The Myths about transactions (ACID) and NoSQL

There have been widespread characterization of one of the major distinctions between NoSQL and traditional DBMSs by saying That's the former don ' t care for ACID semantics or that transactions aren ' t needed. This is a oversimplification to say the least. As long as the NoSQL system supports incremental updates by concurrent set of users (as opposed to only single-threaded bu LK or batch updates), even if multi-api-calls transactions is not supported, at least within the internals of such a Syst Em some notion of transaction is essential to retain a certain level of sanity of the internal design and keep things cons Istent. This was even more important if the system supports replication and/or the updating of multiple data structures within the System even in a single API call (e.g., if there is multiple access paths which has to be updated). Similar points apply to locking and recovery semantics and functionality.

The above sorts of issues is real and were quite tricky to handle in Lotus Notes, which used very ad hoc ways of dealing With the associated complications, until log-based recovery and transaction support were added in R5 (http://bit.ly/LNotes ). From Day 1 in 1989, Notes have supported replication and disconnected operations with the consequent issues of potentially Conflicting parallel updates has to be dealt with. Even RDBMSs were late in dealing with that kind of functionality.

Even if at the individual object level, high concurrency isn ' t important given the nature of a NoSQL application, it might Still be important from the viewpoint of the internal data structures of the "the NoSQL system to" support high concurrency or Fine granularity locking/latching (e.g., for dealing and concurrent accesses to the space management related data structu Res-see http://bit.ly/CMSpMg).

Vague discussions about the NoSQL systems and ACID semantics make many people think that RDBMSs enforce strong ACID Semanti CS all the time. This is completely wrong if by, people imply serializability as the correctness property for handling concurrent EXECU tion of transactions. Even from the very beginning, RDBMSs (System R and products that came from it) has supported different degrees of Isolati On, in some cases even the option of the being able to read uncommitted data, and different granularities of locking (http: BIT.LY/CMQUCC). Even with respect to durability, in-memory RDBMSs like Timeten and SolidDB which came much later, allowed soft commits, et C., trading off durability guarantees for improved performance. 

In my last 2 posts to NoSQL (http://bit.ly/NoSQLt http://bit.ly/NoSQL2), I gave a lot of information on my Backgro und to make it clear to the readers, this whole space of data management are a tricky business. The devil is in the details and it's isn ' t for the faint hearted:-) I wanted to make it clear that I don ' t believe in quick and dirty approaches to handling intrinsically complicated issues And that I am not somebody who takes frequent elevator rides with VCs:-) At the same time, I am not a ivory tower researcher either! When I hear many presentations on "My Kind of topics" at various conferences and meetings like the Hadoop User Group (HUG) , I had a tough time making sense of what was going on given the high level nature of what are being presented with no Seri OUs attempts being made to compare what's proposed with what have been done before and about which more is known. 

Of course, NoSQL systems aren ' t the only context in which such things has happened in the past. A great number of people has talked about optimistic concurrency control and recovery without much of the details really Being worked out (see my discussions on this topic IN HTTP://BIT.LY/CMOPCC). Even now some of the newsql people make some tall claims about what traditional recovery isn ' t needed and that they can get Away without logging while still supporting SQL, etc. One have to quiz them quite a bit to discover that they does in fact does some bookkeeping that they choose isn't to describe as Logging and/or that they don ' t support Statement-level atomicity even though they support SQL and SQL requires it! 

For some people, it might is very tempting to think that the NoSQL applications is so much different from traditional Database applications that simple things is sufficient ("good enough" being the often used phrase to describe such things ) and that overnight mastery of the relevant material is possible. Even in the WEB 2.0 space, if the application programmers is not to go crazy, more of the the burden have to is taken up by th E Designers of the NoSQL systems. A case-in-point was how the Facebook messaging system designers decided eventual consistency semantics was too painful to de Al with. To begin with, if the NoSQL systems has vague semantics of what they support and subsequently, as they evolve, if such th Ings keep changing, users would be is in big trouble! Also, with no standards on place for these systems, if users want to change systems for any number of reasons, application s might require significant rewriting to keep end user semantics consistent over time. 

The Myths about transactions (ACID) and NoSQL