 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
The concept of ACID compliance has traditionally been associated with relational databases, leading to misconceptions about its applicability to NoSQL systems. Several reputed sites, such as AWS, assert that NoSQL cannot be ACID compliant. Contrary to these views, ACID (atomicity, consistency, isolation, durability) is not exclusive to relational databases but rather a cornerstone of transaction processing systems.
Let’s explore these misconceptions and why NoSQL databases can — and often do — adhere to ACID compliance.
Early NoSQL systems prioritized performance and availability, frequently relaxing ACID guarantees, which contributed to the perception that NoSQL is inherently non-ACID compliant.
Another significant source of confusion lies in the interpretation of the “C” (consistency) in ACID. Many mistakenly assume it mandates referential integrity constraints, which NoSQL databases typically do not support. However, ACID’s notion of consistency is broader and does not inherently require referential integrity, allowing NoSQL databases to achieve ACID compliance under the right circumstances.
The atomicity, consistency and durability properties were introduced by Jim Gray in his seminal paper on transactions. While the acronym ACID emerged later, the fundamental concepts originated from Gray’s discussion of transaction processing. Notably, Gray’s definition of consistency does not rely on referential integrity constraints specific to relational databases. Instead, it encompasses a broader notion:
“A transaction is a transformation of state that has the properties of atomicity (all or nothing), durability (effects survive failures) and consistency (a correct transformation).”
Jim Gray and Andreas Reuter later define consistency this way:
“A transaction is a correct transformation of the state. The actions taken as a group do not violate any of the integrity constraints associated with the state. This requires that the transaction be a correct program.”
This highlights that ACID is a framework for ensuring correctness and reliability in transaction processing systems, whether relational or not.
Further, Gray and Reuter define a transaction processing system as follows:
“Transaction processing systems (TP systems) manage applications that interact with databases to represent and manipulate real-world states. They often support distributed, heterogeneous environments with stringent availability and performance requirements. Historically, TP systems pioneered concepts like fault-tolerant storage, distributed computation and, most notably, the ACID properties.”
Even pre-relational systems, such as IBM’s Information Management System (IMS) from the 1970s, supported ACID transactions long before the acronym was coined.
ACID compliance can be understood as a set of guarantees provided by various layers within a database system:
| Layer | Purpose |
| Query Layer | Supports query languages like SQL, Cypher, Gremlin, GQL, etc. |
| Transactional Layer | Provides transactional guarantees for operating on multiple records or key-value (KV) pairs. |
| Replication Layer | Provides consistent replica copies across many nodes. |
| Secondary Index Layer | Provides secondary indexes for records stored at a node. |
| Storage Layer | Storage for records or KV pairs at a node. |
These layers illustrate that ACID compliance is a result of coordinated guarantees across the entire database system. In particular, these guarantees are provided by layers below the query language or data model layer, which can add to ACID guarantees by introducing more notions of what integrity constraints this database system has to ensure.
A common source of confusion arises from the dual use of the term “consistency” in ACID and CAP (consistency, availability, partition tolerance). In ACID, consistency refers to the correctness of a transaction’s state transformation with respect to user-defined constraints (such as primary keys, referential integrity). In CAP, consistency denotes uniform data across replicas in a distributed system.
Note that:
The BASE (basically available, soft state, eventual consistency) philosophy emerged alongside NoSQL databases to address the scalability needs of web applications. Early NoSQL systems prioritized availability and partition tolerance, often relaxing ACID guarantees. This distinction led to the misconception that NoSQL databases cannot achieve ACID compliance.
However, the evolution of NoSQL systems has blurred these lines. Many modern NoSQL databases now support:
Several NoSQL databases claim ACID compliance, backed by robust technical implementations. Note, however, that not all of these systems may operate at the strict serializability isolation level. For instance:
These examples demonstrate that NoSQL databases can and do achieve ACID compliance, making them suitable for mission-critical applications.
ACID is not a relic of relational databases but a foundational concept in transaction processing systems. Modern NoSQL databases have evolved to embrace ACID guarantees, challenging the outdated narrative that they are inherently “BASE.” As the database ecosystem continues to innovate, it’s imperative to reframe our understanding of ACID as a property of transactional systems, regardless of the underlying data model.
By dispelling these misconceptions, we can better appreciate the capabilities of NoSQL databases in delivering reliable, consistent and scalable solutions for diverse applications.
Visit our website to learn more about Aerospike Database.
