I’ve watched this video, which said that hashed sharding is a simple solution to distribute data evenly, but it comes with a horrible cost from index memory point of view.
I was considering a shard key that is monotonically increasing (ObjectId), so I was going to make it hashed to avoid a hot shard. This is the practice I’ve learned from the official MongoDB document..
If total doc size is huge, Hashed sharding is now not recommended way when the shard key is monotonically increasing?
Hello @kuser ,
Welcome to The MongoDB Community Forums! 
As per the documentations, Hashed Sharding is typically recommended for monotonically increasing shard keys, however as per the video you linked, it comes with some caveats and there is no substitute for a proper workload simulation to test the shard key. Please go through below links for reference
Additionally, choosing a proper sharding strategy depends on many things in your use-case such as: most common queries that are required to perform regularly, data size and particular requirements - hardware, costing etc. You need to carefully evaluate your specific use case and performance requirements before deciding on a shard key. Make sure your queries are not scatter-gather queries. Queries that involve multiple shards for each request are less efficient and do not scale linearly when more shards are added to the cluster. Similarly, Shards with un-even distribution of data are also not considered efficient and Jumbo flags should be avoided. So, One needs to plan accordingly. You can read selecting shard key blog to choose the best shard key for your sharded cluster.
Note: Starting in MongoDB 6.0.3, data in sharded clusters is distributed based on data size rather than number of chunks, so if balancing based on data size is your ultimate goal, I recommend you to check out MongoDB 6.0.3 or newer. For details, see Balancing Policy Changes.
Regards,
Tarun
This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.