Another Look at What's New in MongoDB 3.2

As MongoDB 3.2 completes the last yards to the release finish line and MongoDB Inc confusingly pre-announces it has crossed the line, we thought we'd do a quick refresher on what's coming in it, or at least what is coming in the open source version. We build Compose off the open source version of MongoDB and it's also what matters to most MongoDB users.

Not for all

Let's start though with what's not coming in that version, especially as it has been widely promoted in the press: the encryption at rest feature of MongoDB 3.2 is not in the open source version. The ability to encrypt MongoDB documents when they are stored on disk is only available with MongoDB Enterprise, MongoDB Inc's enhanced and pay-for version of MongoDB. The only other core database feature that is an Enterprise version exclusive is language support for Arabic, Farsi, Urdu and Chinese. Outside the core of the database, the Compass schema exploration tool, previously named Scout, is part of MongoDB Inc's commercial offerings. Open source users will have to find, or continue to use, other ways of optimizing their schema.

The aggregated headliners

With the exceptions out of the way, let's talk about what is coming. Back in the summer we took a first look at 3.2 and the features we covered there have all made it to release. MongoDB 3.2 will add the ability to validate documents at insert and update time against a simple expression, partial indexes so you can only index the documents that already meet a particular criteria and the $lookup aggregation function which lets you pull in data from another collection as part of the aggregation process.

Since the article was written, the aggregation functionality has expanded further. There's a new stage, $sample to retrieve a random sample of N documents by scanning, sorting and retrieving the top N documents from a collection. Database aficionados may wish to compare with PostgreSQL's TABLESAMPLE clause coming in version 9.5.

There's also some standard deviation accumulators $stdDevSamp and $stdDevPop. Probably more importantly, there's now a set of new arithmetic expressions (square root, absolute, logs, ceiling and floor) and new array operations, along with many other enhancements in aggregation that will make aggregating a more powerful tool.

Beyond aggregation, there's a new text index behind free text search indexes. The v3 text index is said to offer a wider range of text delimiters, improved case insensitivity and diacritic insensitivity; the latter two being offered as options to the $text search function.

The small stuff

If you've ever tried to model and use bit fields in MongoDB, you will be pleased to see MongoDB 3.2 adding query operators to test if the bits, set using a bitmask, are all set ($bitsAllSet), if any of them are set ($bitsAnySet) and conversely all clear ($bitsAllClear) or any clear ($bitsAnyClear).

In what should be a transparent change to users, MongoDB Inc have switched from the V8 JavaScript engine to the SpiderMonkey engine. This reverses a change made two years ago, but unlike then, there has been no public explanation as to why. Although the change should be transparent, there are some compatibility issues that users should be on the look out for in their own code such as variations in date parsing.

Shell shifts

The MongoDB shell is getting a bit of a coat of paint with many new collection methods being introduced so that the shell is more in line with the general CRUD API specification. These new methods include deleteMany(), deleteOne(), findOneAndDelete(), findOneAndReplace(), findOneAndUpdate(), insertMany(), insertOne(), replaceOne(), updateMany() and updateOne(). They all have existing equivalents, usually by invoking extra options, so in one way this simplifies the command set whilst enlarging it.

Another change, though one that's only noted in the release notes at the moment, is that that Bulk() methods added to the shell in MongoDB 2.6 are now deprecated in favour of a new bulkWrite() command which is likely to model the API version which takes an array of write commands and documents and performs them en masse on the server side.

Storage defaults

With MongoDB 3.2, the WiredTiger storage engine becomes the default for new instances of MongoDB. But that doesn't mean support for the older MMAPv1 engine is going anywhere; WiredTiger demands much more RAM and CPU than MMAPv1. When MongoDB 3.2 starts up with existing data directories, it checks them and automatically runs the storage engine the data was created with. It doesn't try to magically (and dangerously) convert your data in place so exisiting MMAPv1 MongoDB databases will remain MMAPv1 when you run them with 3.2. At Compose, we'll continue offering MMAPv1 MongoDB databases while we continue to look at how to deliver WiredTiger MongoDB in the most cost-effective and sustainable manner.