MongoDB 謹防索引seek的效率問題

目錄

• 背景
• 初步分析
• 索引seeks的緣由
• 優化思路
• 小結

聲明：本文同步發表於 MongoDB 中文社區，傳送門：
http://www.mongoing.com/archives/27310

背景

最近線上的一個工單分析服務一直不大穩定，監控平臺時不時發出數據庫操做超時的告警。
運維兄弟溝通後，發如今天天凌晨1點都會出現若干次的業務操做失敗，而數據庫監控上並無發現明顯的異常。
在該分析服務的日誌中發現了某個數據庫操做產生了 SocketTimeoutException。

開發同窗一開始但願經過調整 MongoDB Java Driver 的超時參數來規避這個問題。
但通過詳細分析以後，這樣是沒法根治問題的，並且超時配置應該如何調整也難以評估。

下面是關於對這個問題的分析、調優的過程。

初步分析

從出錯的信息上看，是數據庫的操做響應超時了，此時客戶端配置的 SocketReadTimeout 爲 60s。
那麼，是什麼操做會致使數據庫 60s 還沒能返回呢？

業務操做

左邊的數據庫是一個工單數據表(t_work_order)，其中記錄了每張工單的信息，包括工單編號(oid)、最後修改時間(lastModifiedTime)
分析服務是Java實現的一個應用程序，在天天凌晨1:00 會拉取出前一天修改的工單信息(要求按工單號排序)進行處理。
因爲工單表很是大(千萬級)，因此在處理時會採用分頁的作法(每次取1000條)，使用按工單號翻頁的方式：

• 第一次拉取

db.t_work_order.find({
   "lastModifiedTime":{
      $gt: new Date("2019-04-09T09:44:57.106Z"),
      $lt: new Date("2019-04-09T10:44:57.106Z")}, 
   "oid": {$exists: true}})
   .sort({"oid":1}).limit(1000)

• 第二次拉取，以第一次拉取的最後一條記錄的工單號做爲起點

db.t_work_order.find({
   "lastModifiedTime":{
      $gt: new Date("2019-04-09T09:44:57.106Z"),
      $lt: new Date("2019-04-09T10:44:57.106Z")}, 
   "oid": {$exists: true, $gt: "VXZ190"}})
   .sort({"oid":1}).limit(1000)

..

根據這樣的查詢，開發人員給數據表使用的索引以下：

db.t_work_order.ensureIndexes({
   "oid" : 1,
   "lastModifiedTime" : -1
})

儘管該索引與查詢字段基本是匹配的，但在實際執行時卻表現出很低的效率：
第一次拉取時間很是的長，常常超過60s致使報錯，然後面的拉取時間則會快一些

爲了精確的模擬該場景，咱們在測試環境中預置了小部分數據，對拉取記錄的SQL執行Explain:

db.t_work_order.find({
   "lastModifiedTime":{
      $gt: new Date("2019-04-09T09:44:57.106Z"),
      $lt: new Date("2019-04-09T10:44:57.106Z")}
   "oid": {$exists: true}})
   .sort({"oid":1}).limit(1000)
   .explain("executionStats")

輸出結果以下

"nReturned" : 1000,
"executionTimeMillis" : 589,
"totalKeysExamined" : 136661,
"totalDocsExamined" : 1000,

...

"indexBounds" : {
    "oid" : [ 
        "[MinKey, MaxKey]"
    ],
    "lastModifiedTime" : [ 
        "(new Date(1554806697106), new Date(1554803097106))"
    ]
},
"keysExamined" : 136661,
"seeks" : 135662,

在執行過程當中發現，檢索1000條記錄，竟然須要掃描 13.6 W條索引項！
其中，幾乎全部的開銷都花費在了 一個seeks操做上了。

索引seeks的緣由

官方文檔對於 seeks 的解釋以下：
The number of times that we had to seek the index cursor to a new position in order to complete the index scan.

翻譯過來就是：
seeks 是指爲了完成索引掃描(stage)，執行器必須將遊標定位到新位置的次數。

咱們都知道 MongoDB 的索引是B+樹的實現(3.x以上)，對於連續的葉子節點掃描來講是很是快的(只須要一次尋址)，那麼seeks操做太多則表示整個掃描過程當中出現了大量的尋址(跳過非目標節點)。
並且，這個seeks指標是在3.4版本支持的，所以能夠推測該操做對性能是存在影響的。

爲了探究 seeks 是怎麼產生的，咱們對查詢語句嘗試作了一些變動：

去掉 exists 條件

exists 條件的存在是由於歷史問題(一些舊記錄並不包含工單號的字段)，爲了檢查exists查詢是否爲關鍵問題，修改以下：

db.t_work_order.find({
   "lastModifiedTime":{
      $gt: new Date("2019-04-09T09:44:57.106Z"),
      $lt: new Date("2019-04-09T10:44:57.106Z")}
   })
   .sort({"oid":1}).limit(1000)
   .explain("executionStats")

執行後的結果爲：

"nReturned" : 1000,
"executionTimeMillis" : 1533,
"totalKeysExamined" : 272322,
"totalDocsExamined" : 272322,
  
...

"inputStage" : {
  "stage" : "FETCH",
  "filter" : {
      "$and" : [ 
          {
              "lastModifiedTime" : {
                  "$lt" : ISODate("2019-04-09T10:44:57.106Z")
              }
          }, 
          {
              "lastModifiedTime" : {
                  "$gt" : ISODate("2019-04-09T09:44:57.106Z")
              }
          }
      ]
}, 

...

"indexBounds" : {
    "oid" : [ 
        "[MinKey, MaxKey]"
    ],
    "lastModifiedTime" : [ 
        "[MaxKey, MinKey]"
    ]
},
"keysExamined" : 272322,
"seeks" : 1,

這裏發現，去掉 exists 以後，seeks 變成了1次，但整個查詢掃描了 27.2W 條索引項！ 恰好是去掉以前的2倍。
seeks 變爲1次說明已經使用了葉節點順序掃描的方式，然而因爲掃描範圍很是大，爲了找到目標記錄，會執行順序掃描並過濾大量不符合條件的記錄。
在 FETCH 階段出現了 filter可說明這一點。與此同時，咱們檢查了數據表的特徵：同一個工單號是存在兩條記錄的！因而能夠說明：

• 在存在exists查詢條件時，執行器會選擇按工單號進行seeks跳躍式檢索，以下圖：

• 在不存在exists條件的狀況下，執行器選擇了葉節點順序掃描的方式，以下圖：

gt 條件和反序

除了第一次查詢以外，咱們對後續的分頁查詢也進行了分析，以下：

db.t_work_order.find({
   "lastModifiedTime":{
      $gt: new Date("2019-04-09T09:44:57.106Z"),
      $lt: new Date("2019-04-09T10:44:57.106Z")}, 
   "oid": {$exists: true, $gt: "VXZ190"}})
   .sort({"oid":1}).limit(1000)
   .explain("executionStats")

上面的語句中，主要是增長了$gt: "VXZ190"這一個條件，執行過程以下：

"nReturned" : 1000,
"executionTimeMillis" : 6,
"totalKeysExamined" : 1004,
"totalDocsExamined" : 1000,

...

"indexBounds" : {
    "oid" : [ 
        "(\"VXZ190\", {})"
    ],
    "lastModifiedTime" : [ 
        "(new Date(1554806697106), new Date(1554803097106))"
    ]
},
"keysExamined" : 1004,
"seeks" : 5,

能夠發現，seeks的數量很是少，並且檢索過程只掃描了1004條記錄，效率是很高的。
那麼，是否是意味着在後面的數據中，知足查詢的條件的記錄很是密集呢？

爲了驗證這一點，咱們將一開始第一次分頁的查詢作一下調整，改成按工單號降序的方式(從後往前掃描):

db.t_work_order.find({
   "lastModifiedTime":{
      $gt: new Date("2019-04-09T09:44:57.106Z"),
      $lt: new Date("2019-04-09T10:44:57.106Z")}, 
   "oid": {$exists: true}})
   .sort({"oid":-1}).limit(1000)
   .explain("executionStats")

新的"反序查詢語句"的執行過程以下：

"nReturned" : 1000,
"executionTimeMillis" : 6,
"totalKeysExamined" : 1001,
"totalDocsExamined" : 1000,

...

"direction" : "backward",
"indexBounds" : {
    "oid" : [ 
        "[MaxKey, MinKey]"
    ],
    "lastModifiedTime" : [ 
        "(new Date(1554803097106), new Date(1554806697106))"
    ]
},
"keysExamined" : 1001,
"seeks" : 2,

能夠看到，執行的效率更高了，幾乎不須要什麼 seeks 操做！
通過一番確認後，咱們獲知了在全部數據的分佈中，工單號越大的記錄其更新時間值也越大，基本上咱們想查詢的目標數據都集中在尾端。

因而就會出現一開始提到的，第一次查詢很是慢甚至超時，然後面的查詢就快了。

上面提到的兩個查詢執行路線如圖所示：

• 加入$gt 條件，從中間開始檢索

• 反序，從後面開始檢索

優化思路

經過分析，咱們知道了問題的癥結在於索引的掃描範圍過大，那麼如何優化，以免掃描大量記錄呢？
從現有的索引及條件來看，因爲同時存在gt、exists以及葉子節點的時間範圍限定，不可避免的會產生seeks操做，
並且查詢的性能是不穩定的，跟數據分佈、具體查詢條件都有很大的關係。
因而一開始所提到的僅僅是增長 socketTimeout 的閾值可能只是治標不治本，一旦數據的索引值分佈變化或者數據量持續增大，可能會發生更嚴重的事情。

回到一開始的需求場景，定時器要求讀取天天更新的工單(按工單號排序)，再進行分批處理。
那麼，按照化零爲整的思路，新增一個lastModifiedDay字段，這個存儲的就是lastModifiedTime對應的日期值(低位取整)，這樣在同一天內更新的工單記錄都有一樣的值。

創建組合索引 {lastModifiedDay:1, oid:1}，相應的查詢條件改成：

{
  "lastModifiedDay": new Date("2019-04-09 00:00:00.000")，
  "oid": {$gt: "VXZ190"}
}  
-- limit 1000

執行結果以下：

"nReturned" : 1000,
"executionTimeMillis" : 6,
"totalKeysExamined" : 1000,
"totalDocsExamined" : 1000,

...

"indexBounds" : {
    "lastModifiedDay" : [ 
        "(new Date(1554803000000), new Date(1554803000000))"
    ],
    "oid" : [ 
        "(\"VXZ190\", {})"
    ]
},
"keysExamined" : 1000,
"seeks" : 1,

這樣優化以後，每次查詢最多隻掃描1000條記錄，查詢速度是很是快的！

小結

本質上，這就是一種空間換時間的方法，即經過存儲一個額外的索引字段來加速查詢，經過增長少許的存儲開銷提高了總體的效能。 在對於許多問題進行優化時，常常是須要從應用場景觸發，適當的轉換思路。 好比在本文的問題中，是否是必定要增長字段呢？若是業務上能夠接受不按工單號排序進行讀取，那麼僅使用更新時間字段進行分頁拉取也是能夠達到效果的，具體仍是要由業務場景來定。