More from #MongoDBWorld.
Hidden Gems in the 2.6 Release
Everyone using MongoDB is familiar with the big features of the 2.6 release (and if you’re not, here’s a link) — text search, $out, user-defined roles, X509 authentication, etc. But what about the little guys? Our VP of Engineering, Daniel Pasette, will take you on a tour of five small but mighty features from the 2.6 release that make your MongoDB experience more productive.
VP of Core Engineering at MongoDB
Dan is the VP of Core Engineering at MongoDB. Prior to joining MongoDB, Dan was a Development Manager at LimeWire where he led a team working on content ingestion for an (unreleased) digital music service called Grapevine. Past employment includes MTV Networks, Sonicnet, iXL, and Electronic Book Technologies. Dan holds a degree in Computer Science from Brown University.
The Technical sessions are packed. I was hoping to look at Memory Management but the room was full to overflowing. So I dropped in to the session on the latest release of MongoDB – Version 2.6.
Power of 2 – Now default allocation Strategy
Power of 2 feature allows extra space when saving records. It is on by default in the latest release. It is best suited to uses that have re-writes to databases. What typically happens is a re-write expands the file and the file wouldn’t fit in the existing space. The extra space enabled by Power of 2 makes it more likely that records can be written back to the blocks they came from.
By adding space to records it reduces the amount of data movement because as data grows inside records the records still fit.
Server Side Timeouts
An example, a collection was indexed in staging but forgotten in production. This can cause table scans that cause users to re-try or re-scan. This creates socket timeouts. This can impact other users on the system. The new feature is maxTimeMS. This allows you to set a maximum time for how long an operation can run in the database. Set from milliseconds to minutes depending on the operation.
Query Engine Introspection
This works in conjunction with MaxTimeMS. It allows you to delve in to queries to resolve problems. The Query execution framework was completely re-writtin in 2.6. Prior to 2.6 the query path etc was opaque to users. This changed in 2.6.
The Query Planner chooses the best index for a given query.
Query Parser sends to Query Planner. This is passed to the Plan Cache. which passes to the Plan Runner.
The Plan Enumerator passes all the plans to the Multiplan router. This runs these plans for a limited amount of time and then chooses the most efficient.
On subsequent execution of the same query the query goes straight to the Plan Cache.
If the plan caches a sub-optimal plan.
Plans are dropped after indexing and other major changes.
A set of Plan Cache tools to view and manipulate the cache.
Background indexing on Secondaries
This has existed but the feature has been rounded out.
Pre-2.6 background index builds became foreground index builds when replicated to secondaries.
In 2.6 keeps background indexing in the background.
Note: Background indexing isn’t as fast and is less tightly packed.
User Driven Enhancements
All of these features came about as a result of user feedback that go through jira.mongodb.com
Limits on Replica sets
Limit of 12 nodes in a replica set with 7 voting members
[tag cloud BigData MongoDBWorld