【发布时间】：2013-02-22 08:30:22
【问题描述】：
我知道如果有一个初始的$match 管道来限制要聚合的集合，那么聚合框架是合适的。但是，有时过滤后的集合可能仍然很大，例如大约 200 万，并且聚合将涉及$group。考虑到在最多 5 秒内输出结果的要求，聚合框架是否适合处理此类集合。目前我在一个节点上工作。通过对一个分片集进行聚合，性能会不会有显着提升。
【问题讨论】：
标签： mongodb aggregation-framework
【发布时间】：2013-02-22 08:30:22
【问题描述】：
据我所知，唯一的限制是聚合的结果不能超过 16MB 的限制，因为它返回的是一个文档，这是 MongoDB 中文档的限制大小。此外，您不能使用超过机器总内存的 10%，因为通常使用 $match 阶段来减少您使用的集合，或者使用 $project 阶段来减少每个文档的数据。
请注意，在 $group 或 $sort 阶段之后的分片环境中，聚合将被带回 MongoS，然后再将其发送到管道的下一个阶段。 MongoS 可能与您的应用程序在同一台机器上运行，如果处理不当，可能会损害您的应用程序性能。
【讨论】：
-
好的，所以它可以处理这么多的数据。但是从我目前所遇到的情况来看，当执行聚合以包含如此多的数据时，性能会下降。我在另一个question 有这个问题。在某种程度上，这似乎是一种限制。
-
确实如此，毕竟它必须扫描所有数据。除了大小限制之外，这是使用 $match 或 $project 减少数据量的另一个原因。如果您使用分片，扫描的数据将只是存储在分片中的子集，因此它不会扫描整个集合，因此会提高性能。
-
虽然看起来确实很昂贵，但如果我有 500 万个文档要聚合，看来我需要设置多个分片才能实时获得结果。 :(
-
您是否正确创建了索引？正如您在docs.mongodb.org/manual/applications/aggregation/… 看到的那样，有几个聚合阶段可以利用索引。如果您充分利用索引，500 万份文档应该不是问题。
-
是的，我确实有用于
$match的字段的索引，但结果输出仍然很大（想想 200 万个苹果放在 5M 的水果篮中）。看来，$group这样的后续操作可能是瓶颈。如果我有 4G 内存，是否足以处理流水线操作？