我发现了这个讨论：MongoDB: Terrible MapReduce Performance。基本上它说试图避免Mongo的MR查询，因为它是单线程的，根本不应该是实时的。 2年过去了，我想知道自那时以来发生了什么变化。现在我们有了MongoDb 2.2。我听说MR现在是多线程的。请分享您对MR使用的想法，以获取实时请求，例如为Web应用程序频繁的http请求获取数据。它是否能够有效地使用索引？
答案 0 :(得分：56)
以下是MongoDB中Map / Reduce的当前功能状态
1）Map / Reduce的大多数性能限制仍然存在于MongoDB 2.2版中。 Map / Reduce引擎仍然需要将每个记录从BSON转换为JSON，实际计算使用嵌入式JavaScript引擎（速度很慢）执行，并且仍然只有一个全局JavaScript锁，只允许一个JavaScript线程一次运行。
对于分片群集，Map / Reduce有一些渐进的改进。最值得注意的是，最终的Reduce操作现在分布在多个分片中，并且输出也是并行分片。
我不建议使用Map / Reduce进行MongoDB 2.2版中的实时聚合
2）从MongoDB 2.2开始，现在有了一个新的聚合框架。这是一个新的聚合操作实现，用C ++编写，并紧密集成到MongoDB框架中。
可以重写大多数Map / Reduce作业以使用聚合框架。它们通常运行得更快（比版本2.2中的Map / Reduce提高20倍速度），它们充分利用现有的查询引擎，并且可以并行运行多个聚合命令。
如果您有实时聚合要求，首先要使用聚合框架。有关聚合框架的更多信息，请查看以下链接：
3）MongoDB版本2.4中的Map / Reduce有了显着改进。 SpiderMonkey JavaScript引擎已被V8 JavaScript引擎取代，并且不再存在全局JavaScript锁定，这意味着可以同时运行多个Map / Reduce线程。
Map / Reduce引擎仍然比聚合框架慢得多，主要有两个原因：
解释JavaScript引擎，而聚合框架 运行已编译的C ++代码
JavaScript引擎仍然要求每个被检查的文档都从BSON转换为JSON;如果要将输出保存在集合中，则必须将结果集从JSON转换回BSON
在2.4和2.6之间，Map / Reduce没有显着变化。
我仍然不建议在MongoDB版本2.4或2.6中使用Map / Reduce进行实时聚合。
4）如果你真的需要Map / Reduce，你也可以看一下Hadoop Adapter。这里有更多信息：