使用新的聚合管道阶段$lookup，我们现在可以执行左外连接＆＃39;。
乍一看，我想立即用两个单独的集合替换我们的非规范化集合之一，并在查询时使用$lookup加入它们。这将解决在必要时更新大量文档的问题。现在我们只能更新一个文档。
但肯定这太好了，不能成为现实吗？毕竟这是一个NoSQL文档数据库！
MongoDB的首席技术官highlights his concerns：
我们仍然担心$ lookup会被滥用来对待MongoDB 像一个关系数据库。但不是限制其可用性， 我们将帮助开发人员知道它的使用何时合适，并且 当它是一个反模式。在接下来的几个月里，我们将超越 现有文件，为该领域提供明确，有力的指导。
$lookup有哪些限制？我是否可以在实时查询数据时使用它们，还是将它们留给报告，离线情况？
答案 0 :(得分：4)
我对$lookup抱有同样的热情。
我认为存在权衡取舍。 SQL数据库的主要问题之一（也是NoSQL起源的原因之一）是，大规模连接可能需要花费大量时间（相对而言）。
它肯定有助于为您提供数据的声明性模型，但是如果您开始为整个NoSQL数据库建模，就好像它是一个行和表的数据库（例如，仅使用ref），然后你就开始建模它，好像它只是一个SQL数据库（在某种程度上）。甚至MongoDB都提到了它（就像你提出的问题一样）：
我们仍然担心$ lookup会被滥用来像对待关系数据库那样对待MongoDB。
你提到了：
这将解决在必要时更新大量文档的问题。现在我们只能更新一个文档。
我不确定你的收藏品究竟是什么样的，但这听起来肯定对$lookup有用。
我可以在实时，可操作的查询中使用它们吗
我想再说一次，这取决于你的用例。你必须比较：
$lookup）值得在计算时间内进行权衡（假设跨集合查询甚至是需要关注的事情）关于，从计算上讲）等...
我相信在接下来的几个月里，我们会看到＆＃34;左外连接的性能测试＆＃34;也许MongoDB会开始写一些关于何时$lookup是反模式的帖子。
希望这个答案有助于增加讨论。
答案 1 :(得分：4)
首先，MongoDB是一个基于文档的数据库，并且永远都是。因此，版本3.2中新增的$lookup聚合管道阶段并没有像MongoDB的CTO所提到的那样将MongoDB更改为关系数据库（RDBMS）：
我们仍然担心$ lookup会被滥用来像对待关系数据库那样对待MongoDB。
文档中提到的$lookup的第一个限制是：
对同一数据库中的未整数集合执行左外连接，以过滤“已连接”集合中的文档以进行处理。
这意味着您无法将其与分片集合一起使用。
此$lookup运算符也不会像post中提到的那样直接使用数组，因此，如果localField非正规化，则需要初步$unwind阶段它是一个数组。
现在你说：
这将解决在必要时更新大量文档的问题。
如果您的数据经常更新而不是读取，这是一个好主意。 如6 Rules of Thumb for MongoDB Schema Design: Part 3中所述，特别是如果您有大型分层数据集。
如果这些字段的读取频率远远超过更新字段，则对一个或多个字段进行非规范化是有意义的。
我相信谨慎schema design您可能不需要$lookup运营商。