MongoDB的原理

一、存储引擎（Storage）

    mongodb 3.0默认存储引擎为MMAPV1，还有一个新引擎wiredTiger可选，或许可以提高一定的性能。

    mongodb中有多个databases，每个database可以创建多个collections，collection是底层数据分区（partition）的单位，每个collection都有多个底层的数据文件组成。（参见下文data files存储原理）

 

    wiredTiger引擎：3.0新增引擎，官方宣称在read、insert和复杂的update下具有更高的性能。所以后续版本，我们建议使用wiredTiger。所有的write请求都基于“文档级别”的lock，因此多个客户端可以同时更新一个colleciton中的不同文档，这种更细颗粒度的lock，可以支撑更高的读写负载和并发量。因为对于production环境，更多的CPU可以有效提升wireTiger的性能，因为它是的IO是多线程的。wiredTiger不像MMAPV1引擎那样尽可能的耗尽内存，它可以通过在配置文件中指定“cacheSizeGB”参数设定引擎使用的内存量，此内存用于缓存工作集数据（索引、namespace，未提交的write，query缓冲等）。

    journal就是一个预写事务日志，来确保数据的持久性，wiredTiger每隔60秒（默认）或者待写入的数据达到2G时，mongodb将对journal文件提交一个checkpoint（检测点，将内存中的数据变更flush到磁盘中的数据文件中，并做一个标记点，表示此前的数据表示已经持久存储在了数据文件中，此后的数据变更存在于内存和journal日志）。对于write操作，首先被持久写入journal，然后在内存中保存变更数据，条件满足后提交一个新的检测点，即检测点之前的数据只是在journal中持久存储，但并没有在mongodb的数据文件中持久化，延迟持久化可以提升磁盘效率，如果在提交checkpoint之前，mongodb异常退出，此后再次启动可以根据journal日志恢复数据。journal日志默认每个100毫秒同步磁盘一次，每100M数据生成一个新的journal文件，journal默认使用了snappy压缩，检测点创建后，此前的journal日志即可清除。mongod可以禁用journal，这在一定程度上可以降低它带来的开支；对于单点mongod，关闭journal可能会在异常关闭时丢失checkpoint之间的数据（那些尚未提交到磁盘数据文件的数据）；对于replica set架构，持久性的保证稍高，但仍然不能保证绝对的安全（比如replica set中所有节点几乎同时退出时）。

    

 

    MMAPv1引擎：mongodb原生的存储引擎，比较简单，直接使用系统级的内存映射文件机制（memory mapped files），一直是mongodb的默认存储引擎，对于insert、read和in-place update（update不导致文档的size变大）性能较高；不过MMAPV1在lock的并发级别上，支持到collection级别，所以对于同一个collection同时只能有一个write操作执行，这一点相对于wiredTiger而言，在write并发性上就稍弱一些。对于production环境而言，较大的内存可以使此引擎更加高效，有效减少“page fault”频率，但是因为其并发级别的限制，多核CPU并不能使其受益。此引擎将不会使用到swap空间，但是对于wiredTiger而言需要一定的swap空间。（核心：对于大文件MAP操作，比较忌讳的就是在文件的中间修改数据，而且导致文件长度增长，这会涉及到索引引用的大面积调整）

 

    为了确保数据的安全性，mongodb将所有的变更操作写入journal并间歇性的持久到磁盘上，对于实际数据文件将延迟写入，和wiredTiger一样journal也是用于数据恢复。所有的记录在磁盘上连续存储，当一个document尺寸变大时，mongodb需要重新分配一个新的记录（旧的record标记删除，新的记record在文件尾部重新分配空间），这意味着mongodb同时还需要更新此文档的索引（指向新的record的offset），与in-place update相比，将消耗更多的时间和存储开支。由此可见，如果你的mongodb的使用场景中有大量的这种update，那么或许MMAPv1引擎并不太适合，同时也反映出如果document没有索引，是无法保证document在read中的顺序（即自然顺序）。3.0之后，mongodb默认采用“Power of 2 Sized Allocations”，所以每个document对应的record将有实际数据和一些padding组成，这padding可以允许document的尺寸在update时适度的增长，以最小化重新分配record的可能性。此外重新分配空间，也会导致磁盘碎片（旧的record空间）。

 

    Power of 2 Sized Allocations：默认情况下，MMAPv1中空间分配使用此策略，每个document的size是2的次幂，比如32、64、128、256...2MB，如果文档尺寸大于2MB，则空间为2MB的倍数（2M,4M,6M等）。这种策略有2种优势，首先那些删除或者update变大而产生的磁盘碎片空间（尺寸变大，意味着开辟新空间存储此document，旧的空间被mark为deleted）可以被其他insert重用，再者padding可以允许文档尺寸有限度的增长，而无需每次update变大都重新分配空间。此外，mongodb还提供了一个可选的“No padding Allocation”策略（即按照实际数据尺寸分配空间），如果你确信数据绝大多数情况下都是insert、in-place update，极少的delete，此策略将可以有效的节约磁盘空间，看起来数据更加紧凑，磁盘利用率也更高。

 

    备注：mongodb 3.2+之后，默认的存储引擎为“wiredTiger”，大量优化了存储性能，建议升级到3.2+版本。

 

二、Capped Collections：一种特殊的collection，其尺寸大小是固定值，类似于一个可循环使用的buffer，如果空间被填满之后，新的插入将会覆盖最旧的文档，我们通常不会对Capped进行删除或者update操作，所以这种类型的collection能够支撑较高的write和read，通常情况下我们不需要对这种collection构建索引，因为insert是append（insert的数据保存是严格有序的）、read是iterator方式，几乎没有随机读；在replica set模式下，其oplog就是使用这种colleciton实现的。    Capped Collection的设计目的就是用来保存“最近的”一定尺寸的document。 

Java代码  

1. db.createCollection("capped_collections",new CreateCollectionOptions()  
2.                 .capped(true)  
3.                 .maxDocuments(6552350)  
4.                 .usePowerOf2Sizes(false).autoIndex(true));//不会涉及到更新，所以可以不用power of 2  

 

    Capped Collection在语义上，类似于“FIFO”队列，而且是有界队列。适用于数据缓存，消息类型的存储。Capped支持update，但是我们通常不建议，如果更新导致document的尺寸变大，操作将会失败，只能使用in-place update，而且还需要建立合适的索引。在capped中使用remove操作是允许的。autoIndex属性表示默认对_id字段建立索引，我们推荐这么做。在上文中我们提到了Tailable Cursor，就是为Capped而设计的，效果类似于“tail -f ”。

 

三、数据模型（Data Model）

    上文已经描述过，mongodb是一个模式自由的NOSQL，不像其他RDBMS一样需要预先定义Schema而且所有的数据都“整齐划一”，mongodb的document是BSON格式，松散的，原则上说任何一个Colleciton都可以保存任意结构的document，甚至它们的格式千差万别，不过从应用角度考虑，包括业务数据分类和查询优化机制等，我们仍然建议每个colleciton中的document数据结构应该比较接近。

    对于有些update，比如对array新增元素等，会导致document尺寸的增加，无论任何存储系统包括MYSQL、Hbase等，对于这种情况都需要额外的考虑，这归结于磁盘空间的分配是连续的（连续意味着读取性能将更高，存储文件空间通常是预分配固定尺寸，我们需要尽可能的利用磁盘IO的这种优势）。对于MMAPV1引擎，如果文档尺寸超过了原分配的空间（上文提到Power of 2 Allocate），mongodb将会重新分配新的空间来保存整个文档（旧文档空间回收，可以被后续的insert重用）。

 

    document模型的设计与存储，需要兼顾应用的实际需要，否则可能会影响性能。mongodb支持内嵌document，即document中一个字段的值也是一个document，可以形成类似于RDBMS中的“one-to-one”、“one-to-many”，只需要对reference作为一个内嵌文档保存即可。这种情况就需要考虑mongodb存储引擎的机制了，如果你的内嵌文档（即reference文档）尺寸是动态的，比如一个user可以有多个card，因为card数量无法预估，这就会导致document的尺寸可能不断增加以至于超过“Power of 2 Allocate”，从而触发空间重新分配，带来性能开销，