Operational Restrictions in Sharded Clusters分片集群中的操作限制
On this page本页内容
Sharding Operational Restrictions分片操作限制
Operations Unavailable in Sharded Environments在共享环境中不可用的操作
$where
does not permit references to the 不允许从db
object from the $where
function. $where
函数引用db
对象。This is uncommon in un-sharded collections.这在未分片的集合中并不常见。
The 在分片环境中不支持geoSearch
command is not supported in sharded environments.geoSearch
命令。
In MongoDB 5.0 and earlier, you cannot specify sharded collections in the 在MongoDB 5.0及更早版本中,不能在from
parameter of $lookup
stages.$lookup
阶段的from
参数中指定分片集合。
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.multi: false
或justOne
选项的分片集合的所有updateOne()
和deleteOne()
操作都必须在查询规范中包括分片键或_id
字段。
在不包含分片键或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._id
字段的分片集合中指定multi:false
或justOne
的updateOne()
和deleteOne()
操作返回错误。
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:findOneAndUpdate()
与分片集合一起使用,查询筛选器必须在分片键上包含一个相等条件,以便以以下任一格式比较键和值:
{ 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. MongoDB不支持跨分片的唯一索引,除非唯一索引包含完整的分片键作为索引的前缀。In these situations MongoDB will enforce uniqueness across the full key, not a single field.在这些情况下,MongoDB将在整个键中强制执行唯一性,而不是单个字段。
See: 请参阅:
Unique Constraints on Arbitrary Fields for an alternate approach.替代方法的任意字段上的唯一约束。
Consistent Indexes一致性索引
MongoDB does not guarantee consistent indexes across shards. MongoDB不能保证分片之间的索引一致。Index creation during addShard
operations or chunk migrations may not propagate to new shards.addShard
操作或区块迁移期间的索引创建可能不会传播到新的分片。
To check a sharded cluster for consistent indexes, use the 要检查分片集群的一致索引,请使用checkMetadataConsistency
command:checkMetadataConsistency
命令:
db.runCommand( {
checkMetadataConsistency: 1,
checkIndexes: true
} )
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.这些限制可以基于所有分片键值的平均大小和配置的块大小来估计。
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. MongoDB在集合中分发文档,这样每个区块在创建时都是半满的。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)
If 如果maxCollectionSize
is less than or nearly equal to the target collection, increase the chunk size to ensure successful initial sharding. maxCollectionSize
小于或几乎等于目标集合,请增加区块大小以确保成功的初始分片。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 Range 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 |