Data Transaction Models
This blog explains the two data transaction models, which are known by the acronyms ACID and BASE and briefly touches on the trade-offs in going with either of the approaches of transaction model.
Transaction
In order to understand ACID and BASE properties, we first need to understand a transaction in database context. A transaction in an individual unit of work, which is indivisible i.e. can not be sub-divided into multiple independent transactions and which completes either fully or rolls back in case of failure. Execution of a transaction, both in case of success or failure (i.e. rollbacks), transitions the entire database from one valid state to another.
ACID
ACID refers to 4 key properties of a transaction namely Atomicity, Consistency, Isolation and Durability. If a database system supports there 4 properties, it’s called a transactional system. Following are the characteristics of ACID compliance
Atomicity
It refers to treating all operations performed in a transaction as a single unit. No partial updates are allowed, which means either all operations will succeed or all will be rolled back in case of failure.
ACID compliance databases allow some sort of provisional update, followed by a commit, in order to allow atomicity.
Consistency
Consistency refers to characteristics that a transaction updates should respect other constraints to keep the data in consistent state, before and after transaction. It refers to correctness of the data and ensures that corruption or errors in your data do not create unintended consequences for the integrity of your table.
Isolation
Isolation is the property of a database system such that modifications from one transaction are not affecting operations in another transaction and thus, multiple transactions may run concurrently. This ensures execution of transactions concurrently result in a state that is equivalent to a state achieved when they are executed sequentially.
Durability
Durability ensures that changes made to data by successful transaction execution should get stored in non-volatile memory and should persist even in case of system failure. This is achieved by simply using a storage engine that can store data in an underlying persistent device like SSD.
Why ACID properties are important
ACID properties greatly simplify the job of an application developer. ACID properties ensures that each transaction comprising of a group of operations acts as a coherent unit and leaves the system in a consistent state after execution. ACID compliance offers multiple benefits
Data integrity and Reliability
ACID compliant systems avoids data integrity issues such as lost updates, dirty or stale reads etc. ACID compliance ensures that reads and writes in database are performed reliably and produce consistent result. This means the data will always be accurate and in-line with the constraints imposed on the data.
These data integrity issues are much simpler to address at database level (rather than application level).
Concurrency Control
ACID compliance ensures concurrent access to shared resources and also ensures, such access does not lead to any race conditions.
When transactions with isolation are allowed, database users can consider each transaction as a sequential operation, even though the transactions may have been executed concurrently by the database system. This removed potential for conflict between operations from separate transactions.
CAP Theorem
As databases became distributed in nature, CAP Theorem (an acronym for Consistency, Availability and Partition Tolerance) was introduced for such systems. CAP states that a distributed system can support only two properties. Any horizontal scaling strategy is based on data partition, thus the choice comes between Availability and Consistency.
ACID and CAP are conceptually different though. For eg. CAP’s consistency refers to a shared view of the value of a single data element, that all members of a distributed system are allowed to see. It is better compared against ACID’s isolation levels, both deal with the values that read operations are allowed to see.
On the other hand, ACID’s consistency guarantee covers entire database. Given that a single ACID transaction can span multiple rows and tables, thus the data integrity guarantee has to present a consistent view of entire database, from one valid state to another.
Relational database vendors have introduced 2PC (two-phase commit) for providing ACID guarantees across multiple database instances. 2PC divides the commit phase of transaction in two steps: The transaction coordinator asks each database instance to pre-commit the transaction, which checks if the transaction is possible. In the next step, the transaction is committed.
Having support for operations like 2PC and locking mechanisms, Relational databases favours consistency rather than availability when viewed from CAP Theorem’s perspective. In NoSQL databases, Availability is usually given higher priority than consistency because of the need to handle bigger workloads that doesn’t require real time consistency.
BASE
ACID compliance is a given in monolithic databases. This is because a monolithic database system can be strongly consistent, provide durable storage and can act as a single source of truth for concurrent transactions.
NoSQL databases usually does not support all ACID properties since ACID compliance imposes performance overhead. ACID compliance leans more towards consistency but NoSQL demands availability over consistency which leads to BASE compliance (which is an acronym for Basically Available, Soft state, Eventually consistent).
BASE compliance allows the transactions to be faster and easier to scale.
Basically Available
The system tilts more towards availability. There will be a response for every request.
Soft State
The state of the system could change over time. Due to eventual consistency, the system may be in transition even when no explicit operation is being performed. Hence, the state is always considered to be ‘soft’.
Eventually Consistent
The system will not check for consistency after every transaction is performed (unlike ACID compliant systems) but the system will become eventually consistent once it stops receiving inputs. This means data will propagate to every node (of the distributed system) at some point of time.
Conclusion
BASE compliance has allowed for a more efficient horizontal scaling approach. Eventual consistency gave databases a tool to scale well with increasing workloads, with necessary availability and partition tolerance. Such databases are preferred where millions of requests are served at once.
if an application developer chooses a BASE compliant database system for their application, it is also essential to be familiar with the BASE behaviour of the chosen system and work within those constraints.
On the other hand, ACID compliance is preferred where strict consistency checks are needed for every transaction. Fields such as banking relies on these checks to maintain database integrity at all times.
Planning around BASE limitations can sometimes be a major disadvantage when compared to the simplicity of ACID transactions. A fully ACID compliant database is the perfect fit for use cases where data reliability and consistency are essential.
Thus, there will be tradeoffs in going with either of the approaches. Depending on the use case, you might favour one over the other.
