mongo基础之 存储引擎对比(9)

1. MongoDB存储引擎构架

插件式存储引擎， MongoDB 3.0引入了插件式存储引擎API，为第三方的存储引擎厂商加入MongoDB提供了方便，这一变化无疑参考了MySQL的设计理念。目前除了早期的MMAP存储引擎外，WiredTiger和RocksDB均 已完成了对MongoDB的支持，前者更是在被MongoDB公司收购后更是直接引入到了MongoDB 3.0版本中。插件式存储引擎API的引入为MongoDB丰富自己武器库以处理更多不同类型的业务提供了无限可能，内存存储引擎、事务存储引擎甚至 Hadoop在未来都有可能接入进来。

图1-1 MongoDB <= 2.6 存储引擎构架

图1-2 MongoDB 3.0 存储引擎构架

1. MongoDB存储引擎说明
   • WiredTiger

如 果说插件式存储引擎API为MongoDB 3.0打造了一个武器库，那么WiredTiger绝对是武器库中第一枚也是最重要的一枚重磅炸弹。因为MMAP存储引擎自身的天然缺陷（耗费磁盘空间和 内存空间且难以清理，库级别锁），MongoDB为数据库运维人员带来了极大痛苦，甚至一部分人已经开始转向TokuMX，尽管后者目前也不甚稳定。意识到这一问题的MongoDB，做出了有钱任性的决定，直接收购存储引擎厂商WiredTiger，将WiredTiger存储引擎集成进3.0版本（仅在64位版本中提供）。那么这款走到聚光灯下的存储引擎究竟具备哪些值得期待的特性呢？

• 文档级别并发控制

WiredTiger 通过MVCC实现文档级别的并发控制，即文档级别锁。这就允许多个客户端请求同时更新一个集合内存的多个文档，再也不需要在排队等待 库级别的写锁。这在提升数据库读写性能的同时，大大提高了系统的并发处理能力。关于这一点的效果从监控工具mongostat就可以直接体现出来，旧版本 的监控指标会有locked db这一项（该项指标过高是mongo使用人员的一大痛点啊），而新版的mongostat已经看不到了。

图2.1.1 文档级别并发控制

• 磁盘数据压缩

WiredTiger 支持对所有集合和索引进行Block压缩和前缀压缩（如果数据库启用了journal，journal文件一样会压缩），已支持的压 缩选项包括：不压缩、Snappy压缩和Zlib压缩。这为广大Mongo使用者们带来了又一福音，因为很多Mongo数据库都是因为MMAP存储引擎消 耗了过多的磁盘空间而不得已进行扩容。其中Snappy压缩为数据库的默认压缩方式，用户可以根据业务需求选择适合的压缩方式。理论上来说，Snappy 压缩速度快，压缩率OK，而Zlib压缩率高，CPU消耗多且速度稍慢。当然，只要选择使用压缩，Mongo肯定会占用更多的CPU使用率，但是考虑到 Mongo本身并不是十分耗CPU，所以启用压缩完全是值得的。

图2.1.1-1 磁盘数据压缩 snappy

图2.1.1-1 磁盘数据压缩 zlib

• 存储方式改变

此 外，WiredTiger存储方式上也有很大改进。旧版本Mongo在数据库级别分配文件，数据库中的所有集合和索引都混合存储在数据库文件中，所以即 使删掉了某个集合或者索引，占用的磁盘空间也很难及时自动回收。WiredTiger在集合和索引级别分配文件，数据库中的所有集合和索引均存储在单独的 文件中，集合或者索引删除后，对应的存储文件随即删除。当然，因为存储方式不同，低版本的数据库无法直接升级到WiredTiger存储引擎，只能通过导 出导入数据的方式来实现。

• 可配置内存使用上限

WiredTiger 支持内存使用容量配置，用户通过storage.wiredTiger.engineConfig.cacheSizeGB参数即可 控制MongoDB所能使用的最大内存，该参数默认值为物理内存大小的一半。这也为广大Mongo使用者们带来了又一福音，MMAP存储引擎消耗内存是出 了名的，只要数据量够大，简直就是有多少用多少。

• MMAPv1

MongoDB 3.0出了引入WiredTiger外，对于原有的存储引擎MMAP也进行了一定的完善，该存储引擎依然是3.0版的默认存储引擎。遗憾的是改进后的 MMAP存储引擎依旧在数据库级别分配文件，数据库中的所有集合和索引都混合存储在数据库文件中，所以磁盘空间无法及时自动回收的问题如故。

• 锁粒度由库级别锁提升为集合级别锁

这在一定程度上也能够提升数据库的并发处理能力。

• 文档空间分配方式改变

在 MMAP存储引擎中，文档按照写入顺序排列存储。如果文档更新后长度变长且原有存储位置后面没有足够的空间放下增长部分的数据，那么文档就要移动到文件 中的其他位置。这种因更新导致的文档位置移动会严重降低写性能，因为一旦文档发生移动，集合中的所有索引都要同步修改文档新的存储位置。

MMAP 存储引擎为了减少这种情况的发生提供了两种文档空间分配方式：基于paddingFactor（填充因子）的自适应分配方式和基于 usePowerOf2Sizes的预分配方式，其中前者为默认方式。第一种方式会基于每个集合中文档更新历史计算文档更新的平均增长长度，然后在新文档 插入或旧文档移动时填充一部分空间，如当前集合paddingFactor的值为1.5，那么一个大小为200字节的文档插入时就会自动在文档后填充 100个字节的空间。第二种方式则不考虑更新历史，直接为文档分配2的N次方大小的存储空间，如一个大小同样为200字节的文档插入时直接分配256个字 节的空间。

MongoDB 3.0版本中的MMAPv1抛弃了基于paddingFactor的自适应分配方式，因为这种方式看起来很智能，但是因为一个集合中的文档的大小不一，所 以经过填充后的空间大小也不一样。如果集合上的更新操作很多，那么因为记录移动后导致的空闲空间会因为大小不一而难以重用。目前基于 usePowerOf2Sizes的预分配方式成为默认的文档空间分配方式，这种分配方式因为分配和回收的空间大小都是2的N次方（当大小超过2MB时则 变为2MB的倍数增长），因此更容易维护和利用。如果某个集合上只有insert或者in-place update，那么用户可以通过为该集合设置noPadding标志位，关闭空间预分配。

图2.2.2 存储引擎空间管理

1. MongoDB存储引擎性能对比
   • 官方数据，基于YCSB测试，WiredTiger引擎

YCSB被一些机构用来作为对几个不同数据库的性能测试的一个工具。YCSB功能是相当有限的，并不一定能够告诉你所有你想了解的关于你应用程序性能方面的信息。当然，YCSB还是相当流行的，并且MongoDB和其他一些数据库系统的用户也对此比较熟悉。

• 并发量

100%写场景：在YCSB测试中， MongoDB3.0在多线程、批量插入场景下较之于MongoDB2.6有大约7倍的增长。

95%读取和5%更新的场景： WiredTiger 有4倍多的吞吐量。相比于纯插入场景，性能提升没有那么显著，因为写操作只占所有操作的5%。在MongoDB2.6中，并发控制是在数据库级别，而且写会阻塞读操作，从而降低总体的并发量。通过这次测试，我们看到MongoDB 3.0更加细粒的并发性控制明显提高了总并发量。

读写操作平衡的场景： MongoDB3.0有6倍的并发率。这比95%读 的4倍提高要好一些，因为这里有更多的写操作。

图3.1.1 并发量

• 响应延迟

在性能测试中仅仅监测并发量是不够的，还要考虑操作的响应延迟 。对许多操作的响应延迟做一个平均得来的平均响应延迟值不是一个最好的度量指标。对于想要系统有持续良好、低延时体验的开发者来说，他们更关注在这个系统 中效能最低的操作。 高延时查询通常用95th和99th百分位数来衡量 – 95th 百分位数表示这个数值（响应延迟）比95%的其他操作都要糟糕（慢）。（有人可能会觉得这种衡量不够准确： 因为很多网页请求会使用几百个数据库操作， 那么很可能绝大部分用户都会经历到这些99th百分位数的慢响应延迟 ）

在读操作响应延迟上看到在MongoDB2.6和MongoDB3.0之间的差别是非常微小的，读操作响应延迟很稳定的保持在1ms或者更少的数值内。然而更新操作响应延迟则有相当大的区别 。

图3.1.2-1响应延迟，读密集型

在这里我们通过读密集型的工作负荷来比较更新响应延迟的95th和99th百分位数 。在MongoDB3.0中更新延时显著改善了，在95th和99th百分位数中几乎减少了90%。这很重要，提高并发量不应该以更长的延时为代价，因为 这将最终降低应用程序 的用户体验。

图3.1.2-1响应延迟，平衡型

在平衡的工作负荷下，更新延迟仍然保持在较低的水平 。在95th百分位数，MongoDB3.0的更新延迟比MongoDB2.6几乎低90%，而99th百分位数则低80% 。这些改善可以给用户带来更好的使用体验，更加可预测的性能。
我们相信这些针对并发量和响应延迟的测试证明了MongoDB在写性能上有了显著的提高。

• 提供充足客户端能力

大多数数据库都是为多线程客户端设计的 。通过逐步增加线程数来找到最佳的数量 – 增加更多线程直到你发现并发率停止上升或者响应时间在增加。

图3.1.3-1多线程MMAP、WiredTiger吞吐量对比

图3.1.3-1 WiredTiger吞吐量延迟对比

• 实际测试

时间关系，本人未做相关测试，网上收录部分测试数据；

• 案例一

公司某个APP应用的数据库已 经实现了日志与业务的垂直分割，将原有的一套RAC，拆分成两套，目前数据库暂时还比较稳定，服务器负载也在正常范围内，但是现有用户数450万，日活跃 用户达到100万，每日日志产生1000万条记录，100G的数据量，而目标用户数接近1800万，预估届时的每日数据库将达到6000万/条，且需要满 足单条记录查询的需求，计划采用MongoDB来替代ORACLE RAC，现测试MongoDB WiredTiger引擎与MMAPv1引擎的写入对比。

测试场景：插入1000万条数据的时间消耗对比；

测试结果：MongoDB MMAPv1写入配置：1000万条数据写入花费了12分钟28秒；MongoDB WiredTiger写入配置：1000万条数据写入花费了10分3秒。

• 案例二

某项目在设计初期使用了mongodb2.6，由于开发设计失误在mongodb中使用了一个很大的数据。而该业务每天需要全亮更新每一个文档，也就是更 新数组字段，这致使在ssd上依然出现了性能问题，而由于该项目已经不再更新处于维护节点并且之前的开发已离职，导致无法通过修改业务逻辑变更数据结构来 调优。

将其迁移到mongodb3.0后数据提及从202G降低到36G，同时更新性能提高五倍，完美解决了性能问题。

• 案例三

Mongdob3.0.2的一个项目使用汇报：

之前使用18分片的mongoS集群，用于业务的统计分析，比如404、503、请求量以及网址请求次数等等。

mongodb的使用场景为：

• 每秒写入2万条数据，其中insert和update比例为3：7，全部使用upsert方法
• 全部查询均为统计类查询，用于画图

在今年年初由于写入并发量不断增长到3万条每秒，导致出现了严重的性能问题，现象为：

• 写入队列积压，每天大概积压80G数据，数据延迟写入22小时，也就是现在的数据，22小时候才能看到
• 查询基本不可用，无法在页面通过统计绘图了

在4月26号升级到了3.0.2，结果如下：

• 写入队列无任何积压，实时写入
• 查询速度暴快，绘图秒出
• 分片减少了一半，从18个变为9个，每个分片使用2块独立的ssd，等于0为我们省下了18块ssd
• 数据总体积的变化：从3T变成了不到600G
• 慢更新消失了（500ms以上的操作会记录日志）

1. 总结

从官方数据和实际使用效果来说，WiredTiger引擎总体上胜出MMAPv1，不论从内存使用效率和存储空间使用效率，还是其写入更新效率，所以在选用MongoDB3.0以上版本时建议还是采用WiredTiger引擎。

但是需要注意一下几点：

首先其在Windows上的性能指标不如Linux，所以搭载服务器最好选用Linux系；

其次Journal 默认不会即时刷盘，系统宕机会丢失最多100MB Journal数据；

再有其不提供32位 支持；

 

 

 

存储引擎（Storage Engine）是MongoDB的核心组件，负责管理数据如何存储在硬盘（Disk）和内存（Memory）上。从MongoDB 3.2 版本开始，MongoDB 支持多数据存储引擎（Storage Engine），MongoDB支持的存储引擎有：WiredTiger，MMAPv1和In-Memory。

从MongoDB 3.2 版本开始，WiredTiger成为MongDB默认的Storage Engine，用于将数据持久化存储到硬盘文件中，WiredTiger提供文档级别（Document-Level）的并发控制，检查点（CheckPoint），数据压缩和本地数据加密（ Native Encryption）等功能。

MongoDB不仅能将数据持久化存储到硬盘文件中，而且还能将数据只保存到内存中；In-Memory存储引擎用于将数据只存储在内存中，只将少量的元数据和诊断日志（Diagnostic）存储到硬盘文件中，由于不需要Disk的IO操作，就能获取索取的数据，In-Memory存储引擎大幅度降低了数据查询的延迟（Latency）。

一，指定MongoDB实例的存储引擎

mongod 参数： --storageEngine  wiredTiger | inMemory

指定Storage Engine的类型，

• 如果参数值是wiredTiger，MongoDB使用的存储引擎是WiredTiger，将数据持久化存储在Disk Files中；
• 如果参数值是inMemory，MongoDB使用的存储引擎是In-Memory，将数据存储在内存中；
• 从MongoDB 3.2 版本开始，MongoDB默认的存储引擎是WiredTiger；

二，WiredTiger 存储引擎将数据存储到硬盘文件（Disk Files）

WiredTiger和MMAPv1都用于持久化存储数据，相对而言，WiredTiger比MMAPv1更新，功能更强大。

1，文档级别的并发控制（Document-Level Concurrency Control）

MongoDB在执行写操作时，WiredTiger 在文档级别进行并发控制，就是说，在同一时间，多个写操作能够修改同一个集合中的不同文档；当多个写操作修改同一个文档时，必须以序列化方式执行；这意味着，如果该文档正在被修改，其他写操作必须等待，直到在该文档上的写操作完成之后，其他写操作相互竞争，获胜的写操作在该文档上执行修改操作。

对于大多数读写操作，WiredTiger使用乐观并发控制（optimistic concurrency control），只在Global，database和Collection级别上使用意向锁（Intent Lock），如果WiredTiger检测到两个操作发生冲突时，导致MongoDB将其中一个操作重新执行，这个过程是系统自动完成的。

For most read and write operations, WiredTiger uses optimistic concurrency control. 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.

2，检查点（Checkpoint）

在Checkpoint操作开始时，WiredTiger提供指定时间点（point-in-time）的数据库快照（Snapshot），该Snapshot呈现的是内存中数据的一致性视图。当向Disk写入数据时，WiredTiger将Snapshot中的所有数据以一致性方式写入到数据文件（Disk Files）中。一旦Checkpoint创建成功，WiredTiger保证数据文件和内存数据是一致性的，因此，Checkpoint担当的是还原点（Recovery Point），Checkpoint操作能够缩短MongoDB从Journal日志文件还原数据的时间。

当WiredTiger创建Checkpoint时，MongoDB将数据刷新到数据文件（Disk Files）中，在默认情况下，WiredTiger创建Checkpoint的时间间隔是60s，或产生2GB的Journal文件。在WiredTiger创建新的Checkpoint期间，上一个Checkpoint仍然是有效的，这意味着，即使MongoDB在创建新的Checkpoint期间遭遇到错误而异常终止运行，只要重启，MongoDB就能从上一个有效的Checkpoint开始还原数据。

当MongoDB以原子方式更新WiredTiger的元数据表，使其引用新的Checkpoint时，表明新的Checkpoint创建成功，MongoDB将老的Checkpoint占用的Disk空间释放。使用WiredTiger 存储引擎，如果没有记录数据更新的日志，MongoDB只能还原到上一个Checkpoint；如果要还原在上一个Checkpoint之后执行的修改操作，必须使用Jounal日志文件。

3，预先记录日志（Write-ahead Transaction Log）

WiredTiger使用预写日志的机制，在数据更新时，先将数据更新写入到日志文件，然后在创建Checkpoint操作开始时，将日志文件中记录的操作，刷新到数据文件，就是说，通过预写日志和Checkpoint，将数据更新持久化到数据文件中，实现数据的一致性。WiredTiger 日志文件会持久化记录从上一次Checkpoint操作之后发生的所有数据更新，在MongoDB系统崩溃时，通过日志文件能够还原从上次Checkpoint操作之后发生的数据更新。

The WiredTiger journal persists all data modifications between checkpoints. If MongoDB exits between checkpoints, it uses the journal to replay all data modified since the last checkpoint.

3，内存使用

3.1 WiredTiger 利用系统内存资源缓存两部分数据：

• 内部缓存（Internal Cache）
• 文件系统缓存（Filesystem Cache）

从MongoDB 3.2 版本开始，WiredTiger内部缓存的使用量，默认值是：1GB 或 60% of RAM - 1GB，取两值中的较大值；文件系统缓存的使用量不固定，MongoDB自动使用系统空闲的内存，这些内存不被WiredTiger缓存和其他进程使用，数据在文件系统缓存中是压缩存储的。

3.2 调整WiredTiger内部缓存的大小

使用 mongod的参数 --wiredTigerCacheSizeGB 来修改MongoDB实例中WiredTiger内部缓存的大小，计算内部缓存大小的公式是：

• Starting in MongoDB 3.2, the WiredTiger internal cache, by default, will use the larger of either: 60% of RAM minus 1 GB, or 1 GB.
• For systems with up to 10 GB of RAM, the new default setting is less than or equal to the 3.0 default setting 
• For systems with more than 10 GB of RAM, the new default setting is greater than the 3.0 setting.

4，数据压缩（Data Compression）

WiredTiger压缩存储集合（Collection）和索引（Index），压缩减少Disk空间消耗，但是消耗额外的CPU执行数据压缩和解压缩的操作。

默认情况下，WiredTiger使用块压缩（Block Compression）算法来压缩Collections，使用前缀压缩（Prefix Compression）算法来压缩Indexes，Journal日志文件也是压缩存储的。对于大多数工作负载（Workload），默认的压缩设置能够均衡（Balance）数据存储的效率和处理数据的需求，即压缩和解压的处理速度是非常高的。

5，Disk空间回收

当从MongoDB中删除文档（Documents）或集合（Collections）后，MongoDB不会将Disk空间释放给OS，MongoDB在数据文件（Data Files）中维护Empty Records的列表。当重新插入数据后，MongoDB从Empty Records列表中分配存储空间给新的Document，因此，不需要重新开辟空间。为了更新有效的重用Disk空间，必须重新整理数据碎片。

WiredTiger使用compact 命令，移除集合（Collection）中数据和索引的碎片，并将unused的空间释放，调用语法：

db.runCommand ( { compact: '<collection>' } )

在执行compact命令时，MongoDB会对当前的database加锁，阻塞其他操作。在compact命令执行完成之后，mongod会重建集合的所有索引。

On WiredTiger, compact will rewrite the collection and indexes to minimize disk space by releasing unused disk space to the operating system. This is useful if you have removed a large amount of data from the collection, and do not plan to replace it.

二，In-Memory 存储引擎将数据存储到内存（Memory）

In-Memory存储引擎将数据存储在内存中，除了少量的元数据和诊断（Diagnostic）日志，In-Memory存储引擎不会维护任何存储在硬盘上的数据（On-Disk Data），避免Disk的IO操作，减少数据查询的延迟。

1，指定In-Memory存储引擎

mongod --storageEngine inMemory --dbpath <path>

在选择In-Memory存储引擎时，需要指定两个参数：

• 设置mongod参数： --storageEngine ，设置参数的值是 inMemory；
• 设置mongod参数： --dbpath ，设置参数的值是数据存储的目录；
• 使用Disk存储元数据，诊断数据和临时数据：虽然 In-Memory 存储引擎不会向文件系统写入数据，但是它需要使用 --dbpath 维护少量的元数据和诊断（Diagnostic ）日志，在创建Large Index时，使用Disk存储临时数据；Although the in-memory storage engine does not write data to the filesystem, it maintains in the --dbpath small metadata files and diagnostic data as well temporary files for building large indexes.

2，文档级别的并发（document-level concurrency）

In-Memory存储引擎在执行写操作时，使用文件级别的并发控制，就是说，在同一时间，多个写操作能够同时修改同一个集合中的不同文档；当多个写操作修改同一个文档时，必须以序列化方式执行；这意味着，如果该文档正在被修改，其他写操作必须等待。

3，内存使用

In-Mmeory 存储引擎需要将Data，Index，Oplog等存储到内存中，通过mongod参数： --inMemorySizeGB 设置占用的内存数量，默认值是：50% of RAM-1GB。指定In-Memory 存储引擎使用的内存数据量，单位是GB：

mongod --storageEngine inMemory --dbpath <path> --inMemorySizeGB <newSize>

4，持久化（Durable）

由于In-Memory 存储引擎不会持久化存储数据，只将数据存储在内存中，读写操作直接在内存中完成，不会将数据写入到Disk文件中，因此，不需要单独的日志文件，不存在记录日志和等待数据持久化的问题，当MongoDB实例关机或系统异常终止时，所有存储在内存中的数据都将会丢失。

5，记录oplog

In-Memory 存储引擎不会将数据更新写入到Disk，但是会记录oplog，该oplog是存储在内存中的集合，MongoDB通过Replication将Primary成员的oplog推送给同一副本集的其他成员。如果一个MongoDB实例是Replica Set的Primary成员，该实例使用In-Memory存储引擎，通过Replication将oplog推送到其他成员，在其他成员中重做oplog中记录的操作，这样，就能将在Primary成员中执行的数据修改持久化存储。

You can deploy mongod instances that use in-memory storage engine as part of a replica set. For example, as part of a three-member replica set, you could have:

• two mongod instances run with in-memory storage engine.
• one mongod instance run with WiredTiger storage engine. Configure the WiredTiger member as a hidden member (i.e. hidden: true and priority: 0).

With this deployment model, only the mongod instances running with the in-memory storange engine can become the primary. Clients connect only to the in-memory storage engine mongod instances. Even if both mongod instances running in-memory storage engine crash and restart, they can sync from the member running WiredTiger. The hidden mongod instance running with WiredTiger persists the data to disk, including the user data, indexes, and replication configuration information.

三，记录日志

数据是MongoDB的核心，MongoDB必须保证数据的安全，不能丢失，Journal 是顺序写入的日志文件，用于记录上一个Checkpoint之后发生的数据更新，能够将数据库从系统异常终止事件中还原到一个有效的状态。MongoDB使用预写日志机制实现数据的持久化：WiredTiger 存储引擎在执行写操作时，先将数据更新写入到Journal文件。Journal Files是存储在硬盘的日志文件，每个Journal File大约是100MB，存储在--dbpath下的Journal子目录中，在执行Checkpoint操作，将数据的更新同步到数据文件。

每隔一定的时间间隔，WiredTiger 存储引擎都会执行Checkpoint操作，将缓存的数据更新日志同步到硬盘上的数据文件中（On-Disk Files），在默认情况下，MongoDB启用日志记录，也可以显式启用，只需要在启动mongod 时使用--journal 参数：

mongod --journal

1，使用Journal日志文件还原的过程

WiredTiger创建Checkpoint，能够将MongoDB数据库还原到上一个CheckPoint创建时的一致性状态，如果MongoDB在上一个Checkpoint之后异常终止，必须使用Journal日志文件，重做从上一个Checkpoint之后发生的数据更新操作，将数据还原到Journal记录的一致性状态，使用Journal日志还原的过程是：

1. 获取上一个Checkpoint创建的标识值：从数据文件（Data Files）中查找上一个Checkpoint发生的标识值（Identifier）；
2. 根据标识值匹配日志记录：从Journal Files 中搜索日志记录（Record），查找匹配上一个Checkpoint的标识值的日志记录；
3. 重做日志记录：重做从上一个Checkpoint之后，记录在Journal Files中的所有日志记录；

2，缓存日志

MongoDB配置WiredTiger使用内存缓冲区来存储Journal Records，所有没有达到128KB的Journal Records都会被缓存在缓冲区中，直到大小超过128KB。在执行写操作时，WiredTiger将Journal Records存储在缓冲区中，如果MongoDB异常关机，存储在内存中的Journal Records将丢失，这意味着，WiredTiger将丢失最大128KB的数据更新。

WiredTiger syncs the buffered journal records to disk according to the following intervals or conditions:

• New in version 3.2: Every 50 milliseconds.

• 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.

• If the write operation includes a write concern of j: true, WiredTiger forces a sync of the WiredTiger journal files.

• Because MongoDB uses a journal file size limit of 100 MB, WiredTiger creates a new journal file approximately every 100 MB of data. When WiredTiger creates a new journal file, WiredTiger syncs the previous journal file.

3，日志文件（Journal Files）

关于Journal文件，MongoDB在 --dbpath 目录下创建 journal子目录，WiredTiger将Journal 文件存储在该目录下，每一个Journal文件大约是100M，命名格式是：WiredTigerLog.<sequence>，sequence是一个左边填充0的10位数字，从0000000001开始，依次递增。

对于WiredTiger存储引擎，Journal 文件具有以下特性：

• 标识日志记录：Journal文件的每一个日志记录（Record）代表一个写操作；每一个记录都有一个ID，用于唯一标识该记录；
• 压缩Journal文件：WiredTiger会压缩存储在Journal文件中的数据；
• Journal文件大小的上限：每一个Journal文件大小的上限大约是100MB，一旦文件超过该限制，WiredTiger创建一个新的Journal文件；
• 自动移除Journal文件：WiredTiger自动移除老的Journal文件，只维护从上一个Checkpoint还原时必需的Journal文件；
• 预先分配Journal文件：WiredTiger预先分配Journal文件；

4，在异常宕机后恢复数据

在MongoDB实例异常宕机后，重启mongod实例，MongoDB自动重做（redo）所有的Journal Files，在还原Journal Files期间，MongoDB数据库是无法访问的。

四，mongod 跟存储引擎相关的参数

1，使用WiredTiger的参数设置

mongod 
--storageEngine wiredTiger 
--dbpath <path> 
--journal --wiredTigerCacheSizeGB <value>
--wiredTigerJournalCompressor <compressor>
--wiredTigerCollectionBlockCompressor <compressor>
--wiredTigerIndexPrefixCompression <boolean>

2，使用In-Memory的参数设置

mongod 
--storageEngine inMemory
--dbpath <path> 
--inMemorySizeGB <newSize>
--replSet <setname>
--oplogSize <value>

 参考 https://www.cnblogs.com/phpandmysql/p/7763420.html