提高對蒙戈geoIndex性能

我有一次收集樣本：提高對蒙戈geoIndex性能

var testSchema = new Schema({ 
title:   {type: String, required: true}, 
owner:   {type:Schema.Types.ObjectId}, 
locatedAt:  {type: {}, index: '2dsphere', sparse: true, "2dsphereIndexVersion": 2, required: true} 
});

我插入10.000行的評估模式性能

db.test.find({"locatedAt":{"$near":{"$geometry":{"type":"Point","coordinates":[2.240413,41.582159]}}}}).explain();

結果是下一個：

{ 
    "cursor" : "S2NearCursor", 
    "isMultiKey" : false, 
    "n" : 10000, 
    "nscannedObjects" : 48846, 
    "nscanned" : 48846, 
    "nscannedObjectsAllPlans" : 48846, 
    "nscannedAllPlans" : 48846, 
    "scanAndOrder" : false, 
    "indexOnly" : false, 
    "nYields" : 0, 
    "nChunkSkips" : 0, 
    "millis" : 95, 
    "indexBounds" : { 

    }, 
    "filterSet" : false 
}

我試圖用相同的結果創建一個「2d」索引。

總結在我看來，查詢是掃描太多的行，我做錯了什麼？也許模式定義？

謝謝！

來源

2014-09-24 Iván Peralta

對於地理索引，nscanned *數量不是文件。它們代表了地理索引內部的一些內容，這些內容並不一定非常重要 - 重要的是該數字與工作量成正比，因此可用於比較地理查詢。所報告的時間爲95ms以獲得所有10000個文檔，因此我認爲查詢執行正常（請注意：實際上並未使用millis字段解釋時序信息）。 – wdberkeley 2014-09-25 15:43:21

感謝您的評論。我今天繼續評估信息（瞭解'解釋'字段的含義），並且如果包含限制或約束，那麼已掃描的數據是正確的，並且milis將達到4. 因此，這只是對該發現，這不是模式定義的過濾器的問題。 – 2014-09-25 18:31:43

在評估了'Explain'文檔和博客中的一些主題後，我需要得出結論：這不是索引問題或模式定義問題。

如果包括限制約束nscanned物體下降從大約50K對象36（限10）和milis下降到4

來源

2014-09-25 18:35:41

提高對蒙戈geoIndex性能

回答

相關問題