MongoDB的WiredTiger存储引擎
从MongoDB 3.2 开始，MongoDB实例默认的存储引擎为WiredTiger，WiredTiger存储引擎具体以下几大优点：
文档级并发
将数据持久化到磁盘
快照和checkpoint
数据压缩
本地数据加密
一、文档级别并发
1、WiredTiger使用文档级别并发，意味着在同一时间，MongoDB实例允许多个对不同文档间的写操作并发执行（复制应用oplog时同样可以做到文档级并发应用）。
2、对于读写操作，MongoDB使用乐观并发控制，WiredTiger仅仅会在数据库或者集合上添加意向锁。
3、一些全局的操作，包括一些涉及多个数据库的操作，仍然需要全局锁。如drop一个集合，仍然需要数据库级别的x锁。
二、journal
2.1 Journal的基本概念
1、WiredTiger使用WAL(journal)和checkpoiont来保证数据的持久性。
2、journal日志记录了两次checkpoint之间的所有数据变更，当MongoDB实例意外宕机时，先恢复实例到last checkpoint时间，然后在journal中找到last checkpoint的唯一标识，开始重放last checkpoint之后的所有数据变更。
3、journal默认使用snappy进行压缩，也可以在配置文件中通过storage.wiredTiger.engineConfig.journalCompressor参数还设置相关的压缩配置。如果一条记录小于128KB，默认不对该记录进行压缩。
4、对于MongoDB单节点，可以使用 storage.journal.enabled 关闭journal，若不开启journal，单数据库宕机后只能将数据恢复到last checkpoint。
2.2 Journal数据恢复
journal属于WiredTiger的WAL的日志，并不是MongoDB实例的日志文件，如果MongoDB实例意外宕机，可以journal可以恢复last checkpoint之后的数据变更操作。journal日志恢复流程大致如下：
1、将数据恢复到last checkpoint；
2、查看data file中last checkpoint的标识符；
3、查看journal日志中last checkpoint的标识符；
3、重放last checkpoint之后的journal日志进行数据恢复（数据最大丢失CommitIntervalms的数据）。
也就是所，当我们通过journal file重放时，丢失的数据就是journal buffer但是没有写入journal file的这部分数据
2.3 Journaling Process机制
1）在开启journal日志的情况下，对数据的每条更新，journal都会记录该更新操作以及其索引的更新。
2）MongoDB会先将数据变更的记录写入到journal buffer中，每条记录（最大128KB）都会被缓存。
3）后续WiredTiger会将journal buffer中的数据写入disk：
从3.2版本开始，MongoDB实例每50ms将journal buffer中的数据刷到磁盘；
当写操作的write concern指定为j:true时，WiredTiger会强制将该写操作写入磁盘；
journal file文件大小限制为100M，当达到限制大小时会创建一个新的journal文件，WiredTiger将之前journal file中的记录写入到磁盘。
2.4 journal file
1）MongoDB会在dbpath路径下创建一个journal的子目录用来存放journal file
2）journal file包括每个客户端发起的所有的数据变更操作
journal记录了包括数据的变更以及索引的变更；
每条记录都有一个唯一的标识；
WiredTiger存储引擎下最小的journal记录为128 bytes.
3）默认情况下，journal file使用snappy进行压缩，可以通过storage.wiredTiger.engineConfig.journalCompressor进行配置
4）journal file大小限制为100MB，WiredTiger会预分配jounal file，且WiredTiger仅仅只维护last checkpoint之所需要的文件
三、snapshots and checkpoints
1、WiredTiger存储引擎支持MVCC，snapshots相当于某个时间点的内存数据的一致性视图。
2、当数据落盘时，WiredTiger将snapshot中的数据一致性写入data file中，并且将当前已经持久化的data file作为最近一次的checkpiont点。checkpoint点可以作为数据恢复的一个时间点。
3、从3.6版本开始，WiredTiger默认每60s刷新一次checkpoint（每60将snapshot刷盘一次）；在3.6版本之前WireTiger默认每60或者journal达到2G时刷新一次checkpoint。
4、只有当新的checkpoint点创建成功后，WigerdTiger才会删除之前的checkpoint。
5、使用WigerdTiger存储引擎，在不开启journal日志的情况下，可以将数据恢复到最后一次checkpoint时刻，但是checkpoint之后的数据无法进行恢复（通过journal进行恢复）。
四、Compression数据压缩
1、在WiredTiger存储引擎下，可以对集合数据以及所有进行压缩，但是压缩会消耗一定的CPU资源。
2、默认情况下，WiredTiger使用snappy对集合数据进行压缩，使用prefix对索引数据进行压缩，在集合和索引创建时，也可以单独指定。
3、默认情况下，journal日志也会使用snappy进行压缩处理。
五、内存使用
1、WiredTiger下，MongoDB使用会利用WiredTiger内部缓存和文件系统缓存。
2、从MongoDB 3.4版本开始，WiredTiger内部缓存默认为50% of (RAM - 1 GB) 或者 256 MB 之间的最大值。
3、WiredTiger内部缓存相对于磁盘格式化的不同：
数据使用文件系统缓存与磁盘格式化是一样的，文件系统缓存主要是用来降低磁盘的IO消耗。
集合索引信息缓存到WiredTiger内部缓存相对磁盘格式化是不同的，但是也主要是为了减少对内存的使用。
集合数据在WiredTiger内部缓存中是不压缩的，相对于磁盘格式也是不同的，块压缩可以极大的节省磁盘空间的使用，但是，数据必须先解压，然后才能供server层使用。
4、对比文件系统缓存，MonogoDB会尽可能使用WiredTiger内部缓存以及其他线程空闲出来的内存。
5、若MongoDB实例内存使用率偏高，可以使用storage.wiredTiger.engineConfig.cacheSizeGB and --wiredTigerCacheSizeGB来控制。
六、磁盘使用
1、WiredTiger存储引擎可以重用已删除的文档（remove操作），这些空间出来的空间不会返回给操作系统。
2、可以通过db.collection.stats()来查看集合当前空间使用情况。
3、对于碎片化比较严重的集合，可以使用compact来进行处理。
