Performance MongoDB在聚合查询上的性能

听了很多关于MongoDB性能的好消息后，我们决定让MongoDB尝试解决我们遇到的问题。我首先将几个mysql数据库中的所有记录移动到mongodb中的一个集合中。这导致了一个拥有2900万文档的集合，其中每个文档至少有20个字段，在HD中占用了大约100GB的空间。我们决定将它们全部放在一个集合中，因为所有文档都具有相同的结构，我们希望查询和聚合所有这些文档的结果

我创建了一些索引来匹配我的查询，否则即使是简单的计数也需要花费很多时间。但是，诸如distinct和group之类的查询仍然需要很长时间

例如：

// creation of a compound index    
db.collection.ensureIndex({'metadata.system':1, 'metadata.company':1})

// query to get all the combinations companies and systems
db.collection.group({key: { 'metadata.system':true, 'metadata.company':true }, reduce: function(obj,prev) {}, initial: {} });

我查看了mongod日志，在执行上面的查询时，它有很多类似的行：

Thu Apr  8 14:40:05 getmore database.collection cid:973023491046432059 ntoreturn:0 query: {}  bytes:1048890 nreturned:417 154ms
Thu Apr  8 14:40:08 getmore database.collection cid:973023491046432059 ntoreturn:0 query: {}  bytes:1050205 nreturned:414 430ms
Thu Apr  8 14:40:18 getmore database.collection cid:973023491046432059 ntoreturn:0 query: {}  bytes:1049748 nreturned:201 130ms
Thu Apr  8 14:40:27 getmore database.collection cid:973023491046432059 ntoreturn:0 query: {}  bytes:1051925 nreturned:221 118ms
Thu Apr  8 14:40:30 getmore database.collection cid:973023491046432059 ntoreturn:0 query: {}  bytes:1053096 nreturned:250 164ms
...
Thu Apr  8 15:04:18 query database.$cmd ntoreturn:1 command  reslen:4130 1475894ms

这个查询耗时1475894ms，比我预期的结果列表大约有60个条目要长得多。首先，考虑到我的收藏中有大量的文档，这是预期的吗？在mongodb中，聚合查询通常会如此缓慢吗？有没有关于如何提高绩效的想法

我在一台具有双核和10GB内存的机器上运行mongod

---

谢谢。

我们的想法是在分布在多台机器上的分片数据库上使用MapReduce来提高聚合查询的性能

在同一台机器上，我将Mongo的Mapreduce与Oracle中的GROUPBY select语句的性能进行了一些比较。我确实发现Mongo大约慢了25倍。这意味着我必须在至少25台机器上共享数据，才能使用Mongo获得与Oracle在一台机器上提供的性能相同的性能。我使用了一个包含大约1400万个文档/行的集合/表

---

通过mongoexport.exe从mongo导出数据，将导出的数据用作Oracle中的外部表，并在Oracle中执行group by，这比使用mongo自己的MapReduce要快得多

聚合映射reduce或其他方式在mongo中非常慢，因为它是由javascript VM完成的，而不是数据库引擎。这仍然是时间序列数据的一个非常好的imo db限制。

两件事

1您的组查询正在处理大量数据。虽然您的结果集很小，但看起来它正在对集合中的所有数据进行表格缩放，以便生成较小的结果。这可能是缓慢的根本原因。为了加快速度，您可能希望在查询运行时通过iostat查看服务器的磁盘性能，因为这可能是瓶颈

2正如在其他答案中指出的，group命令使用javascript解释器，这将限制性能。您可以尝试使用新的聚合框架，该框架在2.1版本中作为beta版发布。注意：这是一个截至2012年2月24日的不稳定版本。请参阅以获得良好的介绍。这不会克服1中的数据卷问题，但是它是用C++实现的，如果JavaScript时间是瓶颈，那么它应该快很多。p>

---

3另一种方法是使用增量map reduce生成包含分组结果的第二个集合。其思想是，您可以运行一个map reduce作业来聚合一次结果，然后定期运行另一个map reduce作业，将新数据重新缩减到现有集合中。然后，您可以从应用程序中查询第二个集合，而不是每次都运行group命令

知道MongoDB的哪个版本真的很有帮助。我相信它类似于1.4.0版。这要追溯到2010年。这个问题太老了，当您搜索MongoDB聚合框架时，仍然会出现在搜索引擎上。马里奥，你没有提到你的MongoDB版本，因为他们在2.4版本中提高了很多AF，而我是在一个糟糕的m1版本上做的。EC2拥有3.7G内存，超过了69m的数据集，速度比以前快了很多。您是否尝试过新版本，或者使用了不同的方法？当然，AF和MapReduce有很多基准测试，但请看一下10Gen tnxThanks的最新基准测试，以获取您的评论。这是在2010年，我相信我们使用了类似MongoDB1.4.0的东西。已经有一段时间了，我确信mongodb中的很多事情都发生了变化，但我从那年晚些时候开始就没有在该项目中工作过：感谢Mario的回复。我刚开始使用MongoDB大约一年，只是想看看你的项目发生了什么。祝你好运：从v2.2开始，聚合管道使用。