震撼揭秘:线上MongoDB慢查询终极优化实战解析

2024年 5月 30日 57.4k 0

背景

研发反馈指出,线上某个页面的响应速度异常缓慢,达到了16秒,严重影响了业务的正常运行。经过与研发的沟通得知,该页面调用的数据集合只会保留7天的数据,集合有6000万条记录。针对过期数据的处理,使用了根据 create_time 字段创建的过期索引,以自动使数据失效。此外,数据集合还通过 company_id 字段进行了哈希分片。

问题排查

慢语句分析

在后台拿到了慢查询语句,如下:

db.visitor.find({
"company_id": 13272,
"create_time": {
"$gte": ISODate("2024-04-11T00:00:00.000+0800"),
"$lte": ISODate("2024-04-11T23:59:59.000+0800")
}
});


db.visitor.find({
"company_id": 13272,
"create_time": {
"$gte": ISODate("2024-04-12T00:00:00.000+0800"),
"$lte": ISODate("2024-04-18T23:59:59.000+0800")
}
});

很简单的一个查询,语句上没有再优化的必要了,如果索引都在不应该出现这种十多秒的耗时,接下来开始分析索引。

索引分析

索引如下:
db.getCollection("visitor").createIndex({
"company_id": "hashed"
}, {
name: "company_id_hashed"
});
db.getCollection("visitor").createIndex({
"company_id": NumberInt("1")
}, {
name: "company_id_1"
});
db.getCollection("visitor").createIndex({
"create_time": NumberInt("1")
}, {
name: "create_time_1",
expireAfterSeconds: NumberInt("604800")
});
  • company_id_hashed:创建集合分片使用的hash索引
  • company_id_1:普通查询的索引
  • create_time_1:过期时间的索引

根据研发团队的反馈和对数据的分析,我们发现当前集合使用 company_id_hashed 索引进行分片存在问题。哈希索引对等值查询最为友好,但对于范围查询支持不佳。由于 company_id 是公司维度字段,相同数据较多,因此使用哈希分片并不合适。建议直接创建 company_id 和 create_time 的联合范围分片键。这样不仅能够友好地支持范围查询,还能更细粒度地拆分数据,提高查询和写入的效率。

针对当前情况就这点数据量,按理说会用到索引的,不应该执行耗时16s,接下来执行计划分析。

Explain执行计划

winningPlan

"inputStage": {
                            "stage": "FETCH",
                            "filter": {
                                "$and": [
                                    {
                                        "company_id": {
                                            "$eq": 13272
                                        }
                                    },
                                    {
                                        "create_time": {
                                            "$lte": ISODate("2024-04-17T15:59:59.000Z")
                                        }
                                    },
                                    {
                                        "create_time": {
                                            "$gte": ISODate("2024-04-10T16:00:00.000Z")
                                        }
                                    }
                                ]
                            },
                            "inputStage": {
                                "stage": "IXSCAN",
                                "keyPattern": {
                                    "company_id": "hashed"
                                },
                                "indexName": "company_id_hashed",
                                "isMultiKey": false,
                                "isUnique": false,
                                "isSparse": false,
                                "isPartial": false,
                                "indexVersion": NumberInt("2"),
                                "direction": "forward",
                                "indexBounds": {
                                    "company_id": [
                                        "[7977521071453068053, 7977521071453068053]"

这部分显示只用到了company_id_hashed索引,没有用到create_time_1索引。

rejectedPlans

"stage": "SHARDING_FILTER",
"inputStage": {
"stage": "FETCH",
"filter": {
"company_id": {
"$eq": 13272
}
},
"inputStage": {
"stage": "IXSCAN",
"keyPattern": {
"create_time": 1
},
"indexName": "create_time_1",
"isMultiKey": false,
"multiKeyPaths": {
"create_time": [ ]
},
"isUnique": false,
"isSparse": false,
"isPartial": false,
"indexVersion": NumberInt("2"),
"direction": "forward",
"indexBounds": {
"create_time": [
"[new Date(1712764800000), new Date(1713369599000)]"
]
}
}
}
},
{
"stage": "SHARDING_FILTER",
"inputStage": {
"stage": "FETCH",
"filter": {
"$and": [
{
"create_time": {
"$lte": ISODate("2024-04-17T15:59:59.000Z")
}
},
{
"create_time": {
"$gte": ISODate("2024-04-10T16:00:00.000Z")
}
}
]
},
"inputStage": {
"stage": "IXSCAN",
"keyPattern": {
"company_id": 1
},
"indexName": "company_id_1",
"isMultiKey": false,
"multiKeyPaths": {
"company_id": [ ]
},

这部分显示的是被拒绝的执行计划列表,不会用到company_id_1、create_time_1索引

executionStats

"nReturned": NumberInt("229707"),
"executionTimeMillis": NumberInt("15668"),
"totalKeysExamined": NumberInt("238012"),
"totalDocsExamined": NumberInt("238012"),
"executionStages": {
"stage": "SINGLE_SHARD",
"nReturned": NumberInt("229707"),
"executionTimeMillis": NumberInt("15668"),
"totalKeysExamined": NumberInt("238012"),
"totalDocsExamined": NumberInt("238012"),
"totalChildMillis": NumberLong("15667"),
"shards": [
{
"shardName": "d-m5eee03fdeaeaee4",
"executionSuccess": true,
"executionStages": {
"stage": "SHARDING_FILTER",
"nReturned": NumberInt("229707"),
"executionTimeMillisEstimate": NumberInt("14996"),
"works": NumberInt("238013"),
"advanced": NumberInt("229707"),
"needTime": NumberInt("8305"),
"needYield": NumberInt("0"),
"saveState": NumberInt("1980"),
"restoreState": NumberInt("1980"),
"isEOF": NumberInt("1"),
"chunkSkips": NumberInt("0"),
"inputStage": {
"stage": "FETCH",
"filter": {
"$and": [
{
"company_id": {
"$eq": 13272
}
},
{
"create_time": {
"$lte": ISODate("2024-04-17T15:59:59.000Z")
}
},
{
"create_time": {
"$gte": ISODate("2024-04-10T16:00:00.000Z")
}
}
]
},
"nReturned": NumberInt("229707"),
"executionTimeMillisEstimate": NumberInt("14595"),
"works": NumberInt("238013"),
"advanced": NumberInt("229707"),
"needTime": NumberInt("8305"),
"needYield": NumberInt("0"),
"saveState": NumberInt("1980"),
"restoreState": NumberInt("1980"),
"isEOF": NumberInt("1"),
"docsExamined": NumberInt("238012"),
"alreadyHasObj": NumberInt("0"),
"inputStage": {
"stage": "IXSCAN",
"nReturned": NumberInt("238012"),
"executionTimeMillisEstimate": NumberInt("251"),
"works": NumberInt("238013"),
"advanced": NumberInt("238012"),
"needTime": NumberInt("0"),
"needYield": NumberInt("0"),
"saveState": NumberInt("1980"),
"restoreState": NumberInt("1980"),
"isEOF": NumberInt("1"),
"keyPattern": {
"company_id": "hashed"
},
"indexName": "company_id_hashed",
"isMultiKey": false,
"isUnique": false,
"isSparse": false,
"isPartial": false,
"indexVersion": NumberInt("2"),
"direction": "forward",
"indexBounds": {
"company_id": [
"[7977521071453068053, 7977521071453068053]"
]
},
"keysExamined": NumberInt("238012"),
"seeks": NumberInt("1"),
"dupsTested": NumberInt("0"),
"dupsDropped": NumberInt("0")

这部分显示的是查询的执行统计信息。

索引分析

通过explain的执行计划,可以看到索引的使用上存在问题,按理说company_id、create_time都已创建索引,为什么没有使用上?是什么使它失效,没有用上create_time索引?

下面列举了失效的情况:

  • 索引选择性不高:由于查询条件是一个范围查询,create_time 字段可能有许多不同的值满足条件。因此,单键索引 create_time_1 的选择性(即索引中不同值的比例)可能不高,这使得使用该索引无法有效地减少需要检索的文档数量。
  • 查询需要跨越多个索引键值:查询涉及到了两个字段 company_id 和 create_time。虽然索引 create_time_1 可以帮助过滤 create_time 符合条件的文档,但在执行查询时,还需要考虑 company_id 的匹配条件。因此,MongoDB 需要在两个索引之间进行查找和合并,而不是简单地使用单个索引来解决查询。
  • 额外的查找和合并成本:在涉及多个条件的查询中,MongoDB 会尝试使用覆盖索引(Covered Index)来尽可能地减少在磁盘上的文档检索。然而,在这种情况下,create_time_1 索引不能单独满足查询条件,因此 MongoDB 还需要查找和合并从 company_id_1 索引中过滤出来的文档。这种额外的查找和合并过程会增加查询的成本,并且降低性能。

问题原因

首先,集合片键选择错误是问题的根本原因。由于集合的分片键是 company_id_hashed,查询必然会使用这个索引。然而,这引发了一系列连锁反应:即“查询需要跨越多个索引键值”和“额外的查找和合并成本”。

具体来说,由于需要进行范围查询,首先会使用 company_id_hashed 索引。然而,MongoDB 还需要查找和合并从 company_id_1 索引中过滤出来的文档。这种额外的查找和合并过程会增加查询的成本,并且降低性能。这也导致了 create_time_1 索引无法被有效利用。

针对此问题,我们将已有索引进行了整改,如下:

分片键不重做(达到毫秒级别)

//分片键不做修整
db.getCollection("visitor").createIndex({
"company_id": "hashed"
}, {
name: "company_id_hashed"
});


//添加范围联合索引
db.getCollection("js_visitor").createIndex({
    "company_id": NumberInt("1"),
    "create_time": NumberInt("1")
}, {
    name: "company_id_create_time"
});


//过期索引保留
db.getCollection("visitor").createIndex({
"create_time": NumberInt("1")
}, {
name: "create_time_1",
expireAfterSeconds: NumberInt("604800")
});


//删掉company_id
db.getCollection("visitor").createIndex({
"company_id": NumberInt("1")
}, {
name: "company_id_1"
});

分片键重做(最完美方案,但需要重新创建集合并迁移数据)

//分片键重做
sh.shardCollection("cmdb.visitor",{ "company_id": "1","create_time": "1"});


索引如下:
db.getCollection("js_visitor").createIndex({
    "company_id": NumberInt("1"),
    "create_time": NumberInt("1")
}, {
    name: "company_id_create_time"
});


//过期索引保留
db.getCollection("visitor").createIndex({
"create_time": NumberInt("1")
}, {
name: "create_time_1",
expireAfterSeconds: NumberInt("604800")
});

注意事项

1、选择合适的分片键

  • 分片键应尽量均匀分布,以避免“热点”问题(即大多数查询集中在某些特定分片上,导致这些分片负载过重)。
  • 常用的选择包括用户ID、时间戳等具有自然分布特性的字段。

2、查询模式

  • 考虑主要的查询模式,选择的分片键应当能够最大化地利用分片查询。例如,如果大部分查询都是基于用户ID的,那么用户ID就是一个合适的分片键。

3、写操作分布

  • 分片键应尽量避免集中写入。例如,使用时间戳作为分片键可能导致最新的分片上写入压力过大。

4、更改分片键

  • 分片键在集合创建后无法更改,因此在设计时需要慎重选择。如果需要更改分片键,通常需要重新创建集合并迁移数据。

5、复合分片键

  • 可以使用多个字段组合成复合分片键,以满足更复杂的查询需求。例如,使用 { userId: 1, timestamp: 1 } 作为分片键,可以优化基于用户ID和时间戳的查询。

6、哈希分片键

  • 哈希分片键可以将数据均匀地分布到所有分片中,适合高并发的写入场景。例如,使用 { _id: "hashed" } 作为分片键。

总结

选择合适的分片键是MongoDB分片设计中的重要步骤。分片键的选择需要考虑数据的分布、查询模式和写操作分布等因素。理解分片键的约束和注意事项,可以帮助我们设计高效、可扩展的分布式数据库架构。

相关文章

Oracle如何使用授予和撤销权限的语法和示例
Awesome Project: 探索 MatrixOrigin 云原生分布式数据库
下载丨66页PDF,云和恩墨技术通讯(2024年7月刊)
社区版oceanbase安装
Oracle 导出CSV工具-sqluldr2
ETL数据集成丨快速将MySQL数据迁移至Doris数据库

发布评论