On this page本页内容
This document addresses common questions regarding MongoDB’s storage system.
A storage engine is the part of a database that is responsible for managing how data is stored, both in memory and on disk. Many databases support multiple storage engines, where different engines perform better for specific workloads. For example, one storage engine might offer better performance for read-heavy workloads, and another might support a higher throughput for write operations.
See also参阅
Yes. You can have replica set members that use different storage engines (WiredTiger and in-memory)
Note
Starting in version 4.2, MongoDB removes the deprecated MMAPv1 storage engine.
Yes. See:
The ratio of compressed data to uncompressed data depends on your data and the compression library used. By default, collection data in WiredTiger use Snappy block compression; zlib and zstd compression is also available. Index data use prefix compression by default.
With WiredTiger, MongoDB utilizes both the WiredTiger internal cache and the filesystem cache.
Starting in MongoDB 3.4, the default WiredTiger internal cache size is the larger of either:
For example, on a system with a total of 4GB of RAM the WiredTiger cache will use 1.5GB of RAM (0.5 * (4 GB - 1 GB) = 1.5 GB
). Conversely, a system with a total of 1.25 GB of RAM will allocate 256 MB to the WiredTiger cache because that is more than half of the total RAM minus one gigabyte (0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB
).
Note
In some instances, such as when running in a container, the database can have memory constraints that are lower than the total system memory. In such instances, this memory limit, rather than the total system memory, is used as the maximum RAM available.
To see the memory limit, see hostInfo.system.memLimitMB
.
By default, WiredTiger uses Snappy block compression for all collections and prefix compression for all indexes. Compression defaults are configurable at a global level and can also be set on a per-collection and per-index basis during collection and index creation.
Different representations are used for data in the WiredTiger internal cache versus the on-disk format:
Via the filesystem cache, MongoDB automatically uses all free memory that is not used by the WiredTiger cache or by other processes.
To adjust the size of the WiredTiger internal cache, see storage.wiredTiger.engineConfig.cacheSizeGB
and --wiredTigerCacheSizeGB
. Avoid increasing the WiredTiger internal cache size above its default value.
Note
The storage.wiredTiger.engineConfig.cacheSizeGB
limits the size of the WiredTiger internal cache. The operating system will use the available free memory for filesystem cache, which allows the compressed MongoDB data files to stay in memory. In addition, the operating system will use any free RAM to buffer file system blocks and file system cache.
To accommodate the additional consumers of RAM, you may have to decrease WiredTiger internal cache size.
The default WiredTiger internal cache size value assumes that there is a single mongod
instance per machine. If a single machine contains multiple MongoDB instances, then you should decrease the setting to accommodate the other mongod
instances.
If you run mongod
in a container (e.g. lxc
, cgroups
, Docker, etc.) that does not have access to all of the RAM available in a system, you must set storage.wiredTiger.engineConfig.cacheSizeGB
to a value less than the amount of RAM available in the container. The exact amount depends on the other processes running in the container. See memLimitMB
.
To view statistics on the cache and eviction rate, see the wiredTiger.cache
field returned from the serverStatus
command.
WiredTiger syncs the buffered journal records to disk upon any of the following conditions:
j: true
.
Note
Write concern "majority"
implies j: true
if the writeConcernMajorityJournalDefault
is true.
storage.journal.commitIntervalMs
).The WiredTiger storage engine maintains lists of empty records in data files as it deletes documents. This space can be reused by WiredTiger, but will not be returned to the operating system unless under very specific circumstances.
The amount of empty space available for reuse by WiredTiger is reflected in the output of db.collection.stats()
under the heading wiredTiger.block-manager.file bytes available for reuse
.
To allow the WiredTiger storage engine to release this empty space to the operating system, you can de-fragment your data file. This can be achieved using the compact
command. For more information on its behavior and other considerations, see compact
.
To view the statistics for a collection, including the data size, use the db.collection.stats()
method from the mongo
shell. The following example issues db.collection.stats()
for the orders
collection:
MongoDB also provides the following methods to return specific sizes for the collection:
db.collection.dataSize()
to return the uncompressed data size in bytes for the collection.db.collection.storageSize()
to return the size in bytes of the collection on disk storage. If collection data is compressed (which is the default for WiredTiger
), the storage size reflects the compressed size and may be smaller than the value returned by db.collection.dataSize()
.db.collection.totalIndexSize()
to return the index sizes in bytes for the collection. If an index uses prefix compression (which is the default for WiredTiger
), the returned size reflects the compressed size.The following script prints the statistics for each database:
The following script prints the statistics for each collection in each database:
To view the size of the data allocated for each index, use the db.collection.stats()
method and check the indexSizes
field in the returned document.
If an index uses prefix compression (which is the default for WiredTiger
), the returned size for that index reflects the compressed size.
The db.stats()
method in the mongo
shell returns the current state of the “active” database. For the description of the returned fields, see dbStats Output.