MongoDB中参数限制与阀值的示例分析

共计 3416 个字符，预计需要花费 9 分钟才能阅读完成。

这篇文章主要介绍 MongoDB 中参数限制与阀值的示例分析，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！

一、BSON 文档

BSON 文档尺寸：一个 document 文档最大尺寸为 16M；大于 16M 的文档需要存储在 GridFS 中。

文档内嵌深度：BSON 文档的结构（tree）深度最大为 100。

二、Namespaces

collection 命名空间：.，最大长度为 120 字节。这也限定了 database 和 collection 的名字不能太长。

命名空间的个数：对于 MMAPV1 引擎，个数最大为大约为 24000 个，每个 collection 以及 index 都是一个 namespace；对于 wiredTiger 引擎则没有这个限制。

namespace 文件的大小：对于 MMAPV1 引擎而言，默认大小为 16M，可以通过在配置文件中修改。wiredTiger 不受此限制。

三、indexes

index key：每条索引的 key 不得超过 1024 个字节，如果 index key 的长度超过此值，将会导致 write 操作失败。

每个 collection 中索引的个数不得超过 64 个。

索引名称：我们可以为 index 设定名称，最终全名为..$，最长不得超过 128 个字节。默认情况下为 filed 名称与 index 类型的组合，我们可以在创建索引时显式的指定 index 名字，参见 createIndex() 方法。

组合索引最多能包含 31 个 field。

四、Data

Capped Collection：如果你在创建“Capped”类型的 collection 时指定了文档的最大个数，那么此个数不能超过 2 的 32 次方，如果没有指定最大个数，则没有限制。

Database Size：MMAPV1 引擎而言，每个 database 不得持有超过 16000 个数据文件，即单个 database 的总数据量最大为 32TB，可以通过设置“smallFiles”来限定到 8TB。

Data Size：对于 MMAVPV1 引擎而言，单个 mongod 不能管理超过最大虚拟内存地址空间的数据集，比如 linux（64 位）下每个 mongod 实例最多可以维护 64T 数据。wiredTiger 引擎没有此限制。

每个 Database 中 collection 个数：对于 MMAPV1 引擎而然，每个 database 所能持有的 collections 个数取决于 namespace 文件大小（用来保存 namespace）以及每个 collection 中 indexes 的个数，最终总尺寸不超过 namespace 文件的大小（16M）。wiredTiger 引擎不受到此限制。

五、Replica Sets

每个 replica set 中最多支持 50 个 members。

replica set 中最多可以有 7 个 voting members。（投票者）

如果没有显式的指定 oplog 的尺寸，其最大不会超过 50G。

六、Sharded Clusters

group 聚合函数，在 sharding 模式下不可用。请使用 mapreduce 或者 aggregate 方法。

Coverd Queries：即查询条件中的 Fields 必须是 index 的一部分，且返回结果只包含 index 中的 fields；对于 sharding 集群，如果 query 中不包含 shard key，索引则无法进行覆盖。虽然_id 不是“shard key”，但是如果查询条件中只包含_id，且返回的结果中也只需要_id 字段值，则可以使用覆盖查询，不过这个查询似乎并没有什么意义（除非是检测此_id 的 document 是否存在）。

对于已经存有数据的 collections 开启 sharding（原来非 sharding），则其最大数据不得超过 256G。当 collection 被 sharding 之后，那么它可以存储任意多的数据。

对于 sharded collection，update、remove 对单条数据操作（操作选项为 multi:false 或者 justOne），必须指定 shard key 或者_id 字段；否则将会抛出 error。

唯一索引：shards 之间不支持唯一索引，除非这个“shard key”是唯一索引的最左前缀。比如 collection 的 shard key 为 {“zipcode”:1,”name”: 1}，如果你想对 collection 创建唯一索引，那么唯一索引必须将 zipcode 和 name 作为索引的最左前缀，比如：collection.createIndex({“zipcode”:1,”name”:1,”company”:1},{unique:true})。

在 chunk 迁移时允许的最大文档个数：如果一个 chunk 中 documents 的个数超过 250000（默认 chunk 大小为 64M）时，或者 document 个数大于 1.3 *（chunk 最大尺寸（有配置参数决定）/ document 平均尺寸），此 chunk 将无法被“move”（无论是 balancer 还是人工干预），必须等待 split 之后才能被 move。

七、shard key

shard key 的长度不得超过 512 个字节。

“shard key 索引”可以为基于 shard key 的正序索引，或者以 shard key 开头的组合索引。shard key 索引不能是 multikey 索引（基于数组的索引）、text 索引或者 geo 索引。

Shard key 是不可变的，无论何时都不能修改 document 中的 shard key 值。如果需要变更 shard key，则需要手动清洗数据，即全量 dump 原始数据，然后修改并保存在新的 collection 中。

单调递增（递减）的 shard key 会限制 insert 的吞吐量；如果_id 是 shard key，需要知道_id 是 ObjectId() 生成，它也是自增值。对于单调递增的 shard key，collection 上的所有 insert 操作都会在一个 shard 节点上进行，那么此 shard 将会承载 cluster 的全部 insert 操作，因为单个 shard 节点的资源有限，因此整个 cluster 的 insert 量会因此受限。如果 cluster 主要是 read、update 操作，将不会有这方面的限制。为了避免这个问题，可以考虑使用“hashed shard key”或者选择一个非单调递增 key 作为 shard key。（rang shard key 和 hashed shard key 各有优缺点，需要根据 query 的情况而定）。

八、Operations

如果 mongodb 不能使用索引排序来获取 documents，那么参与排序的 documents 尺寸需要小于 32M。

Aggregation Pileline 操作。Pipeline stages 限制在 100M 内存，如果 stage 超过此限制将会发生错误，为了能处理较大的数据集，请开启“allowDiskUse”选项，即允许 pipeline stages 将额外的数据写入临时文件。

九、命名规则

database 的命名区分大小写。

database 名称中不要包含：/ .‘$* :|?

database 名称长度不能超过 64 个字符。

collection 名称可以以“_”或者字母字符开头，但是不能包含”$”符号，不能为空字符或者 null，不能以“system.”开头，因为这是系统保留字。

document 字段名不能包含“.”或者 null，且不能以“$”开头，因为 $ 是一个“引用符号”。

最后记录下 json 嵌套中含有列表的查询方法，样例数据：

{  _id  : ObjectId( 5c6cc376a589c200018f7312),
  id  :  9472 ,
  data  : {
  name  :  测试 ,
  publish_date  :  2009-05-15 ,
  authors  : [ 
 {
  author_id  : 3053,
  author_name  :  测试数据 
 }
 ],
 }
}

我要查询 authors 中的 author_id，query 可以这样写：

db.getCollection().find({ data.authors.0.author_id : 3053})

用 0 来代表第一个索引，点代表嵌套结构。但是 spark mongo 中是不能这样导入的，需要使用别的方法。

以上是“MongoDB 中参数限制与阀值的示例分析”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注丸趣 TV 行业资讯频道！