写操作 Performance

在本页面

索引

集合上的每个索引都会为写操作的 performance 增加一些开销。

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

注意 如果写入操作中涉及的文档包含在索引中,MongoDB 仅更新局部索引。

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

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

有关索引和查询,请参阅查询优化。有关索引的更多信息,请参阅索引索引策略

文档增长和 MMAPv1 存储引擎

某些更新操作可以增加文档的大小;例如,如果更新向文档添加新字段。

对于 MMAPv1 存储引擎,如果更新操作导致文档超过当前分配的record 大小,则 MongoDB 将磁盘上的文档重定位,并具有足够的连续空间来保存文档。需要重定位的更新比没有重定位的更新花费的时间更长,特别是在集合具有索引的情况下。如果集合具有索引,则 MongoDB 必须更新所有索引条目。因此,对于具有许多索引的集合,此移动将影响写入吞吐量。

更改 version 3.0.0:默认情况下,MongoDB 使用2 大小分配的力量为 MMAPv1 存储引擎添加自动填充2 大小分配的力量确保 MongoDB 以 2 的幂大小分配文档空间,这有助于确保 MongoDB 可以有效地重用文档删除或重定位创建的可用空间,并在许多情况下减少重新分配的发生。

尽管2 大小分配的力量最小化了 re-allocation 的出现,但它并没有消除文档 re-allocation。

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

存储性能

硬件

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

对于随机工作负载,固态 state 驱动器(SSD)的性能优于旋转硬盘(HDD)100 倍或更多。

看到 Production Notes有关其他硬件和 configuration 选项的建议。

日记

为了在崩溃的事件中提供持久性,MongoDB 使用 write ahead logging 到 on-disk 日志。 MongoDB 首先将 in-memory 更改写入 on-disk journal files。如果 MongoDB 在将更改提交到数据 files 之前应终止或遇到错误,则 MongoDB 可以使用 journal files 将写入操作应用于数据 files。

虽然期刊提供的持久性保证通常会超过额外写入操作的性能成本,但请考虑期刊与 performance 之间的以下相互作用:

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

  • 如果 applications 指定包含j 选项写下问题,则mongod将减少日志写入之间的持续时间,这会增加整体写入负载。

  • 日志写入之间的持续时间可使用commitIntervalMs run-time 选项进行配置。减少日志提交之间的时间间隔将增加写入操作的数量,这可能会限制 MongoDB 的写入操作容量。增加日志提交之间的 time 数量可能会减少写入操作的总数,但也会增加日志不会在失败的 event 中记录写入操作的机会。

有关日记的其他信息,请参阅日记