Announcing MongoDB 2.8.0-rc0 Release Candidate and Bug Hunt

< View all blog posts

November 12, 2014
Category: Release Notes

Edit: 2.8 is Now 3.0

We’re renaming our upcoming MongoDB release to 3.0. For more information, please see the blog post from MongoDB CTO and Co-Founder Eliot Horowitz.

Bug Hunt Extended!

There’s still time to submit your bugs! Along with the recent announcement about MongoDB’s acquisition of WiredTiger, we’ve extended the Bug Hunt. You can file issues until 2.8 is released!

Announcing MongoDB 2.8.0-rc0 Release Candidate

We’re truly excited to announce the availability of the first MongoDB 2.8 release candidate (rc0), headlined by improved concurrency (including document-level locking), compression, and pluggable storage engines.

We’ve put the release through extensive testing, and will be hard at work in the coming weeks optimizing and tuning some of the new features. Now it’s your turn to help ensure the quality of this important release. Over the next three weeks, we challenge you to test and uncover any lingering issues by participating in our MongoDB 2.8 Bug Hunt. Winners are entitled to some great prizes (details below).

MongoDB 2.8 RC0

In future posts we’ll share more information about all the features that make up the 2.8 release. We will begin today with our three headliners:

Pluggable Storage Engines

The new pluggable storage API allows external parties to build custom storage engines that seamlessly integrate with MongoDB. This opens the door for the MongoDB Community to develop a wide array of storage engines designed for specific workloads, hardware optimizations, or deployment architectures.

Pluggable storage engines are first-class players in the MongoDB ecosystem. MongoDB 2.8 ships with two storage engines, both of which use the pluggable storage API. Our original storage engine, now named “MMAPv1”, remains as the default. We are also introducing a new storage engine, WiredTiger, that fulfills our desire to make MongoDB burn through write-heavy workloads and be more resource efficient.

WiredTiger was created by the lead engineers of Berkeley DB and achieves high concurrency and low latency by taking full advantage of modern, multi-core servers with access to large amounts of RAM. To minimize on-disk overhead and I/O, WiredTiger uses compact file formats, and optionally, compression. WiredTiger is key to delivering the other two features we’re highlighting today.

Improved Concurrency

MongoDB 2.8 includes significant improvements to concurrency, resulting in greater utilization of available hardware resources, and vastly better throughput for write-heavy workloads, including those that mix reading and writing.

Prior to 2.8, MongoDB’s concurrency model supported database level locking. MongoDB 2.8 introduces document-level locking with the new WiredTiger storage engine, and brings collection-level locking to MMAPv1. As a result, concurrency will improve for all workloads with a simple version upgrade. For highly concurrent use cases, where writing makes up a significant portion of operations, migrating to the WiredTiger storage engine will dramatically improve throughput and performance.

The improved concurrency also means that MongoDB will more fully utilize available hardware resources. So whereas CPU usage in MongoDB has been traditionally fairly low, it will now correspond more directly to system throughput.

Compression

The WiredTiger storage engine in MongoDB 2.8 provides on-disk compression, reducing disk I/O and storage footprint by 30-80%. Compression is configured individually for each collection and index, so users can choose the compression algorithm most appropriate for their data. In 2.8, WiredTiger compression defaults to Snappy compression, which provides a good compromise between speed and compression rates. For greater compression, at the cost of additional CPU utilization, you can switch to zlib compression.

For more information, including how to seamlessly upgrade to the WiredTiger storage engine, please see the 2.8 Release Notes.

The Bug Hunt

The Bug Hunt rewards community members who contribute to improving MongoDB releases through testing. We’ve put the release through rigorous correctness, performance and usability testing. Now it’s your turn to test MongoDB against your development environment. We challenge you to test and uncover any remaining issues in MongoDB 2.8.0-rc0. Bug reports will be judged on three criteria: user impact, severity and prevalence.

All issues submitted against 2.8.0-rc0 will be candidates for the Bug Hunt. Winners will be announced on the MongoDB blog and user forum by December 9. There will be one first place winner, one second place winner and at least two honorable mentions. Awards are described below.

During the first Bug Hunt, for MongoDB 2.6, the community’s efforts were instrumental in improving the release and we’re hoping to get even more people involved in the Bug Hunt this time!

Bug Hunt Rewards

First Prize:

  • 1 ticket to MongoDB World — with a reserved front-row seat for keynote sessions
  • $1000 Amazon Gift Card
  • MongoDB Contributor T-shirt

Second Prize:

  • 1 ticket to MongoDB World — with a reserved front-row seat for keynote sessions
  • $500 Amazon Gift Card
  • MongoDB Contributor T-shirt

Honorable Mentions:

  • 1 ticket to MongoDB World — with a reserved front-row seat for keynote sessions
  • $250 Amazon Gift Card
  • MongoDB Contributor T-shirt

How to get started

  • Download MongoDB 2.8 RC0: You can download this release at MongoDB.org/downloads.
  • Deploy in your test environment: It is best to test software in a real environment with realistic data volumes and load. Help us see how 2.8 works with your code and data so that others can build and run applications on MongoDB 2.8 successfully.
  • Test new features and improvements: There is a lot of new functionality in MongoDB 2.8. See the 2.8 Release Notes for a full list.
  • Log a ticket: If you find an issue, create a report in Jira (Core Server project). See the documentation for a guide to submitting well written bug reports or discuss on the MongoDB Developers mailing list.

Don’t Hunt Alone

If you’re new to database testing, you don’t have to do it alone your first time. Join one of our MongoDB User Groups this month to try hacking on the release candidate with MongoDB Performance and QA engineers. Here are some of the upcoming events:

Want to run a Bug Hunt at your local user group or provide a space for the community to hunt? Get in touch with the MongoDB Community team to get started.

If you are interested in doing this work full time, consider applying to join our engineering teams in New York City, Palo Alto and Austin, Texas.

Happy hunting!

Eliot, Dan, Alvin and the MongoDB Team

comments powered by Disqus