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