MongoDB:性能优化:聚合管道(一个集合) VS聚合加上对单独集合的额外查询

Question

我想知道在查询mongodb方面哪个更快。假设我想搜索基于地区的收入信息，一个人可以在不同的州有多个居住地。每个多边形区域都会有该个人的相关收入。

我已经概述了查询此信息的两个选项，我想知道哪一个搜索更快。

1)拥有包含两种类型文档的单个集合。Document1:具有带多边形的地理空间索引，并将具有2dsphere索引。它将使用聚合进行搜索，以返回链接到文档2的in。实质上，它取代了mysql中的关系。

Document2:有其他信息(比如收入数量)和不同的索引，但是有一个id，第一个文档也必须引用它。也有一个关于收入金额的索引。

这两个文档使用聚合管道进行搜索。流水线的第一阶段:在地理空间上搜索document1中的项目并获取id值。流水线的第二阶段:使用在document1中找到的id搜索第二个文档。以及按收入类型搜索。

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

3)第三种选择涉及polyglot数据库，mongodb和postigs的组合:查询postgis的id，然后使用它来搜索mongodb集合。我之所以加入这个选项，是因为我相信postgis在地理空间上的查询速度会比mogo快，但我很好奇postgis的速度是否会因为现在查询两个数据库的延迟而无关紧要。

最终目标是基于地理空间半径回调数据。一个地理空间多边形，表示个人为该收入而居住和做生意的区域。映射到1个关系id，每个关系id映射到多个数据集。从本质上讲，我有一个多对一对多的关系。许多地理空间映射到一个人，这映射到许多数据集。

Answer 1

一般情况下，您应该将集合限制为单一类型的文档。

解决方案1将不起作用。你不能像你描述的那样使用聚合管道(如果我没理解错的话)。而且，听起来您似乎是在以关系的方式考虑使用非关系数据库的解决方案。

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

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

所有这三种解决方案都在逐渐地将这两种类型的文档拉得越来越远。我认为对于像MongoDB这样的文档数据库，最好的解决方案是嵌入这些数据。如果没有文档的真实示例，没有对应用程序的清晰理解，就不可能提出准确的解决方案。但一般来说，嵌入数据比在MongoDB中创建文档之间的关系更可取。只要没有超过16MB的文档，就值得研究嵌入是否是正确的解决方案。