BT

MongoDB 4.0 to Include Multi-Document Transactions

| by Jonathan Allen Follow 576 Followers on Feb 16, 2018. Estimated reading time: 2 minutes |

Since MongoDB acquired WiredTiger and their relational database storage engine, technologists have been speculating on when MongoDB would support multi-document transactions. With this week’s announcement, the expectation is that they’ll be ready this summer as part of MongoDB 4.0.

Grigori Melnik of MongoDB claims that "80%-90% of applications don’t need multi-document transactions at all" (although this claim could be questionable, as hierarchical databases tend to have a lot of denormalized data that needs to be updated in multiple locations simultaneously to ensure consistency). He goes on to say:

Also, some developers and DBAs have been conditioned by 40 years of relational data modeling to assume multi-table/document transactions are a requirement for any database, irrespective of the data model they are built upon. Others are concerned that while multi-document transactions aren’t needed by their apps today, they might be in the future, and they don’t want to outgrow their database.

Support for multi-document transactions, a cornerstone of ACID, began with MongoDB 3.0. In this version MongoDB gained multiversion concurrency control (MVCC), a technique for snapshot isolation often associated with the PostgreSQL and Oracle relational databases. Recent versions of SQL Server also use MVCC for their "memory-optimized" tables.

MongoDB 3.2 added "read concern" support. Previously clients were given data as it was known to whichever node they were communicating with. The read concern option allowed clients to require that the data be known to the majority of the nodes. Note that according to the documentation, "regardless of the read concern level, the most recent data on a node may not reflect the most recent version of the data in the system.".

MongoDB 3.6 then provided what they refer to as "causal consistency". In prior versions of MongoDB, there was no guarantee that operations occur in a particular order. You could, for example, delete a set of records and then perform a read that would return the very records you just deleted. With causal consistency, you can indicate that the read operation depends on the result of the write operation, thus ensuring that the deletion completed before the read was performed.

Finally, MongoDB 4.0 will offer the ability to perform a consistent read. Which is to say, it will return only the data as it was known at the moment in time that the read operation began. As we explained in the article, A Quick Primer on Isolation Levels and Dirty Reads, previous versions of MongoDB could return results that were not necessarily consistent with any point in time. It could even skip documents or return multiple versions of the same document in a single query.

Developers wishing to experiment with multi-document transactions are encouraged to enroll in the MongoDB 4.0 beta program.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT