If you’ve been looking forward to use the latest MongoDB release on the Scalingo platform, we have good news for you. We’ve just turned on the ability to upgrade to MongoDB 3.2. From now on, provisioned MongoDB addon will run this version with WiredTiger enabled. Of course, we didn’t forget existing customers. We’ve setup a smooth upgrade path to this new version.
It only takes a few seconds, sign up on the platform, create an application, choose MongoDB addon and that’s it, your new and shiny MongoDB 3.2 database has been provisioned, this is the new default version of the addon, you’ve nothing special to do.
Go in your database dashboard (from the addons page of your app dashboard), and an upgrade card will be available. Upgrading to MongoDB 3.2 from 2.6 requires 2 steps. First you need to upgrade your database to version 3.0, then a second upgrade will be available to get to 3.2. Once this second upgrade has been done, you’ll see that your data has reached the latest available release.
WiredTiger Storage Engine is activated by default for new 3.0 and 3.2 databases.
Migrating to WiredTiger requires the database to be taken down for a while (from seconds to minutes according to your database size). This is the time to migrate existing data to the new storage format.
By migrating to WiredTiger, the authentication scheme will be switched from MONGODB-CR to SCRAM-SHA1. You have to be cautious, your application may be incompatible , resulting in authentication problems. Have a look to the driver compatibility list first.
The biggest and most famous change in MongoDB has been the integration of a Storage Engine named WiredTiger. This new engine delivers 7-10x greater throughput for write-intensive applications with more granular document-level concurrency control. You can expect a huge performance gain if your application tends to be write-heavy.
This storage backend has also changed the way your data are stored on our disks. Data files take now up to 80% less space on disk thanks to compression. Our addon offer let you use 5 times the memory size in disk, you can now store much more data for exactly the same price.
WiredTiger engine is designed to use more memory than before. It uses aggressive cache and compression strategies to reduce I/O operations and to improve performance. The MongoDB default cache size starts at 1GB for WiredTiger and that doesn’t include memory needed for file system cache or other runtime requirements like index storage. According to the plan chosen we’ll determine the amount size for this cache for most databases.
MongoDB let you create indexes with a given condition to index only documents matching this condition:
db.restaurants.createIndex(
{ cuisine: 1 },
{ partialFilterExpression: { rating: { $gt: 5 } } }
)
The above request will create an index which only consider restaurants where the rating is greater then 5.
So far it wasn’t possible to set any constraint at the database level about the values your applications have been sending to MongoDB. All the logics had to be included in your app.
It is now possible to create collections where only some type of documents can be written.
db.createCollection( "contacts",
{ validator: { $or:
[
{ phone: { $type: "string" } },
{ email: { $regex: /@mongodb\.com$/ } },
{ status: { $in: ["Unknown", "Incomplete"] } }
]
}
} )
Debugging query optimization has been done much easier by improving theexplain()
method, you can now get much more details about the internal operations of the database for a given query. Official documentation
It has now several ‘verbosity’ modes to get the information you need:
// 'queryPlanner': MongoDB runs the query optimizer to choose the winning plan
// for the operation under evaluation.
db.collection.find(query).explain("queryPlanner")
// 'executionStats': MongoDB runs the query optimizer to choose the winning
// plan, executes the winning plan to completion, and returns statistics
// describing the execution of the winning plan.
db.collection.find(query).explain("executionStats")
// 'allPlansExecution': MongoDB runs the query optimizer to choose the winning
// plan and executes the winning plan to completion. In "allPlansExecution"
// mode, MongoDB returns statistics describing the execution of the winning
// plan as well as statistics for the other candidate plans captured during
// plan selection.
db.collection.find(query).explain("allPlansExecution")
These were the features which were the most user-facing but much more has been released, We encourage you to have a look at the official Release notes for MongoDB 3.0 and 3.2:
If you are using Mongoid in your Ruby on Rails application, ensure you are using at least Mongoid 5.x before using MongoDB 3.2, otherwise your app will fail to authenticate to the database.
Using MongoDB 3.2 will work normally, but you won’t be able to use the latest features of the database as the driver used by Meteor is not up-to-date. Partial indexes and collection validation won’t be available.
A few days ago, the Meteor team announced that they will fully support MongoDB 3.2 in their next release: Meteor 1.4. Read the announcement.
Oplog is obviously also available for this release.
As our other database addons, they are based on Docker and the images we’re building are public and you can try it on your workstation:
docker run -p 7000:27017 \
-v /tmp/dbdata:/var/lib/mongodb \
scalingo/mongo:3.2.6-2 /mongo user password adminpassword
That’s it, your database will be running of the port 7000 of your workstation. Docker hub page: scalingo/mongo
Next step in our database service is to let you choose the precise version you want to use for your application. You may want to try your application against Mongo 2.6, 3.0 or 3.2, but so far you can’t choose a precise version of the database, we impose the last stable supported release.
We’ll also add a maintenance window to apply minor and security upgrade the day you choose and at the time you want your database to be upgraded.
The next upgrade will concern PostgreSQL, Release 9.5 will be available on the platform in the coming months. With a one click upgrade from 9.4 instances.
At Scalingo (with our partners) we use trackers on our website.
Some of those are mandatory for the use of our website and can't be refused.
Some others are used to measure our audience as well as to improve our relationship with you or to send you quality content and advertising.