MongoDB MMAPv1 vs WiredTiger storage engines

mongodbmongodb-3.0storage-engine

In mongoDB3 appeared a new storage engine: WiredTiger. ~~Yet, MMAPv1 is still the default choice in Mongo~~.

One might not be better than the other, it's often a matter of use case and choosing the right tool for the job. But which engine is right for what job?

In fact, ~~while MMAPv1 is the default engine,~~ WiredTiger seems better in almost every field. It has the same features as MMAPv1 plus:

better write performance,
document level concurrency,
compression,
snapshots and checkpoints system.

I found a comparing table on MongoDB's blog:

So except if you are on Solaris, is there a reason not to choose WiredTiger?

EDIT

Here are two videos that explain in details the internals of
WiredTiger and MMAPv1.

Best Answer

Personally, I prefer the mmapv1 storage engine as of now for three reasons.

Reason 1: Maturity

It isn't that WiredTiger is immature. But mmapv1 is well understood and battle tested all way up and down, back and forth and above and beyond. WiredTiger has had some serious issues (see http://jira.mongodb.com for details) fairly recently, and I am not willing to have my customers find the next one the hard way.

Reason 2: Features

Given, WT has some f... undamentally awesome features. The thing is: I have not seen anyone benefitting from them. Compression? Either way, you sacrifice rather hard to achieve performance for rather cheap disk space. Lack of the document migration problem for expanding documents? Well, we still have the 16MB size limit and added complexity for embedded documents, especially when embedding is overdone.

There are other features, but in general: I do not see to much benefit from them as of now.

Reason 3: Total cost of ownership

For new projects, WT might be fine, especially since 3.2 , since the following does not apply.

Doing data migrations is expensive. It needs to be planned, the plan needs to be agreed upon by all stakeholders, emergency contingency plans have to be created and agreed upon, the migration needs to be prepared, executed and reviewed. Now multiply the time needed with the stakeholders who are part of this process, and the costs for the data migration skyrocket. The return on investment on the other hand seems rather small. You can scale quite a bit instead of doing a migration if you take those factors into account. To give you an impression: I'd estimate roughly one "man-week" per stakeholder if a migration is planned, executed and reviewed properly. With costs of $100 per hour per person, and only three people involved (manager, DBA and developer), that amounts to $12.000. Note that this is a conservative estimate.

Conclusion

All those factors above have brought me to the conclusion not to use WT whatsoever. At the moment.

Update

This post is some months old now, so it deserves an update

On maturity

My original comments on maturity are sort of obsolete. WiredTiger has not had any major issues for a while now and has become the default storage engine as of MongoDB 3.2

On Features

My original comments still hold some validity, imho.

Compression

However, when being tight on budget or, more generally speaking, performance is not the primary concern, the performance tradeoff is rather small, and you basically trade slight performance impacts (when compared to uncompressed WT) for disk space, utilizing what otherwise would idle around: the CPU.

Encryption

MongoDB 3.2 Enterprise introduced the ability to have WiredTiger storages encrypted. For data with enhanced security needs, this is a killer feature and makes WT the only storage engine of choice, both technically (MMAPv1 does not support encryption) and conceptually. Setting aside the possibility of encrypted disk partitions, of course, although you might not have that option in some environments.

Document level locking

I have to admit that I basically omitted that feature of WT in my above analysis, mainly because it did not apply for me or my customers when I wrote the original answer.

Depending on your setup, mainly when you have many concurrent writing clients, this feature may provide a great performance boost.

On Total cost of ownership

Doing migrations is still expensive. However, taking the changes in maturity and the changed view on the features into account, a migration might be worth the investment if:

You need encryption (Enterprise Edition only!)
Performance is not your absolute primary concern and you can save money in the long run (calculate conservatively) using compression
You have a lot of processes writing concurrently, since the increase in performance might save you vertical or horizontal scaling.

Updated Conclusion

For new projects, I use WiredTiger now. Since a migration from a compressed to an uncompressed WiredTiger storage is rather easy, I tend to start with compression to enhance the CPU utilization ("get more bang for the buck"). Should the compression have a noticeable impact on performance or UX, I migrate to uncompressed WiredTiger.

For projects with a lot of concurrent writers, the answer to wether to migrate or not is almost always "Yes", too – unless the project's budget prohibits the investment. In the long run, the performance increase should pay for itself, if the deployment was otherwise reasonably planned. However, you need add some development time to the calculation, since in some cases the driver needs to be updated, and there might be problems which need to be dealt with.

For projects which are tight on budget and can not afford more disk space for the moment, migrating to a compressed WiredTiger can be an option, but the compression puts a bit load on the CPU, something unheard of with MMAPv1. Furthermore, the migration costs might be prohibitively expensive for such a project.