成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

震撼揭秘：線上MongoDB慢查詢終極優化實戰解析

作者：DBA實戰
數據庫 其他數據庫
選擇合適的分片鍵是MongoDB分片設計中的重要步驟。分片鍵的選擇需要考慮數據的分布、查詢模式和寫操作分布等因素。理解分片鍵的約束和注意事項，可以幫助我們設計高效、可擴展的分布式數據庫架構。

背景

研發反饋指出，線上某個頁面的響應速度異常緩慢，達到了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分片設計中的重要步驟。分片鍵的選擇需要考慮數據的分布、查詢模式和寫操作分布等因素。理解分片鍵的約束和注意事項，可以幫助我們設計高效、可擴展的分布式數據庫架構。

責任編輯：武曉燕 來源： DBA實戰
MongoDB查詢模式數據庫
相關推薦

2024-04-29 08:00:00

MongoDB索引

2023-12-11 06:27:39

MySQL線上業務優化后臺上傳文件

2022-11-16 08:00:37

MongoDB阿里云的登錄

2023-12-08 13:23:00

大數據MySQL存儲

2022-04-22 14:41:12

美團慢查詢數據庫

2024-11-28 19:03:56

2012-12-11 09:48:55

廣域網網絡優化網絡加速

2012-09-20 10:13:04

MongoDB

2011-04-02 16:45:58

SQL Server查詢優化

2011-05-16 17:36:05

SEO

2017-07-11 15:50:11

前端webpack2優化

2017-05-23 16:26:26

MySQL優化處理

2012-10-08 11:18:05

JavaMVC項目

2020-08-28 08:55:32

商城系統高并發

2025-01-15 12:48:30

2011-07-07 14:15:35

WIFI無線

2025-06-25 09:30:14

2017-08-18 22:40:33

線上線程備份

2025-05-12 04:01:00

2023-09-01 15:34:34

數據庫開發
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板： 免费观看成人鲁鲁鲁鲁鲁视频 | 91在线精品一区二区 | 免费观看视频www | 亚洲入口 | 欧美精品一区二区三 | 91精品国产高清一区二区三区 | 黄色片在线观看网址 | 久久国产精品免费视频 | 波多野结衣在线观看一区二区三区 | 在线免费观看黄a | 亚洲一区中文字幕 | www.4虎影院| 国产成人av一区二区三区 | 国产91精品久久久久久久网曝门 | 日韩一区二区三区在线 | 亚洲欧美在线免费观看 | 亚洲3级| av国产精品毛片一区二区小说 | 欧美激情精品久久久久久 | 久久国产综合 | 日韩中出| 精品综合久久 | 日韩在线小视频 | 97超碰站| 欧美精品一区二区三区在线播放 | 欧美日韩亚洲一区 | 一二三四在线视频观看社区 | 国偷自产av一区二区三区 | 国产精品一区一区三区 | 亚洲成人免费视频在线 | 色秀网站 | 一区二区三区国产精品 | 日韩精品 | 一级国产精品一级国产精品片 | 精品免费国产一区二区三区四区介绍 | 中文在线a在线 | 国产精品日韩欧美一区二区三区 | 亚洲黄色高清视频 | 国产在线观看一区二区三区 | 四虎永久 | 欧美女优在线观看 |