mongodb - MongoDB 使用 Map Reduce 对抗聚合

Question

几年前我看到过这个问题。从那时起，MongoDB 2.4 提供了多线程 Map Reduce（在切换到 V8 Javascript 引擎之后），并且比以前的版本更快，因此速度慢的论点不是问题。

但是，我正在寻找 Map Reduce 方法可能比聚合框架更有效的场景。事实上，可能是聚合框架根本无法工作但 Map Reduce 可以获得所需结果的场景。

谢谢，约翰

Answer 1

目前聚合框架结果不能超过 16MB。但是，我认为更重要的是，您会发现 AF 更适合本质上是动态的“此时此地”类型的查询（例如，用户在运行时提供过滤器）。

MapReduce 是预先计划好的，可能要复杂得多，并且会产生非常大的输出（因为它们只是output针对新集合）。它没有您可以控制的运行时输入。您可以添加使用 AF 根本不可能（或高效）的复杂对象操作。在 MapReduce 中操作子数组（或类似数组的东西）很简单，因为您只是在编写 JavaScript，而在 AF 中，事情可能变得非常笨拙和难以管理。

最大的问题是 MapReduce 不会自动保持最新，而且很难预测它们何时会完成）。您需要实施自己的解决方案以使它们保持最新（与其他一些 NoSQL 选项不同）。通常，这只是某种时间戳和增量 MapReduce 更新，如此处所示）。您可能需要接受数据可能有些陈旧，并且它们需要未知的时间才能完成。

如果您在 StackOverflow 上四处寻找，您会发现许多非常有创意的解决方案来解决 MongoDB 的问题，并且许多解决方案使用聚合框架，因为它们正在解决 MongoDB 中通用查询引擎的限制，并且可以生成“实时/即时”结果。（一些 AF 管道非常复杂，但取决于开发人员/团队/产品，这可能是一个问题）。

Answer 2

看看这个。

聚合固件结果存储在单个文档中，因此限制为16 MB：这可能不适合某些场景。使用 MapReduce 有几种可用的输出类型，包括一个新的整个集合，因此它没有空间限制。

通常，当您必须处理大型数据集（可能是整个集合）时，MapReduce 会更好。此外，它提供了更大的灵活性（您编写自己的聚合逻辑），而不是仅限于某些管道命令。