根据this 和this 的文章，显然 MapReduce 查询是 MongoDB 中最慢的事情之一。
如果数据集很大，那么使用 MapReduce 代替将整个数据集发送到客户端并在那里进行处理不是更好吗？
MapReduce 查询是否会锁定数据库并因此阻止它响应其他请求？
我发现 MapReduce 非常合乎逻辑且易于理解，而 2.1 版中的 Aggregation Framework 似乎有点压倒性！这是 MongoDB 对没有高性能 MapReduce 设施的回应，因此建议完全放弃 MapReduce？
【问题讨论】：
标签： ruby-on-rails ruby-on-rails-3 mongodb mapreduce
取决于您对“大”的定义，但我仍然会选择运行 map-reduce（在辅助节点上，这样主节点不会被阻塞）
Map-reduce 作业需要大量的短期锁。
2.1。他们在读取数据时获取读取锁，这不会阻塞任何东西。
2.2。他们在写入数据（临时或最终集合）时使用写锁。这会阻止其他操作。
2.3。他们在需要执行 javascript 时使用 JS 锁。他们一直在执行，因为 map 和 reduce 函数在 javascript 中。这是 map 阶段的一个典型序列：“获取读锁，从输入集合中获取文档，释放读锁，获取 js 锁，将 map 函数应用于该文档，释放 js 锁，获取写锁，将条目写入临时集合，释放写锁”。
是的，map-reduce 的基本思想很简单。但我发现聚合管道很简单。也许更简单。 “获取此数据，对其应用此转换数组，我将获取结果”。还有什么比这更简单的？
【讨论】：
They take JS lock whenever they need to execute javascript (that is, all the time) 是指每次执行 MapReduce 查询吗？
a secondary 上运行 MapReduce 是否意味着辅助副本集？