写操作性能

在本页面

• Indexes

• 文档增长和 MMAPv1 存储引擎

• Storage Performance

Indexes

集合上的每个索引都会增加写入操作的性能。

对于集合上的每个insert或delete写操作，MongoDB 将从目标集合中的每个索引中插入或删除相应的文档密钥。 update操作可能导致对集合上索引子集的更新，具体取决于受更新影响的键。

在使用MMAPv1存储引擎的mongod实例上，更新操作可能导致文档超出其分配的空间。当文档超出其分配的空间时，MMAPv1 会将文档移动到磁盘上的新位置，并且必须更新集合上的每个索引以指向新的文档位置。这些移动操作可能很昂贵，但很少发生。

通常，索引为读取操作提供的性能提升值得进行插入惩罚。但是，为了在可能的情况下优化写入性能，在创建新索引并评估现有索引时要小心，以确保您的查询实际使用这些索引。

有关索引和查询，请参见Query Optimization。有关索引的更多信息，请参见Indexes和Indexing Strategies。

文档增长和 MMAPv1 存储引擎

某些更新操作可能会增加文档的大小。例如，如果更新将新字段添加到文档中。

对于 MMAPv1 存储引擎，如果更新操作导致文档超过当前分配的record size，则 MongoDB 会将文档重新放置在磁盘上，并具有足够的连续空间来容纳该文档。需要重定位的更新比不需要重定位的更新要花费更长的时间，尤其是在集合具有索引的情况下。如果集合具有索引，则 MongoDB 必须更新所有索引条目。因此，对于具有许多索引的集合，此举将影响写入吞吐量。

在 3.0.0 版中进行了更改：默认情况下，MongoDB 使用2 大小分配的幂为 MMAPv1 存储引擎添加padding automatically。 2 大小分配的幂确保 MongoDB 分配的文档空间大小为 2 的幂，这有助于确保 MongoDB 可以有效地重用由文档删除或重定位创建的可用空间，并在许多情况下减少重新分配的发生。

尽管2 大小分配的幂可以最大程度地减少重新分配的发生，但是不能消除文档的重新分配。

有关更多信息，请参见MMAPv1 存储引擎。

Storage Performance

Hardware

存储系统的功能为 MongoDB 的写操作性能创建了一些重要的物理限制。与驱动器的存储系统相关的许多独特因素都会影响写入性能，包括随机访问模式，磁盘缓存，磁盘预读和 RAID 配置。

对于随机工作负载，固态驱动器(SSD)的性能可以比旋转硬盘(HDD)高 100 倍甚至更多。

Journaling

为了在崩溃时提供持久性，MongoDB 使用预先写入日志到磁盘journal上。 MongoDB 首先将内存更 Rewrite 入磁盘日志文件。如果在将更改提交到数据文件之前，MongoDB 应该终止或遇到错误，则 MongoDB 可以使用日记文件将写操作应用于数据文件。

尽管日志提供的耐用性保证通常会超过其他写入操作的性能成本，但请考虑以下日志与性能之间的交互作用：

• 如果日志和数据文件位于同一块设备上，则数据文件和日志可能必须竞争有限数量的可用 I/O 资源。将日志移动到单独的设备可能会增加写操作的容量。

• 如果应用程序指定包含j option的write concerns，则mongod将减少日志写入之间的持续时间，这可能会增加总体写入负载。

• 日志写入之间的持续时间可以使用commitIntervalMs运行时选项进行配置。减少日记提交之间的时间间隔将增加写入操作的数量，这可能会限制 MongoDB 的写入操作能力。增加日志提交之间的时间量可能会减少写操作的总数，但也会增加在失败的情况下日志不会记录写操作的机会。

有关日记的其他信息，请参见Journaling。