Question

以下是来自地理空间索引的约200万份文档集合的geo-$ near查询示例，这些文档需要将近半秒钟才能在200米半径范围内找到文档。

rs-[SNIP]:PRIMARY> db.photograph.find({'!geo': { $near: { $geometry: { coordinates: [-71.091246, 42.361474], type: 'Point' }, $maxDistance: 200 }}}).limit(100).explain();
{    
  "cursor" : "S2NearCursor",    
  "isMultiKey" : false,
  "n" : 100,
  "nscannedObjects" : 3914,
  "nscanned" : 59115,
  "nscannedObjectsAllPlans" : 3914,
  "nscannedAllPlans" : 59115,
  "scanAndOrder" : false,
  "indexOnly" : false,
  "nYields" : 462,
  "nChunkSkips" : 0,
  "millis" : 418,
  "indexBounds" : {

  },
  "server" : "[SNIP]",
  "filterSet" : false
}

我的问题：

为什么要扫描59115个对象？即使我将$ maxDistance设置为0.1或0.01米，当然两者都给出0结果，它仍然需要400毫秒并扫描50K对象。我可以调整geohashing算法，以便它使用更精细的桶大小而不需要扫描那么多吗？
对于此用例，2d索引是否优于2dsphere索引？（传统的2d索引根据文档具有可调整的散列精度。）
手动实现geohash作为范围索引会更好地减少'nscanned'吗？
为什么indexOnly在这种情况下是假的？我做在'！geo'...
ElasticSearch会表现得更好吗？我不需要ACID一致性;最终的一致性就足够了，我最需要的是原始搜索速度和同时为大量并发用户发布地理空间查询的能力。文件数量可能增长到数十亿; 99％的时间我会查询“最近100个半径范围内的100个物体”。

为什么在MongoDB中2dsphere索引上的搜索速度如此之慢？

0 个答案: