WiredTiger Storage EngineWiredTiger存储引擎
On this page本页内容
Starting in MongoDB 3.2, the WiredTiger storage engine is the default storage engine. 从MongoDB 3.2开始，WiredTiger存储引擎是默认的存储引擎。For existing deployments, if you do not specify the 对于现有部署，如果未指定--storageEngine or the storage.engine setting, the version 3.2+ mongod instance can automatically determine the storage engine used to create the data files in the --dbpath or storage.dbPath. --storageEngine或storage.engine设置，则版本3.2+mongod实例可以自动确定用于在--dbpath或storage.dbPath中创建数据文件的存储引擎。See Default Storage Engine Change.请参阅默认存储引擎更改。
Operation and Limitations操作和限制
The following operational notes and limitations apply to the WiredTiger engine:以下操作注意事项和限制适用于WiredTiger发动机：
You can't pin documents to the WiredTiger cache.无法将文档固定到WiredTiger缓存。WiredTiger doesn't reserve a portion of the cache for reads and another for writes.WiredTiger不保留缓存的一部分用于读取，另一部分用于写入。A heavy write workload can affect performance, but WiredTiger prioritizes index caching in such cases.繁重的写入工作负载可能会影响性能，但在这种情况下，WiredTiger会优先考虑索引缓存。WiredTiger allocates its cache to the entireWiredTiger将其缓存分配给整个mongodinstance. WiredTiger doesn't allocate cache on a per-database or per-collection level.mongod实例。WiredTiger不按每个数据库或每个集合级别分配缓存。
Document Level Concurrency文档级并发
WiredTiger uses document-level concurrency control for write operations. WiredTiger使用文档级并发控制进行写操作。As a result, multiple clients can modify different documents of a collection at the same time.因此，多个客户端可以同时修改集合的不同文档。
For most read and write operations, WiredTiger uses optimistic concurrency control. 对于大多数读写操作，WiredTiger使用乐观并发控制。WiredTiger uses only intent locks at the global, database and collection levels. When the storage engine detects conflicts between two operations, one will incur a write conflict causing MongoDB to transparently retry that operation.WiredTiger仅在全局、数据库和集合级别使用意向锁。当存储引擎检测到两个操作之间的冲突时，其中一个操作将引发写冲突，导致MongoDB透明地重试该操作。
Some global operations, typically short lived operations involving multiple databases, still require a global "instance-wide" lock. Some other operations, such as 一些全局操作，通常是涉及多个数据库的短期操作，仍然需要全局“实例范围”锁定。其他一些操作，如collMod, still require an exclusive database lock.collMod，仍然需要独占数据库锁。
Snapshots and Checkpoints快照和检查点
WiredTiger uses MultiVersion Concurrency Control (MVCC). At the start of an operation, WiredTiger provides a point-in-time snapshot of the data to the operation. A snapshot presents a consistent view of the in-memory data.WiredTiger使用多版本并发控制（MVCC）。在操作开始时，WiredTiger会为操作提供数据的时间点快照。快照提供内存中数据的一致视图。
When writing to disk, WiredTiger writes all the data in a snapshot to disk in a consistent way across all data files. 在写入磁盘时，WiredTiger会在所有数据文件中以一致的方式将快照中的所有数据写入磁盘。The now-durable data act as a checkpoint in the data files. 现在持久的数据充当数据文件中的检查点。The checkpoint ensures that the data files are consistent up to and including the last checkpoint; i.e. checkpoints can act as recovery points.检查点确保数据文件在最后一个检查点之前（包括该检查点）是一致的；检查点可以作为恢复点。
Starting in version 3.6, MongoDB configures WiredTiger to create checkpoints (i.e. write the snapshot data to disk) at intervals of 60 seconds. In earlier versions, MongoDB sets checkpoints to occur in WiredTiger on user data at an interval of 60 seconds or when 2 GB of journal data has been written, whichever occurs first.从3.6版本开始，MongoDB将WiredTiger配置为每隔60秒创建一个检查点（即将快照数据写入磁盘）。在早期版本中，MongoDB将检查点设置为在WiredTiger中每隔60秒或写入2GB日志数据时（以先发生者为准）对用户数据进行检查。
During the write of a new checkpoint, the previous checkpoint is still valid. As such, even if MongoDB terminates or encounters an error while writing a new checkpoint, upon restart, MongoDB can recover from the last valid checkpoint.在写入新检查点期间，上一个检查点仍然有效。因此，即使MongoDB在编写新的检查点时终止或遇到错误，在重新启动时，MongoDB也可以从最后一个有效的检查点恢复。
The new checkpoint becomes accessible and permanent when WiredTiger's metadata table is atomically updated to reference the new checkpoint. Once the new checkpoint is accessible, WiredTiger frees pages from the old checkpoints.当WiredTiger的元数据表被原子更新以引用新的检查点时，新的检查点将变得可访问且永久。一旦可以访问新的检查点，WiredTiger就会从旧的检查点释放页面。
Snapshot History Retention快照历史记录保留
Starting in MongoDB 5.0, you can use the 从MongoDB 5.0开始，您可以使用minSnapshotHistoryWindowInSeconds parameter to specify how long WiredTiger keeps the snapshot history.minSnapshotHistoryWindowInSeconds参数来指定WiredTiger保存快照历史的时间。
Increasing the value of 增加minSnapshotHistoryWindowInSeconds increases disk usage because the server must maintain the history of older modified values within the specified time window. The amount of disk space used depends on your workload, with higher volume workloads requiring more disk space.minSnapshotHistoryWindowInSeconds的值会增加磁盘使用量，因为服务器必须在指定的时间窗口内维护旧的修改值的历史记录。使用的磁盘空间量取决于您的工作负载，卷越大的工作负载需要更多的磁盘空间。
MongoDB maintains the snapshot history in the WiredTigerHS.wt file, located in your specified dbPath.
Journal日志
WiredTiger uses a write-ahead log (i.e. journal) in combination with checkpoints to ensure data durability.WiredTiger将预写日志（即日志）与检查点结合使用，以确保数据的持久性。
The WiredTiger journal persists all data modifications between checkpoints. WiredTiger日志保存检查点之间的所有数据修改。If MongoDB exits between checkpoints, it uses the journal to replay all data modified since the last checkpoint. 如果MongoDB在检查点之间退出，它会使用日志来回放自上次检查点以来修改的所有数据。For information on the frequency with which MongoDB writes the journal data to disk, see Journaling Process.有关MongoDB将日志数据写入磁盘的频率的信息，请参阅日志处理。
WiredTiger journal is compressed using the snappy compression library. WiredTiger日志使用snappy压缩库进行压缩。To specify a different compression algorithm or no compression, use the 要指定不同的压缩算法或不指定压缩，请使用storage.wiredTiger.engineConfig.journalCompressor setting. For details on changing the journal compressor, see Change WiredTiger Journal Compressor.storage.wiredTiger.engineConfig.journalCompressor设置。有关更换轴颈压缩机的详细信息，请参阅更换WiredTiger日志压缩机。
If a log record less than or equal to 128 bytes (the mininum log record size for WiredTiger), WiredTiger does not compress that record.如果日志记录小于或等于128字节（WiredTiger的最小日志记录大小），WiredTige不会压缩该记录。
See also: 另请参阅：
Compression压缩
With WiredTiger, MongoDB supports compression for all collections and indexes. Compression minimizes storage use at the expense of additional CPU.通过WiredTiger，MongoDB支持对所有集合和索引进行压缩。压缩以牺牲额外的CPU为代价，最大限度地减少了存储使用。
By default, WiredTiger uses block compression with the snappy compression library for all collections and prefix compression for all indexes.默认情况下，WiredTiger对所有集合使用块压缩和snappy压缩库，对所有索引使用前缀压缩。
For collections, the following block compression libraries are also available:对于集合，还提供以下块压缩库：
To specify an alternate compression algorithm or no compression, use the 要指定备用压缩算法或不指定压缩，请使用storage.wiredTiger.collectionConfig.blockCompressor setting.storage.wiredTiger.collectionConfig.blockCompressor设置。
For indexes, to disable prefix compression, use the 对于索引，要禁用前缀压缩，请使用storage.wiredTiger.indexConfig.prefixCompression setting.storage.wiredTiger.indexConfig.prefixCompression设置。
Compression settings are also configurable on a per-collection and per-index basis during collection and index creation. 在集合和索引创建过程中，还可以根据每个集合和每个索引配置压缩设置。See Specify Storage Engine Options and db.collection.createIndex() storageEngine option.请参阅指定存储引擎选项和db.collection.createIndex()存储引擎选项。
For most workloads, the default compression settings balance storage efficiency and processing requirements.对于大多数工作负载，默认压缩设置会平衡存储效率和处理要求。
The WiredTiger journal is also compressed by default. For information on journal compression, see Journal.WiredTiger日记账在默认情况下也被压缩。有关日记账压缩的信息，请参阅日志。
Memory Use内存使用
With WiredTiger, MongoDB utilizes both the WiredTiger internal cache and the filesystem cache.有了WiredTiger，MongoDB既利用了WiredTinger内部缓存，也利用了文件系统缓存。
Starting in MongoDB 3.4, the default WiredTiger internal cache size is the larger of either:从MongoDB 3.4开始，默认的WiredTiger内部缓存大小是以下两者中较大的一个：
- 50% of (RAM - 1 GB), or
- 256 MB.
For example, on a system with a total of 4GB of RAM the WiredTiger cache will use 1.5GB of RAM (例如，在总内存为4GB的系统上，WiredTiger缓存将使用1.5GB的RAM（0.5 * (4 GB - 1 GB) = 1.5 GB). 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 (相反，总RAM为1.25 GB的系统将为WiredTiger缓存分配256 MB，因为这超过了总RAM的一半减去1 GB（0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB).0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB）。
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.在某些情况下，例如在容器中运行时，数据库的内存约束可能低于系统总内存。在这种情况下，这个内存限制，而不是整个系统内存，被用作可用的最大RAM。
To see the memory limit, see 要查看内存限制，请参阅hostInfo.system.memLimitMB.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.默认情况下，WiredTiger对所有集合使用Snappy块压缩，对所有索引使用前缀压缩。压缩默认值可以在全局级别进行配置，也可以在集合和索引创建期间按每个集合和每个索引进行设置。
Different representations are used for data in the WiredTiger internal cache versus the on-disk format:WiredTiger内部缓存中的数据与磁盘上的格式使用不同的表示形式：
Data in the filesystem cache is the same as the on-disk format, including benefits of any compression for data files. The filesystem cache is used by the operating system to reduce disk I/O.文件系统缓存中的数据与磁盘上的格式相同，包括对数据文件进行任何压缩的好处。操作系统使用文件系统缓存来减少磁盘I/O。Indexes loaded in the WiredTiger internal cache have a different data representation to the on-disk format, but can still take advantage of index prefix compression to reduce RAM usage. Index prefix compression deduplicates common prefixes from indexed fields.WiredTiger内部缓存中加载的索引具有与磁盘上格式不同的数据表示形式，但仍然可以利用索引前缀压缩来减少RAM的使用。索引前缀压缩从索引字段中消除常见前缀的重复。Collection data in the WiredTiger internal cache is uncompressed and uses a different representation from the on-disk format. Block compression can provide significant on-disk storage savings, but data must be uncompressed to be manipulated by the server.WiredTiger内部缓存中的采集数据未压缩，使用不同于磁盘格式的表示形式。块压缩可以显著节省磁盘上的存储空间，但数据必须经过压缩才能由服务器操作。
Via the filesystem cache, MongoDB automatically uses all free memory that is not used by the WiredTiger cache or by other processes.通过文件系统缓存，MongoDB自动使用WiredTiger缓存或其他进程未使用的所有可用内存。
To adjust the size of the WiredTiger internal cache, see 要调整WiredTiger内部缓存的大小，请参阅storage.wiredTiger.engineConfig.cacheSizeGB and --wiredTigerCacheSizeGB. Avoid increasing the WiredTiger internal cache size above its default value.storage.wiredTiger.engineConfig.cacheSizeGB和--wiredTigerCacheSizeGB。避免将WiredTiger内部缓存大小增加到其默认值以上。