先啰嗦啰嗦，真的没想到，mongoDB能这么快推出3.x，我的2.6的读书笔记还没有写完呢，3.0就杀到了，咋办。。。头疼中。。。
看了一下3.0的介绍，我觉得还是直接上3.x的读书笔记吧，2.x的东东和3.x的比较着来，这样老的延续的东西也能温习，新的东西也可以马上知道，而且3.x的x到底到几的时候才能变成相对bug fixed版本还不知道，所以一边看着一边看bug fix过程吧。3.0的变化是从底层的数据存储上面发生的变更，存储方式的api可以使得今后增加更多的底层解决方案，根据不同的需求来定制不同的解决方案。mongoDB3.x是激动人心的一次变革，也更让我很期待去深入学习并且运用于今后的工作当中。
文章中部分是直接翻译document，部分是我的一些结合以前的功能的描述。
mongoDB 3.0的主要变化(主要变化的摘录)可插拔的数据存储引擎
mongoDB从3.0开始(其实2.8已经开始beta)终于提供了底层的API，使得存储这个底层过程可以和mongoDB的运用层分隔开来，第三方的存储解决方案今后将会层出不穷。
Wired Tiger
Wired Tiger，说实话，我。。我漏寡闻。。之前只知道它是BerkeleyDB的架构师的一个作品，但不知道这家已经貌似被mongoDB收购了，等于现在mongoDB既有自己的memory映射的存储方式又有一个很NB的Wired Tiger了，看来前景不错。 OK，啥是Wired Tiger呢？网址： 网页上面的一句话是：making big data roar 。roar 这个词。。。我真的是词典了一下，没见过。这个词的中文意思是“咆哮”，Wired Tiger主页的各种数据已经体现了它的算法优势和能力，具体优秀的地方我在后面的学习和理解中继续挖掘然后share出来。mongoDB于2014年12月16日宣布收购Wired Tiger，这是个很成功的战略收购，链接戳戳我。 mongoDB 3.0支持两种底层存储模式：
MMAPv1
这个是mongoDB的亲儿子，自己一直在做的内存映射存储模式，这个模式我在以前的文章中大概写过，是private view 和 Journal 以及 shared view 共同作用来实现数据写入的，其实也就是很努力地使用了内存缓存还有日志。那，这个亲生的之前一直被猜测会被养子所代替，而3.0中把这个存储还是作为了默认模式。看来mongoDB还是想继续优化和持有一段时间(关于优化下面会继续说)。
WiredTiger
作为3.0版本的明星闪亮登场，不过现在只支持64位的操作系统。
特性
WiredTiger可以支持mongoDB所有的特性，包括对于server，数据库的各种操作以及数据分析，我认为对于客户而言除了直接的使用结果，这个变化比较透明。如果现有数据要切换到WiredTiger需要使用mongoDB的命令进行切换，并且有一个比较复杂的update过程，这个我还没有研究，后面有时间细化。 另外一个比较帅气的就是，我们知道的Replica以及Shard是可以支持MMAPv1与WiredTiger的混搭模式，也就是可以根据我们的需求很存储目的来调整集群的模式，加上mongoDB的一些参数命令使得“物尽其用”可以发挥得更好，后面也希望有机会我自己能实践实践。 最后，虽然我还没有仔细研究这个WiredTiger，我觉得可以看到他的主页的图片总结一下它的特点。 1. 良好的线性可扩展性，随着操作线程的增加，(查询)操作的数量是线性递增的。 2. 良好的数据写入吞吐率，随着写入行数的增加，每秒的inserts几乎不变化(我靠，怎么做到的。。。) 3. update操作的低迟延性，随着request的增加，迟延变化率很低(我靠，这又是怎么做到的。。。)
如果高效的存储构件再加上mongoDB的易操作性出来的产品一定很帅。怪不得WiredTiger的口号是make big data roar。
另用户泪奔的又一个特性
document级别的锁。之前的mongoDB的一大诟病就是collection级别的锁，这次WiredTiger直接扑灭这团火，document级锁直接解决大问题。并且采用snappy的压缩方式(sorry 这个我也是不太清楚，有空学学)。
MMAPv1的改善并发的改善
养子那么强悍，亲儿子也不示弱，mongoDB表示对原来的collection级别的locking进行了改善。 (–;) 。。。 改善而已，效果还未知，但是从collection级别这几个字看来可能还是让大规模的读写操作产生畏惧心理。
空间分配机制的变化
以前的mongoDB还有一个诟病，就是空间分配机制。 有一个名词，叫做填充因子(padding Factor)。听着貌似挺神奇的一个东东，其实没啥，说白了就是给一条document占地用的参数，因为Nosql的mongoDB特点就是同一个collection的document可能内部的形态和构造会有不同(如果是in-place-update的话，这种情况会很少，因为in-place-update一般不会影响document的长度变化)，大规模更新和删除操作的时候如果造成document长度的变化会出现文档移动的现象，这种移动有时候会对操作产生很大的影响，再加上collection级的锁，所以一旦数据量大并发又多，产生更多的移动那么影响也是很大的，在mongoDB权威指南第二版中明确写到”现在的mongoDB还没有太好的解决方案“。 3.0中，首先是改善collection的锁，第二个就是废除了填充因子。不使用填充因子，默认只使用mongoDB之前还不太成熟的power of 2 allocation的分配方式，并且宣称对这种方式进行了很好的优化，对于大数量级数据的处理可以“handle”。这种方式其实也是一种算法级的方式，简单来说就是把空间分配做成2的倍数，在开辟、移动的时候可以减少碎片并且在位置计算的时候算法也会统一、简单。在2.x之前的mongoDB中对于collection中的usePowerOf2Sizes 参数已经废弃，之前版本：
mongod –setParameter newCollectionsUsePowerOf2Sizes=false / true
有这么一个parameter的设定，这个设定对于collection可以运用”power of 2 allocation”的分配策略，而3.0开始已经不去识别这个设置，默认的mongoDB都是“power of 2 allocation”策略。 但是呢，如果我们的操作不是一个经常update和delete的操作，可能只有普通的插入或者是in-place-update的操作，那么其实不需要设置成”power of 2 allocation”的模式。所以mongoDB 3.0中提供关闭此策略的方式。当然，3.0也强调，你要确定你的操作是一个不会使得documents长度变化的操作，，三思而后行哦。
Replica Sets12 → 50
虽然谈不上是数量级上的变化，但是这个变化足以吓死一头牛。 之前谈过，Replica Set的最大节点支持数是12个，而3.0后是50个。。。 当然，投票节点还是只能7个，估计是怕节点多了影响投票时间。
支持Replica Sets的Drivers更多
各种Drivers的发布和正在开发中。
replSetStepDown 的改进
个人认为这个改进很有用。
replSetStepDown 的加快
加快，指的是可以对一些阻止replSetStepDown的操作进行直接杀掉。比如索引做成，写入操作或者一个长的mapreduce操作。
replSetStepDown 的减慢希望你灰暗的心情在此刻明亮起来，去迎接美好的明天!
