前两天MongoDB发布了1.8版本，看到的大多数描述都是说到增加了Journaling日志文档这个改进。

　　MongoDB1.8RC0版本有哪些特性

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

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

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

　　Journaling日志的GroupCommits机制

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

　　Journaling对fsync操作的影响

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

　　2.SparseIndex和CoveredIndex

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

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

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

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

　　MongoDB1.8RC0版本有哪些特性

　　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时才适用。