我有一个包含1亿个几何文档的集合。
我有第二个集合，其中包含与其他每个几何图形关联的时间数据。这将是 365 * 96 * 1 亿或 3.5 万亿个文档。
与其存储比需要多1亿个条目（365 * 96）倍，我想将它们保存在单独的集合中，并在MongoDB中执行一种JOIN/DBRef/Anything。
首先，我想使用地理交集从几何集合中获取 GUID 列表。这会将其过滤到 1 亿到 5000。然后，使用这 5000 个几何图形 guid，我想根据 5000 个几何图形和其他日期条件过滤 3.5 万亿个文档，我指定并聚合数据并找到平均值。对于您指定的日期条件，您剩下 5000 个几何和 5000 个平均值。
这基本上是我在SQL中知道的JOIN，在MongoDB中是否可能，并且可以在不到10秒的时间内以最佳方式完成。
澄清：据我了解，这就是 DBrefs 的用途，但我读到它根本没有效率，而且处理这么多数据，它不太合适。
如果您要同时处理几何及其时间序列数据，将它们存储在同一个文档中是有意义的。以 15 分钟为增量的一年数据并不是杀手锏 - 而且您绝对不希望每个时间序列条目都有一个文档！由于您可以将要操作的所有内容作为单个几何文档进行检索，因此这是一个巨大的胜利。请注意，这也可以让您稀疏丢失的数据。如果数据是稀疏的，则可以对数据进行不同的编码，而不是索引到 35040 插槽数组中。
不过，对一大堆几何数据进行$geoIntersects将是一个性能问题。确保你有一些索引（如2dsphere）来加快速度。
如果有任何方法可以在查询中构建其他限定符，从而可以廉价地从更昂贵的搜索中消除成员，则可以使事情变得简单。比如说，搜索将击中美国的州。您可以首先将搜索与州边界相交，以查找包含地理数据的州，并使用邮政编码之类的内容来限定文档。这将是对50个文档的非常快速的预搜索。如果搜索边界最初确定为达到 2 个状态，并且地理数据记录包含一个州字段，则在查询的更昂贵的地理部分之前，您只是筛选掉了 9600 万条记录（在所有条件相同的情况下）。如果与较小的格网坐标相交，则可以在考虑地理数据之前进一步筛选它。
当然，走得太远会增加开销。如果你能正确地将系统调整到1亿个几何形状的密度，你也许能够把时间缩短得相当低。但是，如果不实际处理问题的具体情况，就很难知道。如此多的数据可能需要一些特定的实验，而不是依赖于通用的解决方案。