分片群集中的操作限制
在本页面
分片操作限制
分片环境中不可用的操作
group不适用于分片。请改用mapReduce或aggregate。
从版本 3.0 开始不推荐使用:db.eval()。
db.eval()与分片集合不兼容。您可以对分片群集中的未分片集合使用db.eval()。
$where不允许从$where函数引用db
对象。这在未分片的集合中并不常见。
分片集合中的单文档修改操作
指定justOne
选项的分片集合的所有updateOne(),removeOne()
和deleteOne()操作必须在查询规范中包括shard key 或 _id
字段。在分片集合中指定justOne
的updateOne(),removeOne()
和deleteOne()操作不包含shard key或_id
字段将返回错误。
分片集合中的唯一索引
MongoDB 不支持跨分片的唯一索引,除非唯一索引包含完整的分片键作为索引前缀。在这种情况下,MongoDB 将在整个键而不是单个字段上强制唯一性。
See
任意场的唯一约束作为替代方法。
分片现有收集数据大小
如果现有集合的大小未超过特定限制,则只能对其进行分片。可以基于所有shard key值的平均大小和配置的chunk大小来估计这些限制。
Important
这些限制仅适用于初始分片操作。成功启用分片后,分片集合可以增长到任何大小。
使用以下公式来计算“理论上”的最大收集大小。
maxSplits = 16777216 (bytes) / <average size of shard key values in bytes>
maxCollectionSize (MB) = maxSplits * (chunkSize / 2)
Note
BSON文档的最大大小为 16MB 或16777216
字节。
所有转化均应使用以 2 为基数的标度,例如 1024 兆字节= 1 兆字节。
如果maxCollectionSize
小于或几乎等于目标集合,则增加块大小以确保成功进行初始分片。如果对计算结果是否过于“接近”目标集合大小存有疑问,则最好增加块大小。
成功进行初始分片后,您可以根据需要减小块大小。如果以后减小块大小,则所有块都可能需要一些时间才能拆分为新的大小。有关修改块大小的说明,请参见修改分片群集中的块大小。
下表使用上述公式说明了最大的近似收集大小:
分片键值的平均大小 | 512 bytes | 256 bytes | 128 bytes | 64 bytes |
---|---|---|---|---|
最大分割数 | 32,768 | 65,536 | 131,072 | 262,144 |
最大收集大小(64 MB 块大小) | 1 TB | 2 TB | 4 TB | 8 TB |
最大收集大小(128 MB 块大小) | 2 TB | 4 TB | 8 TB | 16 TB |
最大收集大小(256 MB 块大小) | 4 TB | 8 TB | 16 TB | 32 TB |