借助新的聚合管道阶段$lookup，我们现在能够执行“左外连接”。
乍一看，我想立即用两个单独的集合替换我们的一个非规范化集合，并在查询时使用$lookup 加入它们。这将解决在必要时更新大量文档的问题。现在我们只能更新一个文档。
但这肯定好得令人难以置信？毕竟这是一个 NoSQL 文档数据库！
MongoDB的CTO也highlights his concerns:
我们仍然担心 $lookup 可能被滥用来处理 MongoDB 就像一个关系数据库。但与其限制它的可用性， 我们将帮助开发人员了解何时使用它是合适的，并且 当它是反模式时。在接下来的几个月里，我们将超越 现有文档可在该领域提供清晰、有力的指导。
$lookup 的限制是什么？我可以将它们用于对我们的数据进行实时、可操作的查询，还是应该将它们留作报告、离线情况？
【问题讨论】：
标签： mongodb mongodb-query
我和你一样对$lookup 充满热情。
我认为需要权衡取舍。 SQL 数据库的主要关注点之一（这也是 NoSQL 起源的原因之一）是，在大规模情况下，连接可能需要很多时间（嗯，相对而言）。
它肯定有助于为您的数据提供一个声明性模型，但是如果您开始对整个 NoSQL 数据库进行建模，就好像它是一个包含行和表的数据库（例如，仅使用 refs），那么您开始对其进行建模，就好像它只是一个 SQL 数据库（在一定程度上）。甚至 MongoDB 也提到了它（就像您提出的问题一样）：
我们仍然担心 $lookup 可能会被滥用以将 MongoDB 视为关系数据库。
你提到：
这将解决在必要时更新大量文档的问题。现在我们只能更新一个文档。
我不确定您的收藏到底是什么样的，但这听起来绝对可以很好地用于$lookup。
我可以在实时、可操作的查询中使用它们
我要再说一遍，这取决于您的用例。你必须比较：
$lookup）是否值得在计算时间上进行潜在的权衡（假设跨集合查询甚至是值得关注的事情，从计算上讲）
等等……
我相信在接下来的几个月中，我们会看到“左外连接”的性能测试，也许 MongoDB 会开始写一些关于 $lookup 何时成为反模式的帖子。
希望这个答案有助于增加讨论。
【讨论】：
首先，MongoDB 是一个基于文档的数据库，并且永远都是。所以 3.2 版中新增的 $lookup 聚合管道阶段并没有像 MongoDB 的 CTO 提到的那样将 MongoDB 更改为关系数据库 (RDBMS)：
我们仍然担心 $lookup 可能会被滥用以将 MongoDB 视为关系数据库。
文档中提到的$lookup的第一个限制是：
对同一数据库中的未分片集合执行左外连接，以过滤来自“已连接”集合的文档以进行处理。
这意味着您不能将它与分片集合一起使用。
此外，$lookup 运算符不能直接与post 中提到的数组一起使用，因此您需要一个初步的$unwind 阶段来对localField 进行非规范化（如果它是一个数组）。
现在你说：
这将解决在必要时更新大量文档的问题。
如果您的数据更新频率高于读取频率，这是一个好主意。 如6 Rules of Thumb for MongoDB Schema Design: Part 3 中所述，尤其是在您拥有大型分层数据集的情况下。
如果这些字段的读取频率远高于更新频率，则对一个或多个字段进行非规范化是有意义的。
我相信如果小心schema design，您可能不需要$lookup 运算符。
【讨论】：