我发现了这个讨论:MongoDB: Terrible MapReduce Performance .基本上它说尽量避免 Mongo 的 MR 查询，因为它是单线程的，根本不应该是实时的。 2 年过去了，我想知道从那时起发生了什么变化。现在我们有了 MongoDb 2.2。我听说 MR 现在是多线程的。请分享您对 MR 用于实时请求的想法，例如为 Web 应用程序频繁的 http 请求获取数据。能否有效利用索引？
最佳答案
这是 MongoDB 中 Map/Reduce 功能的当前状态
1) Map/Reduce 的大部分性能限制仍然存在于 MongoDB 2.2 版中。 Map/Reduce 引擎仍然要求将每条记录从 BSON 转换为 JSON，使用嵌入式 JavaScript 引擎执行实际计算(速度很慢)，并且仍然存在单个全局 JavaScript 锁，它只允许单个 JavaScript 线程一次运行。
对分片集群的 Map/Reduce 进行了一些增量改进。最值得注意的是，最终的 Reduce 操作现在分布在多个分片上，并且输出也被并行分片。
我不建议在 MongoDB 2.2 版中使用 Map/Reduce 进行实时聚合
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
Map/Reduce 在 2.4 和 2.6 之间没有显着变化。
我仍然不建议在 MongoDB 2.4 或 2.6 版本中使用 Map/Reduce 进行实时聚合。
4) 如果你真的需要 Map/Reduce，你也可以看看 Hadoop Adaptor。这里有更多信息:
https://stackoverflow.com/questions/12678631/