千万级数据分页优化
mongo采用的是单机部署,数据量1千万,需求是实现分页面,按照capTime倒叙排列,每页数据20条
db.getCollection('CapMotor').find().skip(9000000).sort({'capTime':1}).limit(20);
skip后面是pageSize*pageIndex,limit后是pageSize 这种方式在数据量是百万的时候,还凑合着用,但是千万以后,就不可用了,我这边跟踪的查询时间是9s左右,明显不行,影响效率,建议采用第2中方法前端在查询下一页数据的时候讲,当前页数据的最后一条,capTime这个字段传过来,值是:1548482420,并且把该条数据对应的objectid也传过来,对应值:ObjectId("5bc5ce033b071d2fa84e60f4"),如果是相同的时间,对应的多条数据,要都传递过来,mongo查询的时候,添加条件capTime大于等于1548482420,并且不包含这几条数据,以下是对应的代码
// 数据查询下一页时:
db.getCollection('CapMotor').find({
"$and":[
{'capTime' :{ "$gte" :1548482420}},
{'_id':{"$ne":ObjectId("5bc5ce033b071d2fa84e60f4")}}
]
})
.sort({'capTime':1}).limit(20)
复制代码
注:以上是我考虑的按照某个字段排序,并且该字段的值有可能会有多个的情况,实际在开发中,该字段的值有可能是唯一的,对应的代码如下
// 数据查询下一页时:
db.getCollection('CapMotor').find({'capTime' :{ "$gt" :1539582402} }).sort({'capTime':1}).limit(20)
复制代码
第一种方法,前端可以指定调到首页,尾页,上下一页,中间指定页,但是前提是数据量不过百万的情况下; 第二种方法执行比较快,但是前端不能跳到指定的页数,首页,尾页,上下一页这种是可以的;
mongodb 分析器explain
本次是以3.4.15-49-g4ef027f为例,各个版本的执行计划差异较大
/* 1 */
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "bigdata.faceCapture",
"indexFilterSet" : false,
"parsedQuery" : {
"fcap_id" : {
"$lt" : "fd129550-ced3-11e8-8ea8-1866daf63d9f"
}
},
"winningPlan" : {
"stage" : "FETCH",
"inputStage" : {
"stage" : "IXSCAN",
"keyPattern" : {
"fcap_id" : 1
},
"indexName" : "fcap_id_1",
"isMultiKey" : false,
"multiKeyPaths" : {
"fcap_id" : []
},
"isUnique" : false,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 2,
"direction" : "forward",
"indexBounds" : {
"fcap_id" : [
"[\"\", \"fd129550-ced3-11e8-8ea8-1866daf63d9f\")"
]
}
}
},
"rejectedPlans" : []
},
"serverInfo" : {
"host" : "master",
"port" : 27017,
"version" : "3.4.15-49-g4ef027f",
"gitVersion" : "4ef027f98d5c00a0f4e507cbe39a22cab4c7a44c"
},
"ok" : 1.0
}
复制代码
重点关注queryPlanner里的winningPlan即可, explain.queryPlanner.winningPlan.stage:最优执行计划的stage,这里返回是FETCH,可以理解为通过返回的index位置去检索具体的文档(stage有数个模式,将在后文中进行详解)。
Explain.queryPlanner.winningPlan.inputStage:用来描述子stage,并且为其父stage提供文档和索引关键字。
explain.queryPlanner.winningPlan.stage的child stage,此处是IXSCAN,表示进行的是index scanning。
state各个值的解释如下: COLLSCAN :全表扫描
IXSCAN:索引扫描
FETCH::根据索引去检索指定document
SHARD_MERGE:各个分片返回数据进行merge
SORT:表明在内存中进行了排序(与前期版本的scanAndOrder:true一致)
SORT_MERGE:表明在内存中进行了排序后再合并
LIMIT:使用limit限制返回数
SKIP:使用skip进行跳过
IDHACK:针对_id进行查询
SHARDING_FILTER:通过mongos对分片数据进行查询
COUNT:利用db.coll.count()之类进行count运算
COUNTSCAN:count不使用用Index进行count时的stage返回
COUNT_SCAN:count使用了Index进行count时的stage返回
SUBPLA:未使用到索引的$or查询的stage返回
TEXT:使用全文索引进行查询时候的stage返回
集合faceCapture中有数据1千万条以上的数据,有复合索引fcap_time、fcap_dcid、person_id
{
"fcap_time" : -1,
"fcap_dcid" : 1,
"person_id" : 1
}
复制代码
单行索引fcap_time、fcap_id
{
"fcap_time" : 1
}
复制代码
{
"fcap_id" : 1
}
复制代码
用关键字explain进行sql分析,发现如下问题:
// 走的是复合索引 注意索引的顺序,fcap_time" : -1, "fcap_dcid" : 1, "person_id" : 1
db.getCollection('faceCapture').find({'fcap_time' :{ "$gt" :1539745381}}).explain()
// 以下两个字段都是复合索引中,未走索引,
db.getCollection('faceCapture').find({'fcap_dcid' :{ "$lt" :"fd129550-ced3-11e8-8ea8-1866daf63d9f"}}).explain()
db.getCollection('faceCapture').find({'person_id' :{ "$lt" :"fd129550-ced3-11e8-8ea8-1866daf63d9f"}}).explain()
// 走的是索引 fcap_id" : -1,
db.getCollection('faceCapture').find({'fcap_id' :{ "$lt" :"fd129550-ced3-11e8-8ea8-1866daf63d9f"}}).explain()
db.getCollection('faceCapture').find({'fcap_id' :{ "$lt" :"fd129550-ced3-11e8-8ea8-1866daf63d9f"}}).count()
复制代码
以下有如下结论
mongodb的索引也有最前缀原则,类似于mysql中的like关键字; 复合索引和单列索引中都有同一列,并且该列是位于复合索引的第一个位置时,默认走的是复合索引; 复合索引的非首位查询时,默认不走索引;