MMAPv1 存储引擎

在本页面

• Journal

• 记录存储 Feature

• 记录分配策略

• Memory Use

MMAPv1 是 MongoDB 基于内存 Map 文件的原始存储引擎。它在具有大量插入，读取和就地更新的工作负载方面表现出色。

在版本 3.2 中进行了更改：从 MongoDB 3.2 开始，MMAPv1 不再是默认存储引擎；它不再是默认存储引擎。相反，WiredTiger存储引擎是默认存储引擎。参见默认存储引擎更改。

Journal

为了确保将对 MongoDB 数据集的所有修改持久地写入磁盘，默认情况下，MongoDB 会将所有修改记录到磁盘日志中。 MongoDB 向日志写入的频率比写入数据文件的频率高。

在MMAPv1 存储引擎的默认配置中，MongoDB 每 60 秒写入一次磁盘上的数据文件，大约每 100 毫秒写入一次journal文件。

要更 Rewrite 入数据文件的间隔，请使用storage.syncPeriodSecs设置。有关日志文件，请参见storage.journal.commitIntervalMs设置。

这些值表示完成写操作到 MongoDB 写入数据文件或日记文件之间的“最大”时间量。在许多情况下，MongoDB 和 os 会更频繁地将数据刷新到磁盘，因此上述值代表理论上的最大值。

该日志允许 MongoDB 在mongod实例退出后从数据文件成功恢复数据，而无需刷新所有更改。有关 MongoDB 中的日记的更多信息，请参见Journaling。

记录存储 Feature

所有记录都连续位于磁盘上，并且当文档变得大于分配的记录时，MongoDB 必须分配一个新记录。新的分配要求 MongoDB 移动文档并更新引用该文档的所有索引，这比就地更新要花费更多时间，并导致存储碎片。

在 3.0.0 版中更改。

默认情况下，MongoDB 使用2 大小分配的幂，以便 MongoDB 中的每个文档都存储在* record *中，其中包含文档本身和多余的空间，或padding。填充允许文档随着更新的结果而增长，同时最大程度地减少了重新分配的可能性。

记录分配策略

MongoDB 支持多种记录分配策略，这些策略可以确定mongod在创建记录时如何向文档中添加填充。由于 MongoDB 中的文档在插入后可能会增长，并且所有记录在磁盘上都是连续的，因此填充可以减少更新后在磁盘上重新放置文档的需求。重定位的效率不如就地更新，并且可能导致存储碎片。结果，所有填充策略都为提高效率和减少碎片交换了额外的空间。

不同的分配策略支持不同类型的工作负载：2 分配的力量对于插入/更新/删除工作负载效率更高；而精确匹配分配非常适合集合，而无需*更新和删除工作负载。

2 大小分配的幂

在 3.0.0 版中更改。

MongoDB 3.0 使用 2 大小的幂作为 MMAPv1 的默认记录分配策略。使用 2 个大小的幂分配策略，每个记录的字节大小为 2 的幂(例如 32、64、128、256、512…2 MB)。对于大于 2 MB 的文档，分配将舍入为 2 MB 的最接近倍数。

2 种大小分配策略的功效具有以下关键属性：

• 可以有效地重用释放的记录以减少碎片。将记录分配大小量化为一组固定的大小会增加插入内容适合早期文档删除或重定位所创建的空闲空间的可能性。

• 可以减少动作。增加的填充空间为文档空间提供了增长空间，而无需移动。除了节省移动成本之外，这还减少了索引的更新。尽管 2 种大小策略的功效可以使移动最小化，但是并不能完全消除它们。

无填充分配策略

在 3.0.0 版中更改。

对于工作负载不会更改文档大小的集合，例如由仅插入操作组成的工作负载或不增加文档大小(例如增加计数器)的更新操作，您可以将collMod命令与noPadding一起禁用2 分配的力量标志或带有noPadding选项的db.createCollection()方法。

在 3.0.0 版之前，MongoDB 使用的分配策略包括动态计算的padding作为文档大小的因素。

Memory Use

使用 MMAPv1，MongoDB 自动将计算机上的所有可用内存用作其缓存。系统资源监视器显示 MongoDB 使用大量内存，但是其使用情况是动态的。如果另一个进程突然需要服务器一半的 RAM，则 MongoDB 会将缓存的内存提供给另一个进程。

从技术上讲，os 的虚拟内存子系统 ManagementMongoDB 的内存。这意味着 MongoDB 将使用尽可能多的可用内存，并根据需要交换到磁盘。具有足够内存以适合 RAM 中应用程序的工作数据集的部署将获得最佳性能。