在非常少和非常小的文档

Question

关于其中一个或两个案例的慢速MongoDB聚合，有很多关于SO的问题：

• 要检索的大量文件
• 非常大的文件

今天困扰我的是，在我正在设置的原型中，我有一个非常慢查询，其中：

• 要检索的文件不超过10个
• 每个文档不超过300字节的信息

使用查找聚合

此查询对要检索的主文档执行lookup聚合，并且这样写（使用Python的MongoEngine）

author_lookup = {
    '$lookup': {
        'from': 'users',
        'localField': 'author_id',
        'foreignField': '_id',
        'as': 'author'
     }
}

cursor = post_collection.Post.objects.all().aggregate(author_lookup)

冒着重复自己的风险，就像这个原型的当前状态一样，要检索的文档不超过10个Post，可能要查找3个Author个文档。

以下是此查询连续5次点击的定时结果：

1.9418830871582031 seconds
3.0417070388793945 seconds
2.1725950241088867 seconds
1.3020501136779785 seconds
3.728671073913574 seconds

很慢，mm？

没有查找聚合

现在，如果我删除聚合部分并只是查询它：

cursor = post_collection.Post.objects.all()

其他条件相同，以下是此新查询连续5次点击的定时结果：

0.26596999168395996 seconds
0.00011920928955078125 seconds
0.00011205673217773438 seconds
0.0001659393310546875 seconds
0.00013589859008789062 seconds

如何解释这些结果？

我要注意的第一件事是，当使用聚合时，第一个结果并不比以下结果慢。这使我认为使用当前形式的聚合查询，不会执行缓存操作。

- ＆GT; 使用$lookup聚合框架时，有没有办法缓存结果？

第二件事是，除了使用聚合的不时明显的缓存机制外，似乎第一个查询（未缓存）的执行速度比使用聚合时快十倍。我发现很难相信在总共10个lookup文档中执行Author个文件超过4个Post文档，只需要检索10个Post文档的速度的10倍

所有这一切都让我想到，尽管我已经关注了查找聚合的MongoDB文档，但必须在这里做错了。