我几年前就看到过这个问题。从那时起，MongoDB 2.4提供了多线程Map Reduce（在切换到V8 Javascript引擎之后），并且变得比以前的版本更快，因此速度慢的说法不是问题。
然而，我正在寻找一种情况，在这种情况下，Map Reduce方法可能比Aggregation Framework更有效。事实上，聚合框架可能根本无法工作，但Map Reduce可以获得所需的结果。
谢谢，John
看看这个。
聚合FW结果存储在单个文档中，因此限制为16 MB：这可能不适合某些情况。使用MapReduce，有几种输出类型可用，包括一个新的完整集合，因此它没有空间限制。
通常，当您必须处理大型数据集（可能是整个集合）时，MapReduce会更好。此外，它提供了更多的灵活性（您可以编写自己的聚合逻辑），而不是局限于某些管道命令。
当前聚合框架的结果不能超过16MB。但是，我认为更重要的是，您会发现AF更适合"此时此地"类型的查询，这些查询本质上是动态的（例如，用户在运行时提供过滤器）。
MapReduce是预先计划好的，可能会复杂得多，并产生非常大的输出（因为它们只是output到一个新集合）。它没有您可以控制的运行时输入。您可以添加复杂的对象操作，这在AF中是不可能（或不高效）的。例如，在MapReduce中操作子数组（或类似数组的东西）很简单，因为您只是在编写JavaScript，而在AF中，事情可能会变得非常难处理和难以管理。
最大的问题是MapReduce不会自动更新，而且很难预测何时完成）。您需要实现自己的解决方案来保持它们的最新性（与其他一些NoSQL选项不同）。通常，这只是某种类型的时间戳和增量MapReduce更新，如图所示）。您可能需要接受这样一个事实，即数据可能有些陈旧，并且需要未知的时间才能完成。
如果你在StackOverflow上寻找，你会发现很多非常有创意的解决方案来解决MongoDB的问题，许多解决方案都使用聚合框架，因为它们绕过了MongoDB中通用查询引擎的限制，可以产生"实时/即时"的结果。（尽管有些AF管道非常复杂，但根据开发人员/团队/产品的不同，这可能是一个问题）。