MongoDB3.0发布--新特性

插件式存储引擎API

MongoDB向MySQL看齐，开发了插件式存储引擎API，为第三方的存储引擎厂商加入Mongodb提供了方便。已经支持和即将支持的一些存储引擎：
- MMAP v1 默认存储引擎
- WiredTiger
- RocksDB
- TokuFT
- FusionIO（裸设备）

WiredTiger存储引擎

毫无疑问，WiredTiger存储引擎的引进是此版本最大的亮点。MongoDB公司已然感受到Tokumx深深的恶意和广大使用者对mongodb耗费巨大内存和磁盘的深恶痛绝，所以MongoDB拿（为）出（了）了（不）最（跳）大（票）的（更）诚（久）意，直接收购了WiredTiger，做了一个土豪应该做的事情。下面看一下这个存储引擎都给MongoDB的使用者带来了哪些福音。

1. 文档锁
WiredTiger通过多版本控制（MVCC）实现了文档锁，再也不用忍受库锁带来的并发性问题。这将大大提高诸如比价，打车等全update类型应用的可用性。这是一个现代数据库应该做的，不用说谢谢。

2. 压缩
当，监控报表上几十台机器磁盘报警的时候，当，删了表不释放空间的时候，当，挨个机器重新同步释放碎片的时候，允许我哭一会。现在好了，wiredTiger压缩一切，压缩journal，压缩表，压缩索引，且都是单独文件存储，想删就删，删了就释放，浑身上下哪哪都不疼了。
WiredTiger支持snappy（默认）、zlib压缩算法和None高端不压缩算法。snappy根据测试可以减少80%的磁盘使用。虽然可能会提高一些cpu，但是相比压缩带来的好处，天空飘来五个字儿….

3. 内存可配置
通过wiredTiger.engineConfig.cacheSizeGB参数可以配置运行时MongoDB内存使用大小，默认为物理内存的一半。老板再也不说MongoDB是内存小恶魔了。
wiredtiger还有其他一些参数配置，具体详见：http://docs.mongodb.org/v3.0/reference/program/mongod/#cli-wiredtiger-options

MMAP v1存储引擎

MongoDB给之前内存映射的存储也起了个名字，那就是“内存映射第一版”，MMAPv1依旧是MongoDB的默认存储引擎。此版本最大的改进就是锁力度变成集合锁，也就是表锁。但最大的问题是表空间还是按照库名来的，所以删除表依旧不会释放空间。为了解决空间重用问题和碎片问题，mongodb这次彻底的将Power of 2 Sized Allocations扶正，也就是之前说的usePowerOf2Size，将padding factor废弃。对于增删改频繁的业务，使用Power of 2 Sized Allocations，以提升效率。对于纯写入的应用，使用no padding，以节省空间。
【另外扒的】【在MMAP存储引擎中，文档按照写入顺序排列存储。如果文档更新后长度变长且原有存储位置后面没有足够的空间放下增长部分的数据，那么文档就要移动到文件中的其他位置。这种因更新导致的文档位置移动会严重降低写性能，因为一旦文档发生移动，集合中的所有索引都要同步修改文档新的存储位置。
MMAP存储引擎为了减少这种情况的发生提供了两种文档空间分配方式：基于paddingFactor（填充因子）的自适应分配方式和基于usePowerOf2Sizes的预分配方式，其中前者为默认方式。第一种方式会基于每个集合中文档更新历史计算文档更新的平均增长长度，然后在新文档插入或旧文档移动时填充一部分空间，如当前集合paddingFactor的值为1.5，那么一个大小为200字节的文档插入时就会自动在文档后填充100个字节的空间。第二种方式则不考虑更新历史，直接为文档分配2的N次方大小的存储空间，如一个大小同样为200字节的文档插入时直接分配256个字节的空间。
MongoDB 3.0版本中的MMAPv1抛弃了基于paddingFactor的自适应分配方式，因为这种方式看起来很智能，但是因为一个集合中的文档的大小不一，所以经过填充后的空间大小也不一样。如果集合上的更新操作很多，那么因为记录移动后导致的空闲空间会因为大小不一而难以重用。目前基于usePowerOf2Sizes的预分配方式成为默认的文档空间分配方式，这种分配方式因为分配和回收的空间大小都是2的N次方（当大小超过2MB时则变为2MB的倍数增长），因此更容易维护和利用。如果某个集合上只有insert或者in-place update，那么用户可以通过为该集合设置noPadding标志位，关闭空间预分配。】

查询和索引

• 修改explain函数，现在explain可以支持count，find，group，aggregate，update，remove等操作。显示结果更全面更精细化。
• 后台索引建立过程中，不能进行删库删表删索引操作。
• 使用 createIndexes命令可以同时建立多个索引，并且只扫描一遍数据，提升了建索引的效率。
• 废弃dropDups参数，以后不能通过这个删除重复数据了。