我有一个很大的集合，数据由 lat-lng 坐标和时间与各自的索引排列(球形地理空间和下降的时间)。
现在每步时间大约有 10,000 个点，大约有 2000 个时间步长，我想找到 5 个点中的值，这些值在某个小时间跨度内最接近给定坐标。
问题是，在记录数量达到 1000 万之后，地理空间查询的性能变得令人不安地变得不可预测：以前总是花费大约 3 秒来获取和处理，现在可以一直达到 45，这是不可接受的我的情况。
从我在 mongodb 文档中看到的，似乎如果查询需要利用地理空间索引，默认情况下它优先于查询的任何其他部分，所以在我的情况下，搜索首先经历所有 2000 个时间步骤找到“5 个最近点”的所有 10'000，然后将其缩小到我首先请求的 50 个时间步。这似乎更合理，因为沿着 geo-index 的.count()查询可以花费相同的时间。
所以基本上，如果可能的话，我想以其他方式做到这一点：首先缩小一些时间步骤，然后在这个相当小的数据集上执行$near find 或$geoNear 聚合。没有地理空间部分的查询也可以保持其性能。
在.find()查询中提示另一个索引会破坏地理空间搜索，而$geoNear 在它之前不接受任何聚合管道步骤。由于某种原因在查询之前确保 geo-index 创建了第二个 geo-index，因此聚合变得不可能
Two-step 搜索或聚合本来就很棒，但似乎 mongo 中没有这样的东西，虽然我认为它可以模仿将数据聚合到代理集合中，但这看起来是个坏主意。
虽然我对 mongodb 索引工作 and/or 生命周期有一些渐渐的误解是可能的，因为请求时间并不总是那么糟糕，如果我刚才写的是正确的应该可能。
以防万一：
-
mongodb 3.0.4;
-
电机 0.4.1 与 pymongo 2.8，虽然问题最初是在 pymongo 3.0.3 上发现的;
-
讨论集合是副本集的一部分，查询脚本在具有辅助节点的机器上本地运行。