今天看了mongodb的官方文档中的WiredTiger Storage Engine ，说说我对WiredTiger Storage Engine 的理解！
在mongodb3.2版本以后,wiredTiger 存储引擎为默认的储存引擎。
Document Level Concurrency
WiredTiger 的写操作使用了Document 级别的并发控制，因此多个clients可以同时同一个collection 中的不同的document 进行修改。
为了尽可能多的读和写操作，WiredTiger 使用了optimistic concurrency control（乐观的并发控制），相当于乐观锁，WiredTiger的全局的专一的锁，仅仅存在于database 和 collections 级别，例如：drop 一个collections，需要一个database级别的锁。当存储引擎在database 和collection的锁之间发生冲突时，其中的一个将会引发数据库写的冲突导致mongdb 去重新进行此操作。
Snapshots and Checkpoints
WiredTiger 使用 多版本并发控制（MVCC）。再开始的操作中，WiredTiger 为这个事务提供一个数据的时间点的快照（snapshot），一个快照呈现一组在内存中的数据的视图。
当写进磁盘时，WiredTiger 把所有的在snapshot中的数据通过相同的方法传递到磁盘中的数据文件。把在数据文件中的久经耐用的数据作为一个检查站（checkpoint），这个检查站确保数据文件和上一个检查站的数据是一致的，包括最后一个检查站。eg:检查站可以作为数据的恢复的点。mongodb配置的WiredTiger 去创建的站点是在间隔60秒或者2 GB的日志数据。
在写一个新的站点期间，如果前面一个站点仍然是有效的，就这点而论，如果mongodb 意外结束或者突然遇到一个错误，再重新开始之前，mongodb 可以从上一个有效的checkpoint恢复数据。
当WiredTiger 元数据的表被原子性的更新到新的检查站点的说明文档时，这个新的站点变得可用和稳定，一但新的站点变的可用，WiredTiger会释放pages从旧的检查站点。
Journal
WiredTiger 使用一个write-ahead 处理log, 并且结合检查站点去确保数据的耐久性。
WiredTiger 日志呈现了所有的数据在检查站点之间的变化，如果mongodb在检查站点之间退出，它使用日志去重新从上一个检查站点更新所有的被修改的数据，信息更新的频率和mongodb把日志数据写到磁盘的频率相同。WiredTiger 的日志是使用了快速压缩库被压缩，如果自己想指定一个混合的压缩运算或者不压缩使用 storage.wiredTiger.engineConfig.journalCompressor
WiredTiger的最小的log 记录大小是128 bytes。如果一个log 记录小于等于128 bytes， WiredTiger 不会压缩这个log 记录。
Compression
在mongodb中，使用WiredTiger ，mongodb 支持压缩为所有的collection 和index ,压缩是使用额外CPU的开支减少存储空间。默认的情况下，WiredTiger使用块级别的压缩，所有的collections 被使用快速压缩库，所有的索引（index）被使用前缀压缩。在压缩collections 的时候 ，块级别的压缩用 zlib 也是可用的，去指定一个轮流的压缩运算或者不压缩，使用storage.wiredTiger.collectionConfig.blockCompressor ，假如你不想去压缩index,你可以看下storage.wiredTiger.indexConfig.prefixCompression
对于大多数工作的负载，默认的压缩设置平衡了存储效率和处理要求。
Memory Use
mongodb 使用WiredTiger，mongodb 利用WiredTiger内部的cache和文件系统的cache。
在mongdb 3.4 的版本以后，WiredTiger 内部的cache将变得更大：50%内存减去1GB 或者是256MG,通过文件系统的cache ,mongodb 自动的使用所有的空闲的内存，这些内存是不被WiredTiger cache 或者其他进程使用的。数据是在文件系统的cache里被压缩的。去调整WiredTiger内部cache 的大小可以看storage.wiredTiger.engineConfig.cacheSizeGB。
切记 ，不要调整WiredTiger内部cache的大小超过默认值。