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