NoSQL concepts - Making Sense of NoSQL - page 26

must never change. This is the principle of consistency. It means that your data-
base must never have a report that shows the withdrawal from savings has
occurred but the addition to checking hasn't. It's the responsibility of the data-
base to block all reports during atomic operations. This has an impact on the
speed of a system when many atomic transactions and reports are all being run
on the same records in your database.
 Isolation —Isolation refers to the concept that each part of a transaction occurs
without knowledge of any other transaction. For example, the transaction that
adds funds doesn't know about the transaction that subtracts funds from an
account.
 Durability —Durability refers to the fact that once all aspects of a transaction are
complete, it's permanent. Once the transfer button is selected, you have the
right to spend the money in your checking account. If the banking system
crashes that night and they have to restore the database from a backup tape,
there must be some way to make sure the record of this transfer is also restored.
This usually means that the bank must create a transaction log on a separate
computer system and then play back the transactions from the log after the
backup is complete.
If you think that the software to handle these rules must be complex, you're right; it's
very complex and one of the reasons that relational databases can be expensive. If
you're writing a database on your own, it could easily double or triple the amount of
software that has to be written. This is why new databases frequently don't support
database-level transaction management in their first release. That's added only after
the product matures.
Many RDBMS s restrict transaction location to a single CPU . If you think about the
situation where your savings account information is stored in a computer in New York
and your checking account information is stored in a computer in San Francisco, the
complexity increases, since you have a greater number of failure points and the num-
ber of reporting systems that must be blocked on both systems increases.
Although supporting ACID transactions is complex, there are well-known and well-
publicized strategies to do this. All of them depend on locking resources, putting extra
copies of the resources aside, performing the transaction and then, if all is well,
unlocking the resources. If any part of a transaction fails, the original resource in
question must be returned to its original state. The design challenge is to create sys-
tems that support these transactions, make it easy for the application to use transac-
tions, and maintain database speed and responsiveness.
ACID systems focus on the consistency and integrity of data above all other consid-
erations. Temporarily blocking reporting mechanisms is a reasonable compromise to
ensure your systems return reliable and accurate information. ACID systems are said to
be pessimistic in that they must consider all possible failure modes in a computing
environment. At times ACID systems seem to be guided by Murphy's Law—if anything