翻译或纠错本页面

写操作性能

索引

在每次插入、更新及删除操作之后,除了数据本身之外,MongoDB还必须更新与该集合相关的 每一个 索引。因此,一个集合中的每个索引都会对写操作的性能加大一定数量的开销。 [#exceptions]_

一般说来,索引为 读操作 提供的性能提升相较于插入的惩罚是值得的。然而,为了尽可能地优化写入的性能,在创建新索引及评估现有索引时,一定要谨慎,以保证您的查询确实使用了这些索引。

注解

请查阅 Query Optimization 了解关于索引及查询的信息。此外,您还可以通过查阅 索引 and 索引策略 了解更多关于索引的信息。

On mongod instances that use the MMAPv1 storage engine, update operations may cause a document to grow beyond its allocated space. When a document outgrows its allocated space, MMAPv1 moves the document to a new location on disk, and must update each index on the collection to point to the new document location. These move operations can be expensive but occur infrequently.

In general, the performance gains that indexes provide for read operations are worth the insertion penalty. However, in order to optimize write performance when possible, be careful when creating new indexes and evaluate the existing indexes to ensure that your queries actually use these indexes.

针对无索引字段的插入和更新操作, sparse indexes 的开销要高于非稀疏索引。此外,对于非稀疏索引而言,不改变记录大小的更新操作占用更少的索引开销。

Document Growth and the MMAPv1 Storage Engine

Some update operations can increase the size of the document; for instance, if an update adds a new field to the document.

For the MMAPv1 storage engine, if an update operation causes a document to exceed the currently allocated record size, MongoDB relocates the document on disk with enough contiguous space to hold the document. Updates that require relocations take longer than updates that do not, particularly if the collection has indexes. If a collection has indexes, MongoDB must update all index entries. Thus, for a collection with many indexes, the move will impact the write throughput.

在 3.0.0 版更改: By default, MongoDB uses Power of 2 Sized Allocations to add padding automatically for the MMAPv1 storage engine. The Power of 2 Sized Allocations ensures that MongoDB allocates document space in sizes that are powers of 2, which helps ensure that MongoDB can efficiently reuse free space created by document deletion or relocation as well as reduce the occurrences of reallocations in many cases.

就地更新很明显比那些造成文档增长的更新操作更高效。如果可能的话,您可以使用 data models 来最小化文档增长的需求。

See MMAPv1 Storage Engine for more information.

存储性能

硬件

存储系统的容量给MongoDB写操作的性能带来了一些重要的、物理方面的限制。许多与驱动器存储系统相关的单值因子都会影响写操作的性能,包括:随机存取模式、磁盘缓存、磁盘预加载库文件以及独立磁盘冗余阵列配置等。

Solid state drives (SSDs) can outperform spinning hard disks (HDDs) by 100 times or more for random workloads.

请查阅

生产环境指南 for recommendations regarding additional hardware and configuration options.

日志

To provide durability in the event of a crash, MongoDB uses write ahead logging to an on-disk journal. MongoDB writes the in-memory changes first to the on-disk journal files. If MongoDB should terminate or encounter an error before committing the changes to the data files, MongoDB can use the journal files to apply the write operation to the data files.

While the durability assurance provided by the journal typically outweigh the performance costs of the additional write operations, consider the following interactions between the journal and performance:

  • If the journal and the data file reside on the same block device, the data files and the journal may have to contend for a finite number of available I/O resources. Moving the journal to a separate device may increase the capacity for write operations.
  • If applications specify write concerns that include the j option, mongod will decrease the duration between journal writes, which can increase the overall write load.
  • The duration between journal writes is configurable using the commitIntervalMs run-time option. Decreasing the period between journal commits will increase the number of write operations, which can limit MongoDB’s capacity for write operations. Increasing the amount of time between journal commits may decrease the total number of write operation, but also increases the chance that the journal will not record a write operation in the event of a failure.

For additional information on journaling, see Journaling.