震撼揭秘：線(xiàn)上MongoDB慢查詢(xún)終極優(yōu)化實(shí)戰(zhàn)解析
背景
研發(fā)反饋指出，線(xiàn)上某個(gè)頁(yè)面的響應(yīng)速度異常緩慢，達(dá)到了16秒，嚴(yán)重影響了業(yè)務(wù)的正常運(yùn)行。經(jīng)過(guò)與研發(fā)的溝通得知，該頁(yè)面調(diào)用的數(shù)據(jù)集合只會(huì)保留7天的數(shù)據(jù)，集合有6000萬(wàn)條記錄。針對(duì)過(guò)期數(shù)據(jù)的處理，使用了根據(jù) create_time 字段創(chuàng)建的過(guò)期索引，以自動(dòng)使數(shù)據(jù)失效。此外，數(shù)據(jù)集合還通過(guò) company_id 字段進(jìn)行了哈希分片。
問(wèn)題排查
慢語(yǔ)句分析
在后臺(tái)拿到了慢查詢(xún)語(yǔ)句，如下：
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")
}
});很簡(jiǎn)單的一個(gè)查詢(xún)，語(yǔ)句上沒(méi)有再優(yōu)化的必要了，如果索引都在不應(yīng)該出現(xiàn)這種十多秒的耗時(shí)，接下來(lái)開(kāi)始分析索引。
索引分析
索引如下：
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：創(chuàng)建集合分片使用的hash索引
- company_id_1：普通查詢(xún)的索引
- create_time_1：過(guò)期時(shí)間的索引
根據(jù)研發(fā)團(tuán)隊(duì)的反饋和對(duì)數(shù)據(jù)的分析，我們發(fā)現(xiàn)當(dāng)前集合使用 company_id_hashed 索引進(jìn)行分片存在問(wèn)題。哈希索引對(duì)等值查詢(xún)最為友好，但對(duì)于范圍查詢(xún)支持不佳。由于 company_id 是公司維度字段，相同數(shù)據(jù)較多，因此使用哈希分片并不合適。建議直接創(chuàng)建 company_id 和 create_time 的聯(lián)合范圍分片鍵。這樣不僅能夠友好地支持范圍查詢(xún)，還能更細(xì)粒度地拆分?jǐn)?shù)據(jù)，提高查詢(xún)和寫(xiě)入的效率。
針對(duì)當(dāng)前情況就這點(diǎn)數(shù)據(jù)量，按理說(shuō)會(huì)用到索引的，不應(yīng)該執(zhí)行耗時(shí)16s，接下來(lái)執(zhí)行計(jì)劃分析。
Explain執(zhí)行計(jì)劃
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索引，沒(méi)有用到create_time_1索引。
"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": [ ]
},這部分顯示的是被拒絕的執(zhí)行計(jì)劃列表，不會(huì)用到company_id_1、create_time_1索引
"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")這部分顯示的是查詢(xún)的執(zhí)行統(tǒng)計(jì)信息。
索引分析
通過(guò)explain的執(zhí)行計(jì)劃，可以看到索引的使用上存在問(wèn)題，按理說(shuō)company_id、create_time都已創(chuàng)建索引，為什么沒(méi)有使用上？是什么使它失效，沒(méi)有用上create_time索引？
下面列舉了失效的情況：
- 索引選擇性不高：由于查詢(xún)條件是一個(gè)范圍查詢(xún)，create_time 字段可能有許多不同的值滿(mǎn)足條件。因此，單鍵索引 create_time_1 的選擇性（即索引中不同值的比例）可能不高，這使得使用該索引無(wú)法有效地減少需要檢索的文檔數(shù)量。
- 查詢(xún)需要跨越多個(gè)索引鍵值：查詢(xún)涉及到了兩個(gè)字段 company_id 和 create_time。雖然索引 create_time_1 可以幫助過(guò)濾 create_time 符合條件的文檔，但在執(zhí)行查詢(xún)時(shí)，還需要考慮 company_id 的匹配條件。因此，MongoDB 需要在兩個(gè)索引之間進(jìn)行查找和合并，而不是簡(jiǎn)單地使用單個(gè)索引來(lái)解決查詢(xún)。
- 額外的查找和合并成本：在涉及多個(gè)條件的查詢(xún)中，MongoDB 會(huì)嘗試使用覆蓋索引（Covered Index）來(lái)盡可能地減少在磁盤(pán)上的文檔檢索。然而，在這種情況下，create_time_1 索引不能單獨(dú)滿(mǎn)足查詢(xún)條件，因此 MongoDB 還需要查找和合并從 company_id_1 索引中過(guò)濾出來(lái)的文檔。這種額外的查找和合并過(guò)程會(huì)增加查詢(xún)的成本，并且降低性能。
問(wèn)題原因
首先，集合片鍵選擇錯(cuò)誤是問(wèn)題的根本原因。由于集合的分片鍵是 company_id_hashed，查詢(xún)必然會(huì)使用這個(gè)索引。然而，這引發(fā)了一系列連鎖反應(yīng)：即“查詢(xún)需要跨越多個(gè)索引鍵值”和“額外的查找和合并成本”。
具體來(lái)說(shuō)，由于需要進(jìn)行范圍查詢(xún)，首先會(huì)使用 company_id_hashed 索引。然而，MongoDB 還需要查找和合并從 company_id_1 索引中過(guò)濾出來(lái)的文檔。這種額外的查找和合并過(guò)程會(huì)增加查詢(xún)的成本，并且降低性能。這也導(dǎo)致了 create_time_1 索引無(wú)法被有效利用。
針對(duì)此問(wèn)題，我們將已有索引進(jìn)行了整改，如下：
分片鍵不重做（達(dá)到毫秒級(jí)別）
//分片鍵不做修整
db.getCollection("visitor").createIndex({
"company_id": "hashed"
}, {
name: "company_id_hashed"
});
//添加范圍聯(lián)合索引
db.getCollection("js_visitor").createIndex({
"company_id": NumberInt("1"),
"create_time": NumberInt("1")
}, {
name: "company_id_create_time"
});
//過(guò)期索引保留
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"
});分片鍵重做（最完美方案，但需要重新創(chuàng)建集合并遷移數(shù)據(jù)）
//分片鍵重做
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"
});
//過(guò)期索引保留
db.getCollection("visitor").createIndex({
"create_time": NumberInt("1")
}, {
name: "create_time_1",
expireAfterSeconds: NumberInt("604800")
});注意事項(xiàng)
1、選擇合適的分片鍵
- 分片鍵應(yīng)盡量均勻分布，以避免“熱點(diǎn)”問(wèn)題（即大多數(shù)查詢(xún)集中在某些特定分片上，導(dǎo)致這些分片負(fù)載過(guò)重）。
- 常用的選擇包括用戶(hù)ID、時(shí)間戳等具有自然分布特性的字段。
2、查詢(xún)模式
- 考慮主要的查詢(xún)模式，選擇的分片鍵應(yīng)當(dāng)能夠最大化地利用分片查詢(xún)。例如，如果大部分查詢(xún)都是基于用戶(hù)ID的，那么用戶(hù)ID就是一個(gè)合適的分片鍵。
3、寫(xiě)操作分布
- 分片鍵應(yīng)盡量避免集中寫(xiě)入。例如，使用時(shí)間戳作為分片鍵可能導(dǎo)致最新的分片上寫(xiě)入壓力過(guò)大。
4、更改分片鍵
- 分片鍵在集合創(chuàng)建后無(wú)法更改，因此在設(shè)計(jì)時(shí)需要慎重選擇。如果需要更改分片鍵，通常需要重新創(chuàng)建集合并遷移數(shù)據(jù)。
5、復(fù)合分片鍵
- 可以使用多個(gè)字段組合成復(fù)合分片鍵，以滿(mǎn)足更復(fù)雜的查詢(xún)需求。例如，使用 { userId: 1, timestamp: 1 } 作為分片鍵，可以?xún)?yōu)化基于用戶(hù)ID和時(shí)間戳的查詢(xún)。
6、哈希分片鍵
- 哈希分片鍵可以將數(shù)據(jù)均勻地分布到所有分片中，適合高并發(fā)的寫(xiě)入場(chǎng)景。例如，使用 { _id: "hashed" } 作為分片鍵。
總結(jié)
選擇合適的分片鍵是MongoDB分片設(shè)計(jì)中的重要步驟。分片鍵的選擇需要考慮數(shù)據(jù)的分布、查詢(xún)模式和寫(xiě)操作分布等因素。理解分片鍵的約束和注意事項(xiàng)，可以幫助我們?cè)O(shè)計(jì)高效、可擴(kuò)展的分布式數(shù)據(jù)庫(kù)架構(gòu)。
