First Release Candidate for MongoDB 2.8


The MongoDB developers have announced the first release candidate of MongoDB 2.8 and commenced the community “bug hunt” to eliminate issues. Here on the Compose blog we covered what was expected to land in this new release earlier this year and now, as this has solidified into a release candidate, we can see how those expectations have been met.

Storage plugged in

One expected highlight is the arrival of pluggable storage engines and this has landed in the release candidate. More importantly though, the current storage engine, now named MMAPv1 will be joined by a new MongoDB storage engine based on the WiredTiger storage technology.

WiredTiger is a company founded by Dr Michael Cahill and Keith Bostic who previously were architect and founder at Sleepycat, the company behind Berkley DB, acquired by Oracle back in 2006. In 2010, they launched WiredTiger and have been developing their non-locking, high performance, open source storage system since then.

MongoDB isn't making its WiredTiger-based storage engine default yet, but as you’ll see, reading onwards, that is likely to happen in a version after 2.8. The development release notes point out that WiredTiger has a new on-disk format. This means switching engines it will require either a replica set rolling update (as you can mix WiredTiger and MMAPv1 in a replica set) or a performing a mongodump/mongorestore cycle using the old then new storage engine. It can only be hoped that beyond 2.8 and with the wider use of pluggable storage engines that MongoDB Inc come up with a better in-place process such as parallel loading engines to perform migrations.

Concurrency limited

The other expected highlight of 2.8 was improved concurrency with document level locking offering a chance to really enhance the throughput of a busy MongoDB server. Well, document level locking is coming but only with the WiredTiger storage engine and as we have said, that isn’t the default storage engine in 2.8. The MMAPv1 engine has improved its concurrency, moving from database level locking to collection level locking, which will help throughput where there are multiple collections being written to at the same time. But it is a disappointment that the current storage engine isn’t getting document level locking in this release

With the WiredTiger storage engine, that performance improvement should be seen throughout the database, especially with applications with a few highly contended collections. Other improvements tied to WiredTiger include support for on-disk data compression which can be configured on a per collection basis, which means lower disk I/O and a 30%-80% reduction in disk storage use. It also means that CPU usage will go up too when MongoDB 2.8 is working. But that storage engine will need a reasonable time in the field working with production systems before it becomes the default storage engine and those benefits are widely realised.

The release notes also pick up on some other changes. The maximum size of replica sets goes up to 50 now, but there's no increase in the maximum number of voting members (7) in those sets. There's also new query introspection system, the backend to explain(), which provides more statistics to help in working out how your queries are being performed.

At Compose we’ll be looking at all these changes and ensuring that we can bring you all the production-ready features to your databases. For now, its the start of testing and bug hunting.

Dj Walker-Morgan
Dj Walker-Morgan was Compose's resident Content Curator, and has been both a developer and writer since Apples came in II flavors and Commodores had Pets. Love this article? Head over to Dj Walker-Morgan’s author page to keep reading.

Conquer the Data Layer

Spend your time developing apps, not managing databases.