前两天MongoDB发布了1.8版本，看到的大多数描述都是说到增加了Journaling日志文档这个改进，今天抽空看了一下Release Note，发现还有几个比较有用的特性，分享在这里：

　　1.Journaling 日志文档增加单机可靠性

　　好吧，Journaling 其实就是日志的意思，这里暂且当一个名词用吧。它的使用方法是在启动时加上 –dur 选项。Journaling 的出现应该归因于前段时间发生的某用户在单机使用MongoDB 然后进行了 kill -9 操作导致数据不可用后提出的。关于这个事件的描述可以看这里。

　　Journaling 不仅能增强系统的可靠性，对于非正常关闭的 MongoDB 的重启方式也有改变，从原来的需要进行漫长的 repair 操作，改成了进行在现在数据文件上重新执行 Journaling 日志记录的操作。速度可以得到很大的提升。当然，如果是一次正常关闭，那么所有的 Journaling 日志就没用了，会被直接清除掉。

　　Journaling 日志的 Group Commits 机制

　　Journaling 日志支持 Group Commits 功能，就是将一段时间的日志文件合起来进行一次磁盘写操作。在1.8 版本里，它的提交时间间隔大概是100ms。

　　Journaling 对fsync 操作的影响

　　如果使用了 –dur 参数启动 MongoDB，那么在执行 fsync 命令时，将不会是对所有数据文件进行 fsync 操作后返回，而是在 Journaling 日志写到磁盘上就返回。

　　2.Sparse Index 和 Covered Index

　　Sparse Index 只能对一个列进行索引，这一限制带来的好处是，它不会对该项值为空的行作索引。这样就大大减小了某些列的索引大小。比如你在文章列表中建立了一个是否删除的标识，删除掉的文章这个值为1，其它文章没有这个值，那么在对这个值建立的索引就会非常小。

　　Sparse Index 的使用示例如下，只需要在第二个参数加上 sparse为true的标识即可：

　　db.people.ensureIndex({title : 1}, {sparse : true})

　　Covered Index 是在联合索引小，如果你查找的值正好是在索引中，则可以直接返回索引中存的值，而不用到数据文件中查找。(这个在传统关系型数据库中也有实现)

　　3. Map/Reduce 输出模式可配置

　　在1.8版本中，MongoDB 的 Map/Reduce 不再将结果输出到某个 collection 中，而是让用户在跳 Map/Reduce 任务时指定用何种方式输出，下面是四种方式，使用方法是在Map/Reduce 命令加上 out参数，例：

　　db.users.mapReduce(map, reduce, {out: { inline : 1}});

　　下面是四种方式：

　　“collectionName” – 如果设置 out 为一个collection 名，那么输出结果将会存在这个collection中，这个collection如果本来就存在，那么数据将会被抹掉。

　　{ merge : “collectionName” } -这个选项和上面的略有不同，不同在于数据不会被全部分抹掉，只是覆盖掉与 Map/Reduce 结果有索引冲突的项。

　　{ reduce : “collectionName” } – 此选项比上一个选项又复杂一点，此选项在上面的情况下不会覆盖掉原来的数据，而是选择调用 reduce 方法和finalize方法(如果指定了的话)来合并重复的项。

　　{ inline : 1} – 当指定这个选项时，结果不会存在某一个collection 里，而是直接输出一个数据对象，需要注意的是，只有当结果数据小于8M时才适用。

　　Release Note地址：http://goo.gl/4J732