Database Reference
In-Depth Information
ACID is an acronym for Atomic, Consistent, Isolated, Durable, which are the gauges we can use
to assess that a transaction has executed properly and that it was successful:
Attomiic
Atomic means “all or nothing”; that is, when a statement is executed, every update within the
transaction must succeed in order to be called successful. There is no partial failure where
one update was successful and another related update failed. The common example here is
with monetary transfers at an ATM: the transfer requires subtracting money from one ac-
count and adding it to another account. This operation cannot be subdivided; they must both
succeed.
Consiisttentt
Consistent means that data moves from one correct state to another correct state, with no
possibility that readers could view different values that don't make sense together. For ex-
ample, if a transaction attempts to delete a Customer and her Order history, it cannot leave
Order rows that reference the deleted customer's primary key; this is an inconsistent state
that would cause errors if someone tried to read those Order records.
Isollatted
Isolated means that transactions executing concurrently will not become entangled with each
other; they each execute in their own space. That is, if two different transactions attempt to
modify the same data at the same time, then one of them will have to wait for the other to
complete.
Durablle
Once a transaction has succeeded, the changes will not be lost. This doesn't imply another
transaction won't later modify the same data; it just means that writers can be confident that
the changes are available for the next transaction to work with as necessary.
On the surface, these properties seem so obviously desirable as to not even merit conversation.
Presumably no one who runs a database would suggest that data updates don't have to endure
for some length of time; that's the very point of making updates—that they're there for others
to read. However, a more subtle examination might lead us to want to find a way to tune these
properties a bit and control them slightly. There is, as they say, no free lunch on the Internet, and
once we see how we're paying for our transactions, we may start to wonder whether there's an
alternative.
Transactions become difficult under heavy load. When you first attempt to horizontally scale
a relational database, making it distributed, you must now account for distributedtransactions,
where the transaction isn't simply operating inside a single table or a single database, but is spread
