EmergencyEMERGENCY? Get 24/7 Help Now!

MongoDB Transactions? Yes

 | April 2, 2013 |  Posted In: Tokutek, TokuView


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 zardosht@tokutek.com if interested.

Later, I will write about multi-statement transactions, and our plans to introduce those.



    • 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.

    • 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.

Leave a Reply