我正在重新提出这个问题，因为我认为这个问题应该是来自这个in-mongodb-know-index-of-array-element-matched-with-in-operator的单独主题。
我正在使用mongoDB，实际上我正在使用查找，更新等简单查询编写所有查询（无聚合）。现在我读了许多SO帖子，例如mongodb-aggregation-match-vs-find-speed。现在我想到为什么增加服务器上的计算时间，因为好像我将计算更多，然后我的服务器负载将变得更多，所以我尝试使用聚合，我认为我现在正朝着正确的方向。但是后来我的上一个问题andreas-limoli告诉我没有使用聚合，因为它很慢并且在服务器上使用简单的查询和计算。现在字面上，我正在讨论我应该使用什么，我正在使用mongoDB一年，但是当数据大小增加时我对它的性能没有任何了解，所以我完全不知道哪一个我应该选择。
还有一件事我在任何地方都找不到，如果聚合比因为$ lookup而不是因为$ lookup，因为$ lookup是我考虑使用聚合的最重要的事情因为否则我必须执行许多串行查询，然后在服务器上计算，在聚合前我看起来很差。
另外，当我将数据从一个管道传递到另一个管道时，我读到了关于mongodb聚合的100MB限制，因此人们如何有效地处理这种情况，以及如果他们打开磁盘使用情况，那么因为磁盘使用减慢了一切，而不是人们如何处理这种情况。
此外，我获取了30,000个样本集合，并尝试使用$ match运行聚合并查找查询，我发现聚合比查找查询快一点，聚合需要180ms才能执行，因为查找需要220毫秒才能执行。
请帮助我，请帮助我对我有用。
答案 0 :(得分：2)
MongoDB中的聚合框架类似于SQL中的联接操作。聚合管道通常是资源密集型操作。因此，如果您的工作对简单查询感到满意，则应首先使用该查询。
但是，如果绝对必要，则可以使用聚合管道，以防需要从多个集合中获取数据。
答案 1 :(得分：1)
聚合管道是昂贵的查询。由于CPU内存的增加，它可能会影响您作为增加数据的性能。如果您可以使用with find查询，那么就去吧，因为一旦DB数据增加，聚合的成本就会更高。