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 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 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, thereby not 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
- 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 protected] if interested.
Later, I will write about multi-statement transactions, and our plans to introduce those.
So they use the “atomic operations” model made famous by MyISAM?
http://dev.mysql.com/doc/refman/5.6/en/ansi-diff-transactions.html
Mark,
A lot of MongoDB’s storage algorithms remind me of MyISAM. In addition to atomic individual operations, they have database level locking for writes, as MyISAM has table level locking, and their primary key, the “id” index, is non-clustering. That said, it’s also important to note that MongoDB does have crash recovery.
They also reproduced the excellent community building done by MySQL. Too bad MyISAM was never made crash safe.
Just a lowly sales guy commenting late but as far as I’m aware the Aria engine in MariaDB is a crash-safe MyISAM. It just needs some friends to play with it
How exactly does Tokutek enable multi-statement ACID transactions for MongoDB? Is Tokutek a replacement for the MongoDB storage layer?
Yes, we completely replace the MongoDB storage layer with fractal tree indexing.
Will this be open-sourced?
Big news announced yesterday, http://www.tokutek.com/2013/04/announcing-tokudb-v7-open-source-and-more/
Does this apply to sharded setups? If not it seems to be of limited use since the point of choosing MongoDB over MySQL is often for its easy sharding ability.
We realize that sharded setups are an important use case for MongoDB users and are currently digging into how sharding will work with fractal trees. We can’t yet comment on how transactions will work with sharded setups. This currently applies to non-sharded setups
To be honest, this is a big improvement even with the sharing proviso. I bet many, if not most workloads have inserts hitting a single shard (much like the recommendation for queries to hit one shard, for latency reasons). Certainly for our workloads, the shard key is nicely orthogonal to the data – so this, in itself would be a great improvement.
Good post…
Thanks, nice post