mongodb - MongoDB 聚合 $project 是否会减少要保存在内存中的数据量？

Question

我想知道是否写$project就在 $match 之后语句实际上是减少要保存在内存中的数据量。例如，如果我们想要一个从用户文档分页的数组元素，如下所示:

const skip = 20;
const limit = 50;

UserModel.aggregate([
            { $match: { _id: userId } },
            { $project: { _id: 0, postList: 1 } },
            { $slice: ["$postList", skip, limit] },
            { $lookup: ...
]);

假设用户文档中还有其他列表，并且它们的大小非常大。

所以，是 $project通过不在内存中使用其他大列表来帮助提高性能？

Answer 1

每个聚合阶段都会扫描来自集合(如果是第一阶段)或前一阶段的输入文档。例如，

匹配(过滤文件) - 这将减少
文件，整体尺寸

项目(转换或塑造文档) - 这可以减少(或
增加)文件的大小；剩余文件数
同

group - 减少文档数量并更改大小

跳过，限制 - 减少文档数量

排序 - 文档的大小或数量没有变化，
等

每个阶段都会影响内存或 cpu 或两者。
一般来说，文档大小、文档数量、索引和内存会影响查询性能。

文档中已经明确指定了聚合的内存限制(请参阅 Aggregation Pipeline Limits )。如果内存限制超过限制，聚合将终止。在这种情况下，您可以指定聚合选项 { allowDiskuse: true } ，使用该选项会影响查询性能。如果您的聚合在没有任何内存相关问题(例如由于超出内存限制而导致查询终止)的情况下正常工作，那么您的查询性能就没有直接问题。
$match和 $sort阶段使用索引，如果在管道早期使用。这可以提高性能。

向管道添加阶段意味着额外的处理，它会影响整体性能。这是因为前一阶段的文档必须通过这个额外的阶段。在聚合管道中，文档通过每个阶段传递 - 就像在管道中一样，阶段进行一些数据转换。如果您可以避免某个阶段，它有时会有益于整体查询性能。当数字很大时，有一个额外的(不必要的)阶段绝对是一个缺点。您必须同时考虑内存限制以及文档的大小和数量。

一个 $project可用于减小文档的大小。但是，有必要添加这个阶段吗？这取决于我上面提到的因素以及您的实现和应用程序。文档( Projection Optimization )说:

The aggregation pipeline can determine if it requires only a subset of the fields in the documents to obtain the results. If so, the pipeline will only use those required fields, reducing the amount of data passing through the pipeline.