mongoDB 性能中许多 Map/Reduce 作业的并行化答案

【问题标题】：Parallelization of many Map/Reduce jobs in mongoDB performancemongoDB 性能中许多 Map/Reduce 作业的并行化
【发布时间】：2014-05-19 09:06:21
【问题描述】：

我必须执行一个启动大量 Map/Reduce (~400) 的操作，但每个 Map/Reduce 都在不同的集合上，所以它不能是任何并发写入。

为了提高此操作的性能，我通过在应用程序端为每个 Map/Reduce 创建一个线程（我使用 Java 驱动程序）来使其瘫痪（注意我不使用分片模式）。

但是当我比较结果时，我得到了一些最差的结果，与顺序执行（单线程）相比。更准确地说：顺序执行需要 341 秒，分布式执行需要 904 秒。所以不是得到更好的执行时间，而是延长了三倍。

有人知道为什么 mongoDB 不喜欢 Map/Reduce 进程的并行化吗？

我找到了一篇关于它的文章 (link)，但是现在 mongoDB 使用 V8 引擎我认为应该没问题。

【问题讨论】：

您究竟是如何为每个 map reduce 创建一个线程的？据我所知，MongoDB 会自己处理这些东西，所以我不确定你是如何为每个隔离创建一个线程的
是的，抱歉，我编辑了我的帖子。我说的是应用程序方面。只是我不等第一个map/reduce的执行才启动其他的命令，所以同时查询所有的map/reduce。

标签： multithreading performance mongodb mapreduce

【解决方案1】：

首先，在不同的数据库上做 Map/Reduces，每个数据库都有锁（现在是 2.6 版）。其次，需要更多的RAM和更快的磁盘IO，可能会出现瓶颈。

这是一个关于如何使用多核的示例。 http://edgystuff.tumblr.com/post/54709368492/how-to-speed-up-mongodb-map-reduce-by-20x “问题是线程之间存在过多的锁争用。MR 在锁定时并不是很无私（它每 1000 次读取产生一次），而且由于 MR 作业也进行大量写入，线程最终会相互等待。因为MongoDB 每个数据库都有单独的锁”

【讨论】：