千万级 MongoDB 数据索引优化实践

·  阅读 915
千万级 MongoDB 数据索引优化实践

小李是这家公司的后端负责人,突然有一天下午,收到大量客服反馈用户无法使用我们的APP,很多操作与加载都是网络等待超时。

收到信息后,小李立马排查问题原因,不过多一会,定位到数据库出现大量慢查询导致服务器超负荷负载状态,CPU居高不下,那么为什么会出现这个情况呢,此时小李很慌,经过查询资料,开始往慢查询方向探究,果不其然,由于业务数据增长迅猛,对应的数据表没有相应查询的索引数据,此刻小李嘴角上扬,面露微笑,信心百倍上手的给数据库相关数据表加上了索引字段。但是情况并没有好转,线上依旧没有恢复,经验使然,最后只能采取降级的方案(关闭此表的相关查询业务)临时先恢复线上正常。

但是事情并没有结束,问题没有根本性的解决,公司和自己依旧非常在意这个问题的解决,晚上吃饭的时候,小李突然想起了自己有认识一个行业大佬(老白)。把问题跟老白说了一遍,老白并没过多久,很快就专业的告诉了小白哪些操作存在问题,怎么样可以正确的解决这个问题,加索引的时候首先要学会做查询分析,然后了解ESR最佳实践规则(下面会做说明),小李没有因为自己的不足感到失落,反而是因为自己的不足更是充满了求知欲。

数据库索引的应用有哪些优秀的姿势呢?

MongoDB 索引类型

单键索引

db.user.createIndex({createdAt: 1}) 
复制代码

createdAt创建了单字段索引,可以快速检索createdAt字段的各种查询请求,比较常见 {createdAt: 1} 升序索引,也可以通过{createdAt: -1}来降序索引,对于单字段索引, 升序/降序效果是一样的。

组合索引

db.user.createIndex({age: 1, createdAt: 1}) 
复制代码

可以对多个字段联合创建索引,先按第一个字段排序,第一个字段相同的文档按第二个字段排序,依次类推,所以在做查询的时候排序与索引的应用也是非常重要。

实际场景,使用最多的也是这类索引,在MongoDB中是满足所以能匹配符合索引前缀的查询,例如已经存在db.user.createIndex({age: 1, createdAt: 1}) , 我们就不需要单独为db.user.createIndex({age: 1}) 建立索引,因为单独使用age做查询条件的时候,也是可以命中db.user.createIndex({age: 1, createdAt: 1}) ,但是使用createdAt单独作为查询条件的时候是不能匹配db.user.createIndex({age: 1, createdAt: 1})

多值索引

当索引的字段为数组时,创建出的索引称为多key索引,多key索引会为数组的每个元素建立一条索引

// 用户的社交登录信息,
schema = {
    …
    snsPlatforms:[{
        platform:String, // 登录平台
        openId:String, // 登录唯一标识符
    }]
}
// 这也是一个列转行文档设计,后面会说
db.user.createIndex({snsPlatforms.openId:1}) 
复制代码

TTL 索引

可以针对某个时间字段,指定文档的过期时间(用于仅在一段时间有效的数据存储,文档达到指定时间就会被删除,这样就可以完成自动删除数据) 这个删除操作是安全的,数据会选择在应用的低峰期执行,所以不会因为删除大量文件造成高额IO严重影响数据性能。

部分索引

3.2版本才支持该特性,给符合条件的数据文档建立索引,意在节约索引存储空间与写入成本

db.user.createIndex({sns.qq.openId:1})
/**
 * 给qq登录openid加索引,系统其实只有很少一部分用到qq登录 ,然后才会存在这个数据字段,这个时
 * 候就没有必要给所有文档加上这个索引,仅需要满足条件才加索引
 */
db.user.createIndex({sns.qq.openId:1} ,{partialFilterExpression:{$exists:1}})
复制代码

稀疏索引

稀疏索引仅包含具有索引字段的文档条目,即使索引字段包含空值也是如此。 索引会跳过缺少索引字段的所有文档。

db.user.createIndex({sns.qq.openId:1} ,{sparse:true})

注:3.2版本开始,提供了部分索引,可以当做稀疏索引的超集,官方推荐优先使用部分索引而不是稀疏索引。

ESR索引规则

索引字段顺序: equal(精准匹配) > sort (排序条件)> range (范围查询)

精确(Equal)匹配的字段放最前面,排序(Sort)条件放中间,范围(Range)匹配的字段放最后面,也适用于ES,ER。

实际例子:获取成绩表中,高2班中数学分数大于120的学生,按照分数从大到小排序 不难看出,班级和学科(数学)可以是精准匹配,分数是一个范围查询,同时也是排序条件 那么按照ESR规则我们可以这样建立索引 {"班级":1,"学科":1,"分数":1}

我们怎么分析这个索引的命中与有效情况呢?

db.collection.explain()函数可以输出文档查找执行计划,可以帮助我们做更正确的选择。 分析函数返回的数据很多,但我们主要可以关注这个字段

executionStats 执行统计

{
    "queryPlanner": {
        "plannerVersion": 1,
        "namespace": "test.user",
        "indexFilterSet": false,
        "parsedQuery": {
            "age": {
                "$eq": 13
            }
        },
        "winningPlan": { ... },
        "rejectedPlans": []
    },
    "executionStats": {
        "executionSuccess": true,
        "nReturned": 100,
        "executionTimeMillis": 137,
        "totalKeysExamined": 48918,
        "totalDocsExamined": 48918,
        "allPlansExecution": []
    },
    "ok": 1,
}
复制代码

nReturned 实际返回数据行数

executionTimeMillis 命令执行总时间,单位毫秒

totalKeysExamined 表示MongoDB 扫描了N个索引数据。 检查的键数与返回的文档数相匹配,这意味着mongod只需检查索引键即可返回结果。mongod不必扫描所有文档,只有N个匹配的文档被拉入内存。 这个查询结果是非常高效的。

totalDocsExamined 文档扫描数

这几个字段的值越小说明效率越好,最佳状态是 nReturned = totalKeysExamined = totalDocsExamined 如果相差很大,说明还有很大优化空间,当具体业务还要酌情分析。 查询优化器针对该query所返回的最优执行计划的详细内容(queryPlanne.winningPlan)

stage

COLLSCAN:全表扫描,这个情况是最糟糕的
IXSCAN:索引扫描
FETCH:根据索引去检索指定document
SHARD_MERGE:将各个分片返回数据进行merge
SORT:表明在内存中进行了排序
LIMIT:使用limit限制返回数
SKIP:使用skip进行跳过
IDHACK:针对_id进行查询
SHARDING_FILTER:通过mongos对分片数据进行查询
COUNT:利用db.coll.explain().count()之类进行count运算
COUNTSCAN: count不使用Index进行count时的stage返回
COUNT_SCAN: count使用了Index进行count时的stage返回
SUBPLA:未使用到索引的$or查询的stage返回
TEXT:使用全文索引进行查询时候的stage返回
PROJECTION:限定返回字段时候stage的返回
复制代码

我们不希望看到的(出现以下情况,就要注意了,问题可能就出现了)

COLLSCAN(全表扫描)
SORT但是没有相关的索引
超大的SKIP
SUBPLA在使用$or的时候没有命中索引
COUNTSCAN 执行count没有命中索引
复制代码

然后是我们看看一条普通查询实际执行顺序

db.user.find({age:13}).skip(100).limit(100).sort({createdAt:-1})
复制代码

图中可以看出,首先是IXSCAN索引扫描,最后是SKIP跳过数据进行过滤。

在executionStats每一个项都有nReturned 与 executionTimeMillisEstimate,这样我们可以由内向外查看整个查询执行情况,在哪一步出现执行慢的问题。

关于列转行文档设计模式

首先数据库索引并不是越多越好,在MongoDB单文档索引上限,集合中索引不能超过64个,一些知名大厂推荐不超过10个。

而在一个主表中,由于冗余文档设计,就会存在非常多信息需要增加索引,我们还是以社交登录为例子

常规设计

schema = {
…
        qq:{
            openId:String
        },
        wxapp:{
            openId:String,
        },
        weibo:{
            openId:String,
        }
…
}

// 每次增加新的登录类型,需要修改文档schema和增加索引
db.user.createIndex({qq.openId:1}) 
db.user.createIndex({wxapp.openId:1}) 
db.user.createIndex({weibo.openId:1}) 
复制代码

列转行设计

schema = {
…
 snsPlatforms:[{
    platform:String, // 登录平台
    openId:String, // 登录唯一标识符
 }]
}
// 此时无论是新增登录平台还是删除,都不需要变更索引设计,一个索引解决所有同类型问题
db.user.createIndex({snsPlatforms.openId:1,snsPlatforms.platform:1})
复制代码

提问:为什么openId要放在plaform前面呢?

这个小故事讲述了小李在遇到自身知识不能解决的问题,然后事情的处理思路与过程。每个人都有自己能力所不及的地方,那么这种情况要优先解决问题,或者降低事故的影响范围。

分类:
后端
标签: