Welcome to part 2 in our 3-part what’s new series.

In the previous post, we announced that MongoDB 4.4 is now generally available and ready for production usage. We also covered enhancements to the MongoDB Query Language (MQL) – including the new Union aggregation pipeline stage and custom aggregation expressions – along with the availability of Rust and Swift drivers.

As discussed in that post, bringing 4.4 to market was a significant project. The MongoDB engineering team invested close to 270,000 hours and closed over 5,200 tickets. And so today, we will see where those efforts have been applied to making our distributed systems architecture even more flexible and performant for your applications.

Sharding in MongoDB 4.4

MongoDB’s native sharding is highly valued by developers. It enables you to horizontally scale-out your database across multiple nodes and geographic regions to accommodate application growth and to colocate data with your distributed applications and users. It’s elastic so you scale your database cluster out and in at any time to align consumption with resource requirements, and it’s transparent to your applications.

MongoDB sharding is also highly flexible, allowing data to be partitioned by range, hash, or zone – the latter implemented as Global Clusters in our fully-managed MongoDB Atlas global cloud database service. With this flexibility, you can shard your database to match both your query patterns and data residency needs. This is something you don’t get from most other distributed databases that purely hash a partition key, resulting in data being randomly sprayed across a cluster.

Even with the flexibility of MongoDB sharding, the inability to modify either the shard key or shard key value has been a frustration for some developers. This is because choosing a shard key that could not accommodate changing application requirements could result in data being unevenly distributed across the cluster, leading to inefficient use of provisioned resources and potentially poor performance.

Through developments in both the prior MongoDB 4.2 release and the new 4.4 release, sharding becomes even more flexible and adaptable:

• MongoDB 4.2 introduced the ability to modify shard key values using a distributed, multi-document ACID transaction to change the placement of a document in a cluster. This is useful when you want to rehome a document to a different geographic region or age data out to a lower storage tier.
• MongoDB 4.4 brings the ability to refine the shard key itself, and to create compound hashed shard keys to allow for an even more fine-grained distribution of data within the cluster.

With these enhancements, sharding your database is now even easier, giving you more flexibility in selecting your shard key and making ongoing scaling operations more seamless as your applications evolve.

#mongodb #cloud #developer