What Is New in MongoDB 1.9
MongoDB 1.9 introduces significant enhancements focused on performance, indexing, and sharding. This release builds a more robust foundation for handling larger datasets and more complex queries.
| Category | Key Changes |
|---|---|
| New Features | Compound Geospatial Indexes, Replica Set Tags for Write Concern |
| Performance Improvements | Faster Counts, Index-Only Queries, Improved Concurrency |
| Sharding Enhancements | Tag-Aware Sharding, addShard Tags, Improved Balancer |
| Indexing | Sparse Index Improvements, Background Indexing Builds |
| Deprecated | Master-Slave Replication (in favor of Replica Sets) |
How did indexing get better in 1.9?
Indexing saw major upgrades, most notably with the introduction of compound geospatial indexes. You can now combine a geospatial field with other fields in a single index, which is a game-changer for location-based queries with additional filters.
Sparse indexes also became more useful. They now ignore documents that lack the indexed field entirely, which saves a ton of index space for optional fields. Background indexing builds mean adding indexes doesn't lock up your database during the process.
What sharding improvements were made?
Sharding became much more flexible with tag-aware sharding. This lets you control data placement across your cluster by assigning tags to shards and then defining ranges of data that should live on those tagged shards.
The balancer got smarter about moving chunks around, and the addShard command now accepts tags during configuration. This is the groundwork for more sophisticated data distribution strategies based on hardware or geography.
Were there any performance wins?
Absolutely. Count operations are significantly faster when a query can use an index. We also got index-only queries, where if all the data you need is in the index, MongoDB can return the results without touching the actual documents.
Concurrency improvements under the hood reduce lock contention. This means better performance for workloads with heavy reads and writes happening at the same time.
What about replica sets?
The big addition for replica sets is the ability to use tags for write concern. You can define a custom write concern that requires replication to specific members tagged with a certain role, like "critical" or a specific geographic location.
This release also solidifies replica sets as the preferred replication method. Master-slave replication is officially deprecated here, so it's time to migrate if you haven't already.
FAQ
Can I create an index on both a location and a timestamp now?
Yes. Compound geospatial indexes are a flagship feature of 1.9. You can create an index like { "location": "2d", "created_at": -1 } to efficiently query for the most recent posts near a specific point.
How do tag-aware sharding and replica set tags work together?
They serve different purposes. Replica set tags control write concern and read preferences within a single replica set. Shard tags control which shard (a replica set) a chunk of data gets placed on in a clustered environment.
Should I be worried about the master-slave deprecation?
You should plan to migrate to replica sets. Replica sets offer automatic failover and better reliability. Master-slave might still work, but it's not the future-proof path.
Do index-only queries work with all index types?
They work with any index that contains all the fields required by the query. If your query is db.users.find({name: "alice"}, {_id: 0, name: 1}) and you have an index on {name: 1}, it can be satisfied entirely by the index.
What's the practical impact of faster count operations?
It makes pagination and dashboard counters much more efficient. Applications that frequently run db.collection.count() with a query filter will see the biggest performance boost.