0
У меня есть следующий образец коллекции:Повышение производительности 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}
});
Я вставил 10000 строк для оценки производительности схемы
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» с тем же результатом.
Подводя итоги, по моему мнению, запрос сканирует слишком много строк, что я делаю неправильно? Может быть, определение схемы?
спасибо !!
Для индексов ГЭП, nscanned * номер не являются документами , Они представляют собой нечто внутреннее по отношению к геоинформатору, о котором не обязательно знать - важно то, что число по-прежнему пропорционально объему работы, поэтому его можно использовать для сравнения геоинформаций. Сообщаемое время составляет 95 мс, чтобы получить все 10000 документов, поэтому я думаю, что запрос выполнен отлично (обратите внимание: на самом деле не используйте поле millis в объяснении для информации о синхронизации в целом). – wdberkeley
Спасибо за ваш комментарий. Я продолжал сегодня оценивать информацию (изучая смысл полей «объяснять»), и если вы включаете ограничение или ограничение, nscanned data является правильным, а milis - до 4. Таким образом, это было просто плохое использование найти, это не было проблемой с фильтрами определения схемы. –