Sharding >
Sharding Reference >
Operational Restrictions in Sharded Clusters

Operational Restrictions in Sharded Clusters¶

On this page

Sharding Operational Restrictions¶

Operations Unavailable in Sharded Environments¶

The group does not work with sharding. Use mapReduce or aggregate instead.

Deprecated since version 3.0: db.eval() is deprecated.

db.eval() is incompatible with sharded collections. You may use db.eval() with un-sharded collections in a shard cluster.

$where does not permit references to the db object from the $where function. This is uncommon in un-sharded collections.

The $isolated update modifier does not work in sharded environments.

$snapshot queries do not work in sharded environments.

The geoSearch command is not supported in sharded environments.

Single Document Modification Operations in Sharded Collections¶

All updateOne(), removeOne(), and deleteOne() operations for a sharded collection must include the shard key or the _id field in the query specification. updateOne(), removeOne(), and deleteOne() operations without the shard key or the _id field return an error.

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.

See

Unique Constraints on Arbitrary Fields for an alternate approach.

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.

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 sucessful 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

← Sharding Reference Troubleshoot Sharded Clusters →