MongoDB：性能优化：聚合管道（一个集合）VS聚集加上附加查询分离集合

Question

我想知道在查询mongodb方面更快。 可以说我想根据地区搜索收入信息 而且一个人可以在不同的州有很多居住地。每个多边形区域都会为该个人提供相关的收入。

我列出了两个查询此信息的选项，我想知道哪个搜索更快。

1）拥有一个包含两种类型文档的集合。 Document1：在它上面有一个带有多边形的地理空间索引，并且其上会有012ds2dsphere索引。它将通过聚合来搜索，以返回将链接到文档2的id。本质上取代了mysql中的关系。 Document2：有其他信息（可以说是收入金额）和不同的索引，但有一个ID ，第一个文档也必须引用它。 并且还有一个收入指数。

使用聚合管道搜索这两个文档。 管道的第一阶段：在地理空间中搜索document1以查找项目并获取id值。 管道第二阶段：使用document1中的id查找第二个文件。以及收入类型搜索。

2）分离出每个文件都有自己的集合并避免聚合的文档。 查询collection1的地理空间信息，并使用发现的人员id查询collection2获取收入信息。

3）第三个选项涉及多语种数据库，mongodb和postigs的组合：查询postgis为id，然后用它搜索mongodb collecton。我包括这个选项，因为我认为postgis比mogo查询地理空间更快，但我很好奇，由于现在查询两个数据库的延迟，postgis的速度并不重要。

最终目标是根据地理空间半径拉回数据。一个地理空间多边形代表该人员居住并为该收入做生意的区域。 映射到1关系id并且每个关系id映射到多组数据。基本上我有很多对一对多的关系。 许多geospatials映射到1人映射到许多数据集。

Answer 1

您通常应该将集合限制为单一类型的文档。

解决方案1不起作用。你不能像你所描述的那样使用聚合管道（如果我正确理解你的话）。此外，听起来好像您正在以关系方式思考使用非关系数据库的解决方案。

解决方案2将工作，但它不会有最佳性能。这个解决方案听起来更像是一个关系数据库解决方案，其中的集合被视为像表一样对待。

解决方案3可能会工作，但正如你所说，它现在需要两个数据库。

所有这三种解决方案都逐步将这两种类型的文档拉得越来越远。我相信像MongoDB这样的文档数据库的最佳解决方案就是嵌入这些数据。如果没有您的文档的真实例子，并且没有清楚地了解您的应用程序以提供确切的解决方案，这是不可能的。但是通常嵌入数据比在MongoDB中创建文档之间的关系更受欢迎。只要没有文件将超过16MB，值得研究嵌入是否是正确的解决方案。