我正在使用一个大约500平方公里的多边形运行geoWithin查询,这需要很长时间才能执行,在30到5分钟之间。该系列只有180k行,多边形可以是2km²到10,000km²。服务器有大约4GB的RAM。在本地运行(以消除网络延迟)没有明显的影响。
我在集合上设置了一个2dsphere索引,并将字段数限制为仅返回_id(现在)。
这就是我的文件:
{
"_id" : ObjectId("..."),
"geometry" : {
"type" : "MultiPolygon",
"coordinates" : [[...]]
},
"area_sq_m" : 6699.1309787227955894
}
这是我的索引:
[
{
"v" : 1,
"key" : {
"_id" : 1
},
"name" : "_id_",
"ns" : "db.output_areas"
},
{
"v" : 1,
"key" : {
"geometry" : "2dsphere"
},
"name" : "geometry_2dsphere",
"ns" : "db.output_areas",
"2dsphereIndexVersion" : 2
}
]
这是我的疑问:
{
"geometry": {
$geoWithin: {
$geometry: {
type: 'Polygon',
coordinates: [[ [lng,lat], [lng,lat], [lng,lat] ...]]
}
}
}
}
这是运行explain()
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "db.output_areas",
"indexFilterSet" : false,
"parsedQuery" : {
"geometry" : {
"$geoWithin" : {
"$geometry" : {
"type" : "Polygon",
"coordinates" : [...]
}
}
}
},
"winningPlan" : {
"stage" : "PROJECTION",
"transformBy" : {
"_id" : 1
},
"inputStage" : {
"stage" : "KEEP_MUTATIONS",
"inputStage" : {
"stage" : "FETCH",
"filter" : {
"geometry" : {
"$geoWithin" : {
"$geometry" : {
"type" : "Polygon",
"coordinates" : [...]
}
}
}
},
"inputStage" : {
"stage" : "IXSCAN",
"keyPattern" : {
"geometry" : "2dsphere"
},
"indexName" : "geometry_2dsphere",
"isMultiKey" : true,
"direction" : "forward",
"indexBounds" : {
"geometry" : [
"[\"2f0332301\", \"2f0332301\"]",
"[\"2f03323011\", \"2f03323011\"]",
"[\"2f033230111\", \"2f033230112\")",
"[\"2f033230112\", \"2f033230112\"]",
"[\"2f0332301120\", \"2f0332301121\")",
"[\"2f0332301121\", \"2f0332301121\"]",
"[\"2f03323011210\", \"2f03323011211\")",
"[\"2f03323011211\", \"2f03323011212\")",
"[\"2f1003230\", \"2f1003230\"]",
"[\"2f10032300\", \"2f10032300\"]",
"[\"2f100323000\", \"2f100323001\")"
]
}
}
}
}
},
"rejectedPlans" : [ ]
},
"serverInfo" : {
"version" : "3.0.4"
},
"ok" : 1
}
这表明正在使用索引。如果我尝试使用较小的区域,查询确实会变得更快,而更大的区域会更慢。
这是我的收藏统计数据:
{
"ns" : "db.output_areas",
"count" : 181408,
"size" : 3062445568,
"avgObjSize" : 16881,
"numExtents" : 22,
"storageSize" : 3927183360,
"lastExtentSize" : 1021497344,
"paddingFactor" : 1,
"paddingFactorNote" : "paddingFactor is unused and unmaintained in 3.0. It remains hard coded to 1.0 for compatibility only.",
"userFlags" : 1,
"capped" : false,
"nindexes" : 2,
"totalIndexSize" : 35606480,
"indexSizes" : {
"_id_" : 5894896,
"geometry_2dsphere" : 29711584
},
"ok" : 1
}
我运行了db.setProfilingLevel(2)
命令,重新运行了查询,然后检查了db.system.profile
集合。
第一条记录是实际查询("op": "query"
)
然后我再假设7个查询("op": "getmore"
)正在获取剩余的数据。
每个查询产生1000行("nreturned": 1000
),每个查询的平均值为millis
。
我已经阅读了许多人们抱怨geojson查询的问题> 2s> 1米行,所以我显然缺少一些简单的东西。