0

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

文档格式如下:

  • 一级钥匙
  • 一级钥匙
    • 2级钥匙A
      • 3级钥匙A
    • 2级键B
      • 3级钥匙1
        • 4级钥匙A
        • 4级钥匙B
        • 4级键C
        • ...
      • 3级钥匙2
      • 3级键3
      • ...

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

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

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

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

4

2 回答 2

0

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

于 2013-03-07T06:42:20.757 回答
0

avgObjSize 为 3191

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

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

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

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

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

您很可能遇到递归问题。

Riak 我们来了

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

于 2013-03-07T11:54:12.637 回答