本篇文章给大家分享的是有关MongoDB 1.8 RC0版本的特性有哪些，小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着小编一起来看看吧。
前两天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时才适用。
以上就是MongoDB 1.8 RC0版本的特性有哪些，小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注创新互联行业资讯频道。
