Database Reference
In-Depth Information
Chapter 3. Mimicking Transactional
Behavior
Relational database schemas often rely on the existence of atomic multistatement transactions
to ensure data consistency: either all of the statements in a group succeed, or all of the state-
ments fail, moving the database from one self-consistent state to another. When trying to scale
relational databases over multiple physical servers, however, transactions must use a two-
phase commit protocol, which significantly slows down transactions that may span multiple
servers. MongoDB, in not allowing multidocument atomic transactions, effectively side-steps
this problem and substitutes another one: how to maintain consistency in the
absence
of trans-
actions.
In this chapter, we'll explore how MongoDB's document model and its atomic update opera-
tions enable an approach that maintains consistency where a relational database would use a
transaction. We'll also look at how we can use an approach known as
compensation
to mimic
the transactional behavior of relational databases.
The Relational Approach to Consistency
One of the goals of relational database normalization is the ability to make atomic changes
to a single row, which maintains the domain-level consistency of your data model. Although
normalization goes a long way toward such consistency enforcement, there are some types of
consistency requirements that are difficult or impossible to express in a single SQL statement:
▪ Deleting a row in a one-to-many relationship should also delete the many rows joined to
it. For instance, deleting an order from the system should delete its subordinate rows.
▪ Adjusting the quantity of a line item on an order should update the order total cost (as-
suming that cost is stored in the order row itself).
▪ In a bank account transfer, the debit from the sending account and the credit into the re-
ceiving account should be an atomic operation where both succeed or both fail. Addition-
