Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Yes, MongoDB is Transactional

DZone's Guide to

Yes, MongoDB is Transactional

· Java Zone
Free Resource

Build vs Buy a Data Quality Solution: Which is Best for You? Gain insights on a hybrid approach. Download white paper now!

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

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

Build vs Buy a Data Quality Solution: Which is Best for You? Maintaining high quality data is essential for operational efficiency, meaningful analytics and good long-term customer relationships. But, when dealing with multiple sources of data, data quality becomes complex, so you need to know when you should build a custom data quality tools effort over canned solutions. Download our whitepaper for more insights into a hybrid approach.

Topics:

Published at DZone with permission of Zardosht Kasheff, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}