MongoDB Map-reduce How To Avoid Global Locks

Two important features that drives analytics in MongoDB are:

• Aggregation
• Map-Reduce

In general most of the aggregation framework does not require any global write lock, but Map-reduce needs global write lock when writing reducer results back to existing or new collection.

Since version 2.2, MongoDB added a new variable called nonAtomic, by setting it to true in OUT parameter as shown below, it can skip the global write lock for both merge and reduce OUT operations, but it is not supported for replace operation, even though “replace” is most commonly used MR operation especially when dealing with large record changes.

MongoDB Map-reduce example with all 3 options (replace, merge and reduce)

As you can see from the below MongoDB source code, MongoDB does acquire global write lock “Lock::GlobalWrite lock” when nonAtomic: true is not specified:

That does not end there, as an optimization when existing collection has 0 records, then it simply falls back to replace mode even if one specifies merge or reduce option.

Here is the MongoDB source snippet that does this:

Even though it is a good intention to optimize by removing an empty collection with new one instead of merging/copying the records, but not with the cost of global write lock as it causes much more damage than what it can solve; recently we had enough performance and scalability issues with MongoDB due to global locks; and this is one such case.

Here is the global write lock(W:) on MERGE operation when resulting(mragg) collection did not exist (or empty) in the database from MongoDB log.

Work Around:

One work around is to simply add dummy record to existing collection when it is empty or did not exist and use merge operation, so it can avoid the global lock, for example:

Only problem with merge mode is, if you had any old records from previous aggregation that no more exists in new run, will continue to stay in the resulting collection where as any new or existing records will be inserted and/or replaced. So, one has to decide if they need replace or merge operation.

In general replace is more optimal as it can simply replace the existing collection with new one; and one should still stick to REPLACE mode if changes or resulting collection is very big.

Scalability Issues With Global Locks

Applications can’t scale on large concurrent operations when MongoDB starts acquiring/releasing global locks (read or write) for every major database operation. For example, when it comes to map-reduce “replace” operation, it simply needs to drop/truncate the old collection and create a new one from the results; which should be a simple atomic in updating global namespace.

MySQL had similar issues on meta data locking, but it was addressed from MySQL version 5.5 onwards. Hopefully MongoDB can use the same logic to get around from namespace locking.

Example:

Here is the complete Map-reduce example javascript:

Here is the test output: