This week I attended the NoSQL Now Conference in San Jose, California. This conference focused on NoSQL technology and implementations and a LOT of the discussion focused on transactions and whether or not Big Data and NoSQL databases were at a disadvantage when it comes to their lack of support for ACID (mostly).
You can read all about my experience at this conference on my Data Technology Today blog in the following two posts:
At any rate, though, I got to thinking... and those of you who know me understand that that can be a dangerous thing. Basically, ACID is not a topic that relational folks sit around talking about. It is kind of taken for granted. So I thought it might be a good idea to reinforce the definition of ACID and why it is so important in DB2... and the relational world in general.
ACID is an acronym for atomicity,
consistency, isolation, and durability. Each of these four qualities
is necessary for a transaction to be designed correctly and deliver data integrity when complete:
- Atomicity
means that a transaction must exhibit “all or nothing” behavior. Either all of
the instructions within the transaction happen, or none of them happen.
Atomicity preserves the “completeness” of the business process.
- Consistency
refers to the state of the data both before and after the transaction is
executed. A transaction maintains the consistency of the state of the data. In
other words, after running a transaction, all data in the database is
“correct.”
- Isolation
means that transactions can run at the same time. Any transactions running in
parallel have the illusion that there is no concurrency. In other words, it
appears that the system is running only a single transaction at a time. No
other concurrent transaction has visibility to the uncommitted database
modifications made by any other transactions. To achieve isolation, a locking
mechanism is required.
- Durability
refers to the impact of an outage or failure on a running transaction. A
durable transaction will not impact the state of data if the transaction ends
abnormally. The data will survive any failures.
Let’s use an example to better understand the importance of ACID transactions to relational database applications. Consider a banking application. Assume
that you wish to withdraw $50 from your account with your bank. This business
process requires a transaction to be executed. You request the money either in
person by handing a slip to a bank teller or by using an ATM. When the bank receives the request, it performs the following tasks,
which make up the complete business process. The bank will
- Check your account to make sure you have the necessary
funds to withdraw the requested amount.
- If you do not, deny the request and stop; otherwise
continue processing.
- Debit the requested amount from your checking account.
- Produce a receipt for the transaction.
- Deliver the requested amount and the receipt to you.
The transaction that is run to perform the withdrawal must complete
all of these steps, or none of these steps, or else one of the parties in the
transaction will be dissatisfied. If the bank debits your account but does not
give you your money, then you will not be satisfied. If the bank gives you the
money but does not debit the account, the bank will be unhappy. Only the
completion of every one of these steps results in a “complete business
process.” Database developers must understand the requisite business processes
and design transactions that ensure ACID properties.
Unit of work (UOW)
is another transaction term that describes a physical transaction. A UOW is a
series of instructions and messages that, when executed, guarantees data
integrity. So a UOW and a transaction are similar in concept. However, a UOW is
not necessarily a complete business process—it can be a subset of the business
process, and a group of units of work can constitute a single transaction. Each UOW must possess ACID characteristics. In other words, if the
transaction were to fail, the state of the data upon failure must be consistent
in terms of the business requirements.
To summarize, a transaction—when executed alone, on a consistent
database—will either complete, producing correct results, or terminate, with no
effect. In either case the resulting condition of the database will be a
consistent state.
Hopefully after this discussion it is simple to see why relational databases—with many related tables—rely on ACID properties of transactions to maintain consistency. Of course, the NoSQL world has different use cases and, arguably, can get by with eventual consistency... that is, without ACID. But that is another topic that is, frankly, beyond the scope of this DB2/mainframe-focused blog.
Hopefully, though, this review of ACID and its importance to data consistency was helpful.
