What Is New in MongoDB 2.1
MongoDB 2.1 introduces significant improvements in indexing, concurrency, and aggregation, making it faster and more powerful for complex queries.
| Category | Key Changes |
|---|---|
| New Features | Concurrent Index Builds, Sparse Index Improvements, Aggregation Framework |
| Performance | Faster Counts, Improved Write Performance, Better Concurrency |
| Query & Indexing | Index Only Plans, Geospatial Enhancements, Sparse Index on Sharded Collections |
| Management | TTL Collection Stats, Compact Command, Replica Set Visibility |
How did indexing get better in 2.1?
The biggest indexing upgrade is the ability to build indexes in the background without blocking the entire database. This was a major pain point for large deployments. The build process now uses an initial sync and then an oplog catch-up phase, drastically reducing the performance impact on production systems.
Sparse indexes also got a major boost. You can now use them on sharded collections, and the query planner is much smarter about when to use them. This is huge for schemas with many optional fields, as it saves a ton of index space and maintenance overhead.
What performance improvements should I expect?
Count operations are significantly faster, especially on sharded clusters, because they can now run in parallel across shards. Write performance sees a nice bump from improved concurrency and reduced locking contention during operations like index builds.
The new aggregation framework is the star for complex data processing. It lets you run multi-stage pipelines for filtering, grouping, and transforming data directly in the database, which is far more efficient than doing it in your application code.
Are there any new commands for admins?
Yes, the compact command was added to defragment and reclaim space from a collection without needing to repair the entire database. This is a more surgical tool for maintenance.
You also get better visibility into replica sets with new server status output that shows lag and state for each member. For TTL collections, the stats now show how many documents were deleted and when the last cleanup happened.
FAQ
Do I need to do anything special to use concurrent index builds?
No, it's the new default for background index builds. The database handles the process automatically, making it much safer to add indexes on large collections during peak hours.
Can I use the aggregation framework for real-time analytics?
Absolutely. It's designed for that. The pipeline stages like $match, $group, and $project let you build complex reports directly in MongoDB, reducing the load on your application servers.
What happens to my existing sparse indexes?
They automatically benefit from the new query planner optimizations. The change to allow them on sharded collections means you can now create new sparse indexes on a sharded key if needed.
Is the compact command safe to run on a live production database?
It still requires a write lock on the collection it's operating on, so it will block operations on that collection. Schedule it during a maintenance window, just like you would with the repair command.
How much faster are count operations on a sharded cluster?
They can be orders of magnitude faster because the count is distributed to all shards simultaneously instead of being executed sequentially. The improvement scales with the number of shards in your cluster.