The ObjectRocket engineering team has been busy building our latest high performance data platform for taking full advantage of the new MongoDB 3.0 feature improvements. As with any major version upgrade, we suggest that you begin testing with MongoDB 3.0 prior to going straight into production and reach out to us with any questions.
I’m sure you’ll notice the lack of the WiredTiger storage engine right now, and you’re probably wondering why. Part of our mission here at ObjectRocket is to provide the most performant data platform on the market and to back it with the best support. To that end, we’re currently busy testing WiredTiger internally and developing the needed automations, tools, and monitoring for us to safely and effectively host your data. We expect to see WiredTiger added to the Early Access program very soon, with others to follow.
What’s new in MongoDB 3.0 MMAPv1?
Which data centers are supporting it?
MongoDB 3.0 MMAPv1 is currently availble in our Northen Virgina (IAD) data center and expect to roll out to our other DCs over the coming weeks.
Query Plan Explanations
MongoDB 3.0 now includes query explanation methods for gaining fine grained insight of the query plan and query execution. A detailed explanation of the output can be found here.
Replica set improvements
Replica sets can now up to 50 members, while the maximum number of voting members is still 7. The step down behavior has also been improved to now gracefully close out long running user operations and also prevent rollbacks by waiting for an electable secondary to catch up to the state of the primary. Finally, initial sync is more efficient and applied in batches via threads.
One of the most widely discussed feature improvements for MongoDB 3.0 has been the introduction of the pluggable storage engines. One of these is MongoDB’s original MMAP storage engine which has been updated to now allow for more granular control of the record allocation behavior per collection. The MMAP engine has also added collection-level locking for improving performance when multiple collections are contending for locks in previous versions.
The default user authentication method has been switched from MONGODB-CR to SCRAM-SHA-1, an IETF standard, and is considered to be a significant improvement in security. Existing instances of MongoDB 3.0 that are imported or migrated from versions 2.4 or 2.6 will be manually upgraded and verified by our expert customer data engineers to ensure minimal disruptions in your data access. All newly created instances will use SCRAM-SHA-1 by default and require no additional steps.
What differences should I be aware of?
The release of MongoDB 3.0 comes with largest set of feature changes since the initial release of the product. As such it is recommended that you take some time to review the release notes.
Here are the highlights we think you’ll be most interested in:
With the all new version of MongoDB came a whole new set of drivers that are required for interacting with your MongoDB 3.0 instances. Please refer to the driver compatibility list if migrating an existing solution to MongoDB 3.0.
Date and Timespan Sorting
MongoDB 3.0 no longer treats Timestamp and Date data types as equivalent. If your application relies on the equivalent comparison/sort order of Date and Timestamp objects, modify your application accordingly before upgrading.
The standard set of MongoDB tools have all been updated for this latest release and are not backwards compatible with the previous releases. Of particular note is that you can no longer directly modify the data files by using the –dbpath argument.
Common use cases that benefit from MongoDB 3.0 with MMAPv1
Clickstream / Logging / Internet of things (IoT)
Popular uses of MongoDB are the management of vast amounts of logs, clickstream events, and IoT data being created by modern websites, services, and home appliances. This sort of time series data typically doesn’t change document size once stored and is used in batch processing or analytics. To better support this data shape MMAPv1 allows the developer to specify a record allocation strategy which doesn’t add padding to the individual records. The end result is less physical storage use with no read or write performance penalties.
Existing collections in MongoDB 3.0 using MMAPv1 can change the record allocation strategy by using the colMod command. In this example we are update the existing collection named pageViews to no longer pad records:
To create a collection named pageViews in MongoDB 3.0 using MMAPv1 using the noPadding record allocation strategy:
Like what you’ve heard?
Great! Head over to the ObjectRocket Control Panel and join the Early Access program for MongoDB 3.0 with MMAPv1. And don’t forget to check out our hosted Elasticsearch and Redis offerings while you’re there.