MongoDB学习笔记之WiredTiger读写模型详解

一、WiredTiger介绍

MongoDB从3.0开始引入可插拔存储引擎的概念。目前主要有MMAPV1，WiredTiger存储引擎可供选择。在3.22源的消耗，节省约60%以上的硬盘资源。

二、WiredTiger读写模型

读缓存

理想情况下，MongoDB可以提供近似内存式的读写性能。WiredTiger引擎实现了数据的二级缓存，第一层是操作系统的页面缓存，第二层则是引擎提供的内部缓存。

读取数据时的流程如下：

1、数据库发起Buffer I/O读操作，由操作系统将磁盘数据页加载到文件系统的页缓存区。

2、引擎层读取页缓存区的数据，进行解压后存放到内部缓存区。

3、在内存中完成匹配查询，将结果返回给应用。

MongoDB为了尽可能保证业务查询的“热数据”能快速被访问，其内部缓存的默认大小达到了内存中的一半，该值由WiredTigerCacheSize参数指定，其默认的计算公式如下：

wiredTigerCacheSize=Math.max((RAM/2-1GB),256MB)

写缓冲

当数据发生写入时，MongoDB并不会立即持久化到磁盘上，而是先在内存中记录这些变更，之后通过CheckPoint机制将变化的数据写入磁盘。为什么要这么处理？主要有以下两个原因：

1、如果每次写入都触发一次磁盘I/O,那么开销太大，而且响应时延会比较大

2、多个变更的写入可以尽可能进行I/O合并，降低资源负荷。

思考：MongoDB会丢数据吗？

MongoDB单机下保证数据可靠性的机制包括以下两个部分：

CheckPoint（检查点）机制

快照（snapshot）描述了某一时刻（point-in-time）数据在内存中的一致性视图，而这种数据的一致性是WiredTiger通过MVCC（多版本并发控制）实现的。当建立CheckPoint时，WiredTiger会在内存中建立所有数据的一致性快照，并将该快照覆盖的所有数据变化一并进行持久化（fsync）。成功之后，内存中数据的修改才得以真正保存。默认情况下，MongoDB每60s建立一次CheckPoint，在检查点写入过程中，上一个检查点仍然是可用的。这样可以保证一旦出错，MongDB仍然能恢复到上一个检查点。

Journal日志

Journal是一种预写式日志（write ahead log）机制，主要用来弥补CheckPoint机制的不足，如果开启了Journal日志，那么WiredTiger会将每个写操作的redo日志写入Journal缓冲区，该缓冲区会频繁地将日志持久化到磁盘上。默认情况下，Journal缓冲区每100ms执行一次持久化。此外，Journal日志达到100MB，或是应用程序指定Journal：true，写操作都会触发日志的持久化。一旦MongoDB发生宕机，重启程序时会先恢复到上一个检查点，然后根据Journal日志恢复增量的变化。由于Journal日志持久化的间隔非常短，数据能得到更高的保障，如果按照当前版本的默认配置，则其在断电情况下最多会丢失100ms的写入数据。

 

WiredTiger写入数据的流程：

1、应用向MongoDB写入数据（插入、修改或删除）

2、数据库从内部缓存中获取当前记录所在的业块，如果不存在则会从磁盘中加载（Buffer I/O）

3、WiredTiger开始执行写事务，修改的数据写入页块的一个更新记录表，此时原来的记录仍然保持不变

4、如果开启了Journal日志，则在写数据的同时会写入一条Journal日志（Redo Log）。该日志在最长不超过100ms后写入磁盘。

5、数据库每隔60s执行一次CheckPoint操作，此时内存中的修改会真正刷入磁盘。

Journal日志的刷新周期可以通过参数storage.journal.commitIntervalMs指定，MongoDB 3.4及以下版本的默认值是50ms，而3.6版本之后调整到了100ms。由于Journal日志采用的是顺序I/O写操作，频繁地写入对磁盘的影响并不是很大。

CheckPoint的刷新周期可以调整storage.syncPeriodSecs参数（默认值60s），在MongoDB 3.4及以下版本中，当Journal日志达到2GB时同样会触发CheckPoint行为。如果应用存在大量随机写入，则CheckPoint可能会造成磁盘I/O的抖动。在磁盘性能不足的情况下，问题会更加显著，此时适当缩短CheckPoint周期可以让写入平滑一些。