While sharding is a powerful and compelling feature, sharded clusters
have significant infrastructure requirements and increases the overall
complexity of a deployment. As a result, only deploy sharded clusters
when indicated by application and operational requirements
Sharding is the only solution for some classes of deployments. Use
sharded clusters if:
your data set approaches or exceeds the storage capacity of a single
the size of your system’s active working setwill soon
exceed the capacity of your system’s maximum RAM.
a single MongoDB instance cannot meet the demands of your write
operations, and all other approaches have not reduced contention.
If these attributes are not present in your system, sharding will only
add complexity to your system without adding much benefit.
It takes time and resources to deploy sharding. If
your system has already reached or exceeded its capacity, it
will be difficult to deploy sharding without impacting
As a result, if you think you will need to partition your database
in the future, do not wait until your system is over capacity to
When designing your data model, take into consideration your sharding
Your cluster should manage a large quantity of data if sharding is to
have an effect. The default chunk size is 64 megabytes. And the
balancer will not begin moving data across
shards until the imbalance of chunks among the shards exceeds the
migration threshold. In
practical terms, unless your cluster has many hundreds of megabytes of
data, your data will remain on a single shard.
In some situations, you may need to shard a small collection of data.
But most of the time, sharding a small collection is not worth the
added complexity and overhead unless you need additional write
capacity. If you have a small data set, a properly configured single
MongoDB instance or a replica set will usually be enough for your
persistence layer needs.
Chunk size is
For most deployments, the default value is of 64
megabytes is ideal. See Chunk Size for more information.