MongoDB 和 MapReduce 以及极其缓慢的性能答案

【问题标题】：MongoDB & MapReduce and insanely slow performanceMongoDB 和 MapReduce 以及极其缓慢的性能
【发布时间】：2013-03-07 19:54:12
【问题描述】：

我在 Mongo 实例中存储了大约 700000 个文档。它在 2GB VPS 上运行，因此无法预期最终速度。我使用 NodeJS 和 Mongoose 来完成这项工作。

文档格式如下：

avgObjSize 是 3191，所以它们不是最大的也不是最小的.. 基本上是短文本列表。

所以我需要做的是将某些值与在所有 3 级键中的 4 级键 C 中找到的所有值进行匹配。棘手的部分是只有在第 4 级键 Cs 中找到 XX% 的匹配值时才会返回文档。

我尝试过 MapReduce，以便一切都发生在 map 函数中，它只发出预处理对象，我尝试返回所有文档和后处理，我尝试使用 map 函数仅输出 4 级键 Cs 和我试过使用 Mongo 自己的函数，比如 $all 等。

问题是一切都非常缓慢。我的意思是每秒不到 500 个文档。该集合只会增长，所以我的问题是我只是错过了如何正确使用 Mongo 的东西，还是像这样的任务这么慢？我阅读了以前的问题，Mongo 中的 MR 有一些问题很慢，但这并不慢，这是在爬行。

【问题讨论】：

【解决方案1】：

查看您的结构，我建议您将文档重组为更有效的格式。使用第 4 级键进行匹配预计会很慢。要么向上移动它们，要么让它们成为自己的文档。

【讨论】：

好的。不知道为什么它会影响速度，因为使用 mapreduce 我没有查询该标准，我只是通过循环运行第 4 级，或者运行 foo.bar.oz 的循环是否比 foo.bar 慢？但是，如果唯一的解决方案是重组数据，那么 Riak 来了。

【解决方案2】：

avgObjSize 为 3191

所以 3.1MB * 700,000 大约是 2.1GB。这意味着根据您的问题内容判断，您的工作集可能会超出您最可能知道的当前 RAM 数量。

这里要考虑的另一点是，您将 3.1MB 加载到 RAM 中，这对于每个文档来说是相当大的数量。

您还应该考虑到由于 JS 引擎是 JS 而不是 MongoDB 的本机 C++ 编码，并且当然是单线程，因此已经降低了速度。

问题是一切都非常缓慢。我的意思是每秒不到 500 个文档。

实际上，您还在寻找每个 3 级键的 4 级键可能存在于每个键本身的位置。这是相当多的循环和躲避才能得到你的结果。

您很可能遇到递归问题。

Riak 我们来了

我怀疑这会有所帮助，无论你走到哪里，这个查询都会很慢。相反，您应该研究如何根据您的加入模式设计架构，就像在设计可扩展技术时一样。

【讨论】：

实际上，无论出于何种原因，Mongo 都没有使用那么多内存。 Mongo 的文档说它将使用所有可用内存，但在我们的情况下不会。如果循环是问题所在，为什么在不处理的情况下获取所有内容与处理一样慢？对我来说没有意义。但你是对的，这不是我希望 Mongo 能够“实时”处理的事情。 Riak 是我们的下一步，因为坦率地说，Mongo 在很多层面上都很糟糕，而选择它的唯一原因是查询功能。至少使用 Riak，我们可以通过廉价的 OpenVZ VPS 轻松获得更多处理能力。
@jimmy 嗯，如果内存不足，那可能是另一个问题，我不知道那部分，也许您的预读设置需要修改？ kchodorow.com/blog/2012/05/10/…