mongodb mapreduce 性能 Mongodb的MapReduce很慢，有没有办法提高性能

Mongodb的MapReduce很慢，有没有办法提高性能

发现了一个简单办法可以大幅提高mongodb mapreduce的速度，以前我在一台机器上只部署了一个mongod的数据库实例，起始如果机器配置可以的话，可以在一台机器上多配几个Mongod数据库实例，把他们用分片的形式加到集群中就可以了。
这样就相当于多进程操作了，避免了js单进程的尴尬。
如果机器的cpu是12核的可以起6-8个mongod，根据测试发现再多个mongod对于速度的影响不升反降。据我分析之前是因为单进程操作，是因为单个cpu达到瓶颈。
改成多进程后，达到磁盘i/o瓶颈后速度就没法提升了。

如何将 MongoDB MapReduce 速度提升 20 倍

使用排序
　　我在之前的这篇文章中简要说明了使用排序对于MR的好处，这是一个鲜为人知的特性。在这种情况下，如果处理未排序的输入，意味着MR引擎将得到随机排序的值，

　　基本上没有机会在RAM中进行reduce，相反，它将不得不通过一个临时collection来将数据写回磁盘，然后按顺序读取并进行reduce。

　　使用多线程
　　MongoDB对单独的MR作业并不使用多线程——它仅仅对多作业使用多线程。但通过多核CPU，在单个服务器使用Hadoop风格来并行作业非常有优势。我们需要做的是把输入分成几块，通过各个块来加速一个MR作业。也许数据集有简单的方法来分割，但其他使用splitVector命令（不明确）可以使你很快的找到分割点
　　使用多数据库
　　问题是在多线程之间会有很多锁竞争。在上锁时，MR并不是那么无私的(它每1000次读操作就会产生一次锁定)，而且MR任务还会执行许多写操作，导致线程最终都会在等待另一个线程。由于每个MongoDB数据库都有私有锁，让我们尝试为每一个线程使用一个不同的输出数据库
　　使用纯JavaScript模式
　　当把输入数据拆分到不同线程上去的时候，发生了一些有趣的事情:每个线程现在有大约250000个不同的值来输出，而不是1百万。这意味着我们可以使用“纯JS模式”，它可以通过使用jsMode:true来开启。开启后，MongoDB在处理时将不会把对象在JS和BSON之间来回翻译，相反，它使用一个限额500000个key的内部JS字典来化简所有对象。

mongodb hbase redis 哪个更强大

hbase，mongodb，redis都属于nosql型存储方案。在实际的项目实践上看，他们的系统存储及处理的数量由大到小。
HBase基于列存储，提供三项坐标方式定位数据，由于其qualifier的动态可扩展型（无需schema设计，可存储任意多的qualifier），特别适合存储稀疏表结构的数据（比如互联网网页类）。HBase不支持二级索引，读取数据方面只支持通过key或者key范围读取，或者全表扫描。

MongoDb在类SQL语句操作方面目前比HBase具备更多一些优势，有二级索引，支持相比于HBase更复杂的集合查找等。BSON的数据结构使得处理文档型数据更为直接。MongoDb也支持mapreduce，但由于HBase跟Hadoop的结合更为紧密，Mongo在数据分片等mapreduce必须的属性上不如HBase这么直接，需要额外处理。
HBase与Mongodb的读写性能正好相反，HBase写优于随机读，MongoDB似乎写性能不如读性能。

Redis为内存型KV系统，处理的数据量要小于HBase与MongoDB