MongoDB& MapReduce和疯狂的性能降低

时间:2013-03-07 04:55:21

标签: mongodb mongoose

我在Mongo实例中存储了大约700000个文档。它运行在2GB VPS上,因此无法达到最高速度。我使用NodeJS&猫鼬做的工作。

文档格式如下:

  • 第一级密钥
  • 第一级密钥
    • 第二级密钥A.
      • 第3级密钥A
    • 第二级密钥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有一些问题很慢,但这并不慢,这是爬行。

2 个答案:

答案 0 :(得分:0)

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

答案 1 :(得分:0)

  

avgObjSize是3191

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

此处需要考虑的另一点是,您要在RAM中加载3.1MB,这对于每个文档来说都是相当可观的。

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

  

问题是一切都是疯狂的慢。我的意思是每秒不到500个文件。

实际上,您还在寻找每个第三级密钥的第四级密钥可能存在于每个密钥中的位置。这是一个相当数量的循环和躲避即将到达你的结果。

你很可能会遇到递归问题。

  

Riak,我们来了

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