MongoDB 限制和阈值

在本页面

本文档提供了 MongoDB 系统的硬性限制和软性限制。

BSON Documents

最大文档大小有助于确保单个文档不会使用过多的 RAM 或在传输过程中占用过多的带宽。要存储大于最大大小的文档,MongoDB 提供了 GridFS API。有关 GridFS 的更多信息,请参见mongofilesdriver的文档。

Naming Restrictions

/\. "$*<>:|?

另外,数据库名称不能包含空字符。

/\. "$

另外,数据库名称不能包含空字符。

如果您的集合名称包含特殊字符(例如下划线字符)或以数字开头,则可以使用mongo shell 或您的驱动程序的类似方法中的db.getCollection()方法访问集合。

集合名称空间的最大长度为 120 个字节,其中包括数据库名称,点(.)分隔符和集合名称(即<database>.<collection>)。

否则,从 MongoDB 3.6 开始,服务器允许存储包含点(即.)和美元符号(即$)的字段名称。

Important

MongoDB 查询语言不能始终有效地对字段名称包含这些字符的文档表示查询(请参见SERVER-30575)。

在以查询语言添加支持之前,不建议在字段名称中使用$.,并且官方 MongoDB 驱动程序不支持。

Namespaces

对于 MMAPv1,名称空间的数量限于名称空间文件的大小除以 628.

一个 16 MB 的名称空间文件可以支持大约 24,000 个名称空间。每个集合和索引都是一个名称空间。

WiredTiger 存储引擎不受此限制的约束。

对于 MMAPv1 存储引擎,名称空间文件不能大于 2047 兆字节。

默认情况下,名称空间文件为 16 MB。您可以使用nsSize选项配置尺寸。

WiredTiger 存储引擎不受此限制的约束。

Indexes

在 2.6 版中进行了更改:MongoDB 2.6 版和更高版本对index key实施了更严格的限制:

因为这些操作会从集合中删除所有索引,然后按 Sequences 重新创建它们,所以索引键限制的错误会阻止这些操作为该集合重建任何剩余的索引,并且对于repairDatabase命令,将阻止它们 continue 执行剩余的索引。过程。

如果现有文档包含其索引条目超过限制的索引字段,则导致该文档在磁盘上重新定位的* any *更新将出错。

次要成员还允许对包含索引字段的集合进行索引构建和重建操作,该索引字段的对应索引条目超过索引键限制但在日志中带有警告。

对于辅助目录为 2.6 版且主目录为 2.4 版的* mixed version *副本集,辅助目录将复制在 2.4 主目录上插入或更新的文档,但是如果文档包含其索引对应的索引字段,则会在日志中显示错误消息条目超过了索引键限制

默认情况下,<index name>是字段名称和索引类型的串联。您可以为createIndex()方法显式指定<index name>,以确保标准索引名称不超过限制。

See also

唯一索引限制为分片操作限制

createIndexes结合使用内存和磁盘上的临时文件来完成索引构建。达到内存限制后,createIndexes--dbpath目录中名为_tmp的子目录中的临时磁盘文件用于其他暂存空间。设置的内存限制越高,索引构建就可以完成得越快,但是请注意不要相对于可用 RAM 将此限制设置得太高,否则系统可能会耗尽可用内存。

前景索引构建可以通过诸如Create Index的用户命令或诸如initial sync的 Management 过程来启动。两者都受maxIndexBuildMemoryUsageMegabytes设置的限制。

初始同步操作一次只能填充一个集合,并且没有超过内存限制的风险。但是,用户有可能同时在多个数据库中的多个集合上启动前台索引构建,并且可能消耗的内存量大于maxIndexBuildMemoryUsageMegabytes中设置的限制。

Tip

为了最大程度地减少在具有副本集分片的副本集和分片群集上构建索引的影响,请按照在副本集上构建索引所述使用滚动索引生成过程。

Tip

要在具有非简单排序规则的集合上创建text2dgeoHaystack索引,必须在创建索引时明确指定{collation: {locale: "simple"} }

Data

使用 MMAPv1 存储引擎,单个mongod实例无法 Management 超出基础 os 提供的最大虚拟内存地址空间的数据集。

虚拟内存限制

Operating System Journaled Not Journaled
Linux 64 terabytes 128 terabytes
Windows Server 2012 R2 和 Windows 8.1 64 terabytes 128 terabytes
Windows (otherwise) 4 terabytes 8 terabytes

WiredTiger 存储引擎不受此限制的约束。

对于 MMAPv1 存储引擎,数据库中最大集合数是名称空间文件大小和数据库中集合索引数的函数。

WiredTiger 存储引擎不受此限制的约束。

有关更多信息,请参见命名空间数

Replica Sets

副本集最多可包含 50 个成员。有关特定驱动程序与大型副本集兼容性的更多信息,请参见副本集成员数量增加

如果您未明确指定操作日志大小(即使用oplogSizeMB--oplogSize),则 MongoDB 将创建一个不超过 50 GB 的操作日志。

Sharded Clusters

分片群集具有此处描述的限制和阈值。

分片操作限制

从版本 3.0 开始不推荐使用:db.eval()

db.eval()与分片集合不兼容。您可以对分片群集中的未分片集合使用db.eval()

$where不允许从$where函数引用db对象。这在未分片的集合中并不常见。

分片环境中不支持geoSearch命令。

在以前的版本中,针对mongos运行时,索引不能coversharded集合的查询。

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

See

任意场的唯一约束作为替代方法。

如果块中的文档数大于配置的chunk size除以平均文档大小所得结果的 1.3 倍,则 MongoDB 无法移动该块。 db.collection.stats()包含avgObjSize字段,该字段表示集合中的平均文档大小。

分片键限制

shard key索引不能是在shard key字段上指定multikey indextext indexgeospatial index的索引。

当插入具有单调递增分片键的文档时,所有插入都在单个shard上属于相同的chunk。系统最终划分接收所有写操作的块范围,并迁移其内容以更均匀地分配数据。但是,群集在任何时候都只将插入操作定向到单个分片,这会造成插入吞吐量瓶颈。

如果群集上的操作主要是读取操作和更新,则此限制可能不会影响群集。

为避免此约束,请使用哈希分片键或选择一个不会单调增加或减少的字段。

哈希分片键hashed indexes存储带有升序值的键的散列。

Operations

如果管道包含在aggregate()操作中观察到allowDiskUse: true的其他阶段,则allowDiskUse: true选项对这些其他阶段有效。

2d Geospatial queries cannot use the $or operator

See

$or2 d 索引内部

对于球形查询使用2d索引可能会导致错误的结果,例如对于围绕极点的球形查询使用2d索引。

在版本 3.6 中进行了更改:写入次数从1,000增加到100,000。此限制也适用于旧版OP_INSERT消息。

mongo Shell 中的Bulk()操作以及驱动程序中的类似方法没有此限制。

Sessions

考虑发布db.collection.find()的应用程序。服务器返回游标以及find()cursor.batchSize()定义的一批文档。每当应用程序从服务器请求新一批文档时,会话都会刷新。但是,如果应用程序花费超过 30 分钟的时间来处理当前批次的文档,则该会话将被标记为已过期并关闭。当应用程序请求下一批文档时,服务器将返回错误,因为在关闭会话时光标被杀死。

对于返回游标的操作,如果游标可能闲置了 30 分钟以上,请使用Session.startSession()在显式会话中发出操作,并使用refreshSessions命令定期刷新该会话。例如:

var session = db.getMongo().startSession()
var sessionId = session.getSessionId().id

var cursor = session.getDatabase("examples").getCollection("data").find().noCursorTimeout()
var refreshTimestamp = new Date() // take note of time at operation start

while (cursor.hasNext()) {

  // Check if more than 5 minutes have passed since the last refresh
  if ( (new Date()-refreshTimestamp)/1000 > 300 ) {
    print("refreshing session")
    db.adminCommand({"refreshSessions" : [sessionId]})
    refreshTimestamp = new Date()
  }

  // process cursor normally

}

在示例操作中,db.collection.find()方法与显式会话关联。游标使用noCursorTimeout()配置,以防止服务器在空闲时关闭游标。 while循环包括一个块,该块使用refreshSessions每 5 分钟刷新一次会话。由于会话将永远不会超过 30 分钟的空闲超时,因此游标可以无限期保持打开状态。

对于 MongoDB 驱动程序,请参考driver documentation以获取有关创建会话的说明和语法。

Shell

mongo shell 提示每行的限制为 4095 个代码点。如果您 Importing 的行中包含 4095 个以上的代码点,则 Shell 将截断它。

首页