I am trying to understand if “Entity-/relationship-based sharding” is a concept on MongoDB or not. I have a situation where in, I want data belonging to a set of accounts to be in a shard but that means, I need the right shard key in ALL The collections?
Example, I am having a CRM based application where Customer ID is the key for Sharding by using Hash. But, this is not just applicable to Customer Collection but all other collections which have “related” data.
Does it mean, I should have Customer ID in All the collection to use it as shard key or a concept of “Entity-/relationship-based sharding” allows you to do it without adding Customer ID in All Collections?
Hi @Vikram_Bade and welcome to MongoDB community forums!!
MongoDB does not support Entity-/relationship-based sharding directly.
Since MongoDB gives you the flexibility to related data using the Reference Pattern, Embedded documents and DBrefs, storing the related data becomes easier. You can read about Best Practices for Schema Design in MongoDB for further details.
The concept of Sharding in MongoDB, distributed the data on different machines based on the selection of the shard key.
If the customer ID is a unique identification for all the documents in the collection, perhaps directly using it as shard key would not be ideal as this would end up creating a jumbo chunk . Since, the choice of shard key affects the creation and distribution of chunks across the available shards. The distribution of data affects the efficiency and performance of operations within the sharded cluster. You can read more about shard key in the documentation for The choice of shard key affects the creation and distribution of chunks across the available shards. The distribution of data affects the efficiency and performance of operations within the sharded cluster.
The recommendation here would be to rethink about the schema design if possible and then use the shard key according the requirements and shard the collection.
Please feel free to reach out in case of any further questions.