People claim that MongoDB is not transactional. It actually is, and that’s a good thing.
In MongoDB 2.2, individual operations are Atomic. By having per database locks and control reads and writes to collections, write operations on collections are Consistent and Isolated. With journaling on, operations may be made Durable. Put these properties together, and you have basic ACID properties for transactions.
The shortcoming with MongoDB’s implementation is that these semantics apply to individual write operations, such as an individual insert or individual update. If a MongoDB statement updates 10 rows, and something goes wrong with the fifth row, then the statement will finish execution with four rows updated and six rows not updated.
Running MongoDB with Fractal Tree Indexes (used today in the MySQL storage engine TokuDB) is fully transactional. Each statement is transactional. If an update is supposed to modify ten rows, then either all rows are modified, or none are. Queries use multi-versioning concurrency control (MVCC) to return results from a snapshot of the system, preventing them from being affected by write operations that may happen concurrently.
Here are some benefits:
- The state of the system after a failed command is well-defined. Nothing is applied.
- Users that run queries requiring calls to getMore will have the results come from a consistent snapshot
- The clone command will clone a consistent snapshot of the data
From what we can tell, users want this.
Do you want to participate in the process of bringing full transactions to MongoDB? We’re looking for MongoDB experts to test our build on your real-world workloads. Evaluator feedback will be used in creating the product road map. Please email me at email@example.com if interested.
Later, I will write about multi-statement transactions, and our plans to introduce those.