关于存储引擎 WiredTiger storage engine
WiredTiger 在3.2版本成为mongodb的默认存储引擎。所以这里讲的就是WiredTiger了。
Document Level Concurrency
WiredTiger提供了document-level concurrency control 的写操作，这么说，多个client可以在同一时间内修改同一collection的不同文档。对于大多数读写操作，WiredTiger都会使用最佳的并发控制，在global、database、collection等级别上只使用了意向锁（intent lock）。如果存储引擎检测到两个操作冲突了，则导致mongodb将其中一个操作重新执行。
Snapshots and Checkpoints
MongoDB配置WiredTiger在每60秒或者2GB日志数据就创建一个checkpoint（快照）。在写入一个checkpoint时，前一个checkpoint仍然是有效的，所以在此时MongoDB如果崩溃了，还是可以回退到最新的有效checkpoint，并依靠日志来恢复最近的改变。在新的checkpoint成功变成有效的，之前的旧checkpoint pages就会被释放。
Journal
MongoDB在没有新的checkpoint生成之前，会持续地打日志，使用的是snappy compression library来压缩日志，但是也可以指定其他的压缩算法，这可通过storage.wiredTiger.engineConfig.journalConpressor来设置。甚至设置storage.journal.enabled=false来关闭日志系统，这样可以减少花费，但是所做的修改也就很危险。
MongoDB配置了WiredTiger在内存指定缓冲区中进行记录，等到达 128 kb 时再写到磁盘中去。将内存中的记录写入磁盘有下面一些条件：
- 每经过100ms。
- 新的checkpoint出现，或者日志数据到达2GB。
- 如果设置了write concern 的
j:true选项，存储引擎立刻写入log file。
最小的log记录是128字节，如果等于小于128字节则不使用压缩。log file的大小规定为100M，所以存储引擎大约每100M的日志数据就创建一个log file，一般会预先创建一些log file（通常是在首次启动mongod实例之前，此功能可以关闭）。除非写操作特别多，否则一般情况下只会有两三日志文件。正常关闭mongod时会清空所有的日志文件，而非正常关闭则会留下一些文件。
如果在日志信息仍在内存缓冲区的时候mongd突然崩溃（如断电），这些日志数据就会丢失。最有可能丢失的就是崩溃前的100ms再加上写进日志文件的这一时间段。serverStatus
命令中有log的统计信息。
如果频繁写日志文件会导致效率的下降，这时可以将journal目录转移到其他文件系统中，就不会影响到数据库正常的读写操作效率。但这会带来的一个问题是，对数据库使用snapshot时不能够对这两个部分单独进行操作，而是需要使用fsyncLock()将数据库锁起来，等snapshot操作都完成之后再使用fsyncUnlock()解锁。
Compression
MongoDB提供collection压缩和index压缩。默认是使用block compression来压缩collection，和使用prefix compression来压缩index。
对于collection，可以更改指定压缩算法或者禁用压缩，使用storage.wiredTiger.collectionConfig.blockCompressor设置即可。
对于index，可以使用storage.wiredTiger.indexConfig.prefixCompression来关闭prefix压缩。
甚至，针对每个collection和index的压缩，可以使用具体的压缩算法，参考create-collection-storage-engine-options和db.collection.createIndex()。不过，默认的压缩算法在大多数平均情况下都有出色的表现，很好平衡了效率和执行需求。
Cache
MongoDB使用了双Cache，一个是WiredTiger Cache，一个是文件系统Cache。默认情况下，从3.2起WiredTiger将使用60%的RAM减去1GB或者使用1GB，取其中的大者。在3.0中要么使用1GB，要么50%的物理内存，取其中的大者。可以参考storage.wiredTiger.engineConfig.cacheSizeGB
和 --wiredTigerCacheSizeGB进行配置Cache大小，但是要避免超过默认的大小，值得注意的是，storage.wiredTiger.engineConfig.cacheSizeGB仅仅限制了WiredTiger Cache的大小，这只是mongod的一部分，而不是mongod所使用内存的上限。MongoDB假设了这只有一个instance在一个node上而已，如果有多个的话，更加需要调整一下Cache大小。
本引擎会自主决定哪些数据保存在内存中，哪些数据会刷新到磁盘中。而且，两种引擎不能混淆使用，即用Wired Tiger创建的数据库不能用MMAPv1去打开，这是两种不同的文件存储方式以及管理方式的。
关于MMAPv1 storage engine
每个文档中的所有field都位于同一块连续的内存中，而storage engine在为文档申请内存块的时候都是会留出一部分内存供后来填充用的，即为每个文档申请的实际内存大小都会大于其真实大小（一般是以2的指数增长）。当填充的多余部分内存用光了之后，就会引起重新为该文档申请新内存的操作。
Document Level Lock
本引擎也提供了锁的机制，对于document级别的写操作保证了不会冲突，而是进行有序的执行。
MongoDB 系统的限制与门槛
- BSON文档
最大BSON文档的大小是16MB，如果超过这个限制，可以尝试使用GridFS API来存储大文件。 - 嵌套深度
MongoDB目前支持的内嵌文档的嵌套深度是不超过100层。 - Namespace 长度
支持的最大的集合namespace为120 Bytes，其中包括了数据库名称，还有dot等等，即. - Namespace 的数量
在3.0之前使用的默认存储引擎就会有一些限制，比如Namespace的数量受限制于namespace文件的大小，现在的默认存储引擎WiredTiget就没有这些限制了。 - Namespace 文件的大小
之前MMAPv1默认的namespace文件的大小限制为16MB，但是可以通过nsSize来配置它，只要不超过2047字节。但WiredTiger现在没有这个限制。 - 固定集合Capped Collection。如果是通过max参数来创建的固定集合，那么集合大小不能超过232。而在创建固定集合的时候没有指定集合大小，那么集合中可以包含任意多个文档。
- MMAPv1存储引擎限制了每个数据库不能够超过16000个数据文件，即不超过32TB，可通过
storage.mmapv1.smallFiles来设置为8TB。 - MMAPv1不能够处理数据大小超过操作系统的虚存空间大小。而WiredTiger没有此限制。
- MMAPv1限制了数据库中的文档数量，与索引数量和namespace文件大小相关。WiredTiger没有此限制。
- 针对具体情况，可以使用no padding模式的申请内存方式，这样每次申请的内存大小就刚刚好了。
GridFS 大文档存储
如果存储的文档超过了16MB，那么就需要选择这种方式来存储了。将大文档分割成小部分或chunk，然后分别作为小文档存储起来，分别存储于两个集合collection中，其中一个集合存储的是文件chunk，另一个存储的是元数据（这里有详细介绍 GridFS Collections）。默认的chunk大小为255kB，即除了最后一块，其他都是255kB（自从v 2.4.10改为255kB的）。
在需要查询大文件的时候，引擎会重组所有的chunk。可以针对文件中的某个范围进行查询，比如跳过视频的片头。这种存储方式也支持16MB以下的文档存储的，当经常需要查询文件中的某个范围的时候就能派上用场了。
一般情况下，GridFS使用两个分别名为fs.files和fs.chunks的文件来保存所有的大文件信息。一对文件称之为“桶”，可以创建多对，也可以选择其他名称。chunks中的每个文档都是一个chunk，就像下面这样：
{
"_id" : ,
"files_id" : ,
"n" : , //sequence of this chunk
"data" :
}
files中的每个文档代表着GridFS中的一个大文件。除了部分是可选的，文档格式大致如下：
{
"_id" : ,
"length" : ,
"chunkSize" : ,
"uploadDate" : ,
"md5" : ,
"filename" : ,
"contentType" : ,
"aliases" : ,
"metadata" :
}
那效率如何呢？GridFS对每个chunks和files集合使用了index，驱动一般会自动创建这些索引，提升速度就只能依靠这些索引了，也可以自定义一些新索引。