Write Operation Performance¶
On this page
Each index on a collection adds some amount of overhead to the performance of write operations.
For each insert or delete write operation on a collection, MongoDB either inserts or removes the corresponding document keys from each index in the target collection. An update operation may result in updates to a subset of indexes on the collection, depending on the keys affected by the update.
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.
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.
Changed in version 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.
Although Power of 2 Sized Allocations minimizes the occurrence of re-allocation, it does not eliminate document re-allocation.
See MMAPv1 Storage Engine for more information.
The capability of the storage system creates some important physical limits for the performance of MongoDB’s write operations. Many unique factors related to the storage system of the drive affect write performance, including random access patterns, disk caches, disk readahead and RAID configurations.
Solid state drives (SSDs) can outperform spinning hard disks (HDDs) by 100 times or more for random workloads.
Production Notes 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.