Database Administrators Don’t Need to Trip on ACID

Atomicity, Consistency, Isolation, Durability, or ACID, is a set of properties guaranteeing the reliable processing of database transactions, but as new database structures come to the fore, how important is the ACID compliant database structure?

The properties defining a reliable transaction system were aggregated in the 1970s by Jim Gray, but solidified into the ACID acronym in 1983.

The issue revolves around a single logical database operation called a transaction. A series of changes, such as debiting one account and crediting another, constitutes a single transaction in this context.

In parsing the acronym, Kate Ticknor with MarkLogic explains:

“A is for Atomicity: The database must execute the whole transaction and not just part of it — all or nothing.

C is for Consistency: The database must enforce the system rules, e.g., you can’t put a value in a field if that value is not allowed.

I is for Isolation: If multiple transactions are running at the same time they will run independently and the end result will be as if they were executed one after the other.

D is for Durability: Once a transaction is done, it stays done (even if the system crashes thereafter).”

As noted in Wired: “Together, these properties ensure that when you make a change to a database — or a series of changes — those changes are either recorded reliably and permanently or rejected completely.”

ACID is not a pick-and-choose metric. It is, explains Microsoft, “all-or-none propositions designed to reduce the management load when there are many variables.”

The ACID test can help database administrators in many ways, including providing criteria for selecting a database for a project, but it’s also not a necessity. Most products available offer guarantees for ACID transactions, but, Peter Bailis contends, “ACID and NewSQL databases rarely provide true ACID guarantees by default, if they are supported at all.”

Many products, especially NoSQL databases, relax or eliminate some or all of these properties to assure performance. Serialization, for example, is most often mentioned as being an issue. This has also given rise to new concepts and theories, such as the CAP theorem and compensating transactions, that purport to be better suited for specific types of applications in the enterprise.

This begs the question: As structures move away from relational databases to non-relational structures, does ACID remain a valid concern for a wise database administrator as long as the data is being processed in a timely, effective fashion?