Operational Restrictions in Sharded Clusters
Sharding Operational Restrictions
Operations Unavailable in Sharded Environments
$where
does not permit references to the db
object
from the $where
function. This is uncommon in
un-sharded collections.
The geoSearch
command is not supported in sharded
environments.
In MongoDB 4.4 and earlier, you cannot specify sharded collections in the from
parameter of $lookup
stages.
Single Document Modification Operations in Sharded Collections
All updateOne()
and deleteOne()
operations for a sharded
collection that specify the multi: false
or justOne
option must include the
shard key or the _id
field in the query specification.
updateOne()
and deleteOne()
operations specifying multi: false
or justOne
in a sharded collection which do not contain either the
shard key or the _id
field return an error.
To use findOneAndUpdate()
with a sharded
collection, your query filter must include an equality condition on the
shard key to compare the key and value in either of these
formats:
{ key: value } { key: { $eq: value } }
Unique Indexes in Sharded Collections
MongoDB does not support unique indexes across shards, except when the unique index contains the full shard key as a prefix of the index. In these situations MongoDB will enforce uniqueness across the full key, not a single field.
Sharding Existing Collection Data Size
An existing collection can only be sharded if its size does not exceed specific limits. These limits can be estimated based on the average size of all shard key values, and the configured chunk size.
Important
These limits only apply for the initial sharding operation. Sharded collections can grow to any size after successfully enabling sharding.
MongoDB distributes documents in the collection so that each chunk is half full at creation. Use the following formulas to calculate the theoretical maximum collection size.
maxSplits = 16777216 (bytes) / <average size of shard key values in bytes> maxCollectionSize (MB) = maxSplits * (chunkSize / 2)
Note
The maximum BSON document size is 16MB or 16777216
bytes.
All conversions should use base-2 scale, e.g. 1024 kilobytes = 1 megabyte.
If maxCollectionSize
is less than or nearly equal to the target
collection, increase the chunk size to ensure successful initial sharding.
If there is doubt as to whether the result of the calculation is too
'close' to the target collection size, it is likely better to increase the
chunk size.
After successful initial sharding, you can reduce the chunk size as needed. If you later reduce the chunk size, it may take time for all chunks to split to the new size. See Modify Chunk Size in a Sharded Cluster for instructions on modifying chunk size.
This table illustrates the approximate maximum collection sizes using the formulas described above:
Average Size of Shard Key Values | 512 bytes | 256 bytes | 128 bytes | 64 bytes |
---|---|---|---|---|
Maximum Number of Splits | 32,768 | 65,536 | 131,072 | 262,144 |
Max Collection Size (64 MB Chunk Size) | 1 TB | 2 TB | 4 TB | 8 TB |
Max Collection Size (128 MB Chunk Size) | 2 TB | 4 TB | 8 TB | 16 TB |
Max Collection Size (256 MB Chunk Size) | 4 TB | 8 TB | 16 TB | 32 TB |