先啰嗦啰嗦，真的没想到，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是激动人心的一次变革，也更让我很期待去深入学习并且运用于今后的工作当中。

mongoDB 3.0于 2015年3月3日发布 我 当时在北京。希望在mongoDB 4.0发布的时候我可以说，我在嗯。。。哪里呢？一个让梦想能够实现得更加美丽的地方。呵呵。

文章中部分是直接翻译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呢？网址：http://www.wiredtiger.com/

网页上面的一句话是：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 Sets

12 → 50

虽然谈不上是数量级上的变化，但是这个变化足以吓死一头牛。

之前谈过，Replica Set的最大节点支持数是12个，而3.0后是50个。。。

当然，投票节点之类的是否还是7个暂时不知道，后面看文档后再做说明。

支持Replica Sets的Drivers更多

各种Drivers的发布和正在开发中。

replSetStepDown 的改进

个人认为这个改进很有用。

replSetStepDown 的加快

加快，指的是可以对一些阻止replSetStepDown的操作进行直接杀掉。比如索引做成，写入操作或者一个长的mapreduce操作。

replSetStepDown 的减慢

之前，我曾经写过mongoDB的很麻烦的Rollback，自己还画了一副图来解释，本来觉得这个东东只能这样了，没想到而3.0的mongoDB终于改进了。

在老版本中，如果执行了replSetStepDown后，Primary会默认等待可成为候选者的Secondary 10秒的时间，这个设定毕竟是一个不太负责的设定，所以导致了Rollback，而mongoDB的Rollback的复原工作又只能人为操作，所以算一个小小的鸡肋。所以，3.0开始Primary会等待Secondary追到和自己一样的状态后再自杀。

replSetStepDown 的中和

上面既加速，又减速，其实都是一个极端操作，那么最后一招：中庸。

也算是一个模糊责任的办法。毕竟如果减慢Primary的自杀如果导致了长时间的假死也可能会被口水，所以，最新的replSetStepDown命令中可以设置等待Secondary追Primary的时间，算是一个timeout参数吧。另外，如果不考虑Secondary的同步，直接杀掉Primary的话，还可以使用force：true参数来直接枪毙，多种组合任君选用。

Sharded Cluster

Sharding也有所变化，但是我还没有详细的看完，后面细化的时候再写。

其他改进

安全性，Query的增强，log的的分类细化。。。比较多。慢慢来，来日方长。

就酱先。

つづく???