Open Framework, Information Management Strategy & Collaborative Governance | Data & Social Methodology - MIKE2.0 Methodology
Wiki Home
Collapse Expand Close

Members
Collapse Expand Close

To join, please contact us.

Improve MIKE 2.0
Collapse Expand Close
Need somewhere to start? How about the most wanted pages; or the pages we know need more work; or even the stub that somebody else has started, but hasn't been able to finish. Or create a ticket for any issues you have found.

Acid compliance Is it Necessary

From MIKE2.0 Methodology

Share/Save/Bookmark
Jump to: navigation, search

ACID stands for atomicity, consistency, isolation, and durability. Compliance to ACID means that a system supports transactions by guaranteeing the full committal of all or no operations in a transaction. This ensures the state of the system is always consistent. In a banking scenario, if I only commit the deposit and the associated withdrawal does not completes, not only is the system inconsistent, but it could be difficult to restore consistency.

Expanding on this (since ACID stands for 4 distinct items, not one), we have… Atomicity – All operations or no operations committed Consistency – The database only has committed transactions Isolation – No views into components of uncommitted transactions Durability – A restore will not bring database back up with incomplete transactions

A significant number of the offerings in the NoSQL and Commercial open source (OSS) camps are fundamentally different from what a Fortune 50 may be used to when it comes to robustness. So is the lack of ACID compliance a fault in the design or is there a time and place for tools short of ACID compliance? This post is inspired by the insights and direction my friend Neil Raden has been promoting in Twitter on this issue. One tweet for example said “@williammcknight It's because they are not tied to the ACID criteria. My suggestion, NoSQL is silly, let's call it DropACID.”

While calling it DropACID instead of NoSQL would give attention to this set of “cons” for the tools, we don’t normally refer to tools by what they don’t have. With the lack of ACID compliance comes some “pros” for the tools as well. For example, there is no locking in MongoDB (con). However, this gives it higher throughput. They just take the highest timestamped data as gospel. You can also change schemas at will, something not do-able when committing (pun intended) to ACID. In a 24 X 7 web world, this is important. Also relational databases, with locking and single masters, cannot guarantee 100% availability, also important in the web 24 X 7 world.

Nearly the entire NoSQL movement has emerged by playing up the benefits of non-ACID compliance (and taking advantage of the speed of development) such that it’s almost by definition that NoSQL is not ACID compliant. I do note that MarkLogic, db4o, VoltDB, BerkeleyDB and CouchDB come closest to ACID compliance and others promote processes and have ACID-light features like “lazy writes” to minimize inconsistencies.

NoSQL includes key-value, document and graph stores. Key-value stores just combine a key name with the value, like a table with 2 columns. Document stores are schema-less and use tree structures to store XML and JSON files and web pages. Graph stores, or triple-stores, extend the key-value concept with a node-link-node relationship structure. Some try to put columnar databases in NoSQL. Although the data is not stored relationally (all columns of the table together), except for a few column stores (Cassandra, HBase, Hypercube), SQL does work against most columnar databases.

The NoSQL movement is brash and plays up the importance of the applications it serves. It serves a different class of applications than has been tapped to-date with relational technologies. While it demonstrates disregard for pre-2011 relational systems, its proponents are careful not to step over the line into areas the technology is not suited for. One way to sum this up is the confession of a leading engineer of a NoSQL product that he wouldn’t use NoSQL for “money.”

Now, before any relational purists run with that, consider that many important applications are not about money. Many today are large scale web applications that need horizontal partitioning (sharding/Dynamo approaches). Large enterprises are where the dollars are and you would not see the NoSQL investment happening if it did not see a play in those accounts. NoSQL will “co-exist” there, creating “not-only” SQL accounts worldwide.

I’m only condoning dropping ACID in the right circumstances.

Wiki Contributors
Collapse Expand Close