MongoDB 謹防索引seek的效率問題

来源:https://www.cnblogs.com/littleatp/archive/2019/11/10/11832096.html
-Advertisement-
Play Games

[TOC] 聲明：本文同步發表於 MongoDB 中文社區，傳送門： "http://www.mongoing.com/archives/27310" 背景 最近線上的一個工單分析服務一直不大穩定，監控平臺時不時發出資料庫操作超時的告警。 運維兄弟溝通後，發現在每天凌晨1點都會出現若幹次的業務操作失 ...


目錄

聲明：本文同步發表於 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條記錄，查詢速度是非常快的！

小結

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


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • nginx+uWSGI+django+virtualenv+supervisor發佈web伺服器
    導論 WSGI是Web伺服器網關介面。它是一個規範，描述了Web伺服器如何與Web應用程式通信，以及Web應用程式如何鏈接在一起以處理一個請求，（接收請求，處理請求，響應請求） 基於wsgi運行的框架有bottle,DJango,Flask,用於解析動態HTTP請求 支持WSGI的伺服器 wsgir ...
  • xshell 遠程登陸CentOS7 免密登陸
    首先說一下大體的思路： 1. 以密碼登陸CentOS系統 2. 配置ssh 3. xshell 生成秘鑰 4. 進行免密登陸 軟體、設備： xshell(下載地址(免費版)，也可以自行百度下載) CentOS7.5 （百度雲伺服器） 接下來言歸正傳： 1. 密碼遠程連接CentOS 打開xshell ...
  • z390 m.2 介面插上sata 硬碟後，機械硬碟不識別；HDD 硬碟不識別；z390 m.2和 SATA 硬碟安裝組合；
    今天，在集成z390晶元組的主板上，安裝了一塊m.2支持 sata協議的ssd時，發現安裝上ssd後，之前機械硬碟不識別了；還以為機械硬碟燒了； 在網上查找相關博客可以發現，是M.2 SATA 和 SATA5,6 介面 共用通道的原因；換到1,2,3或4,通道就可以了；具體的依據，簡單記錄如下； 上 ...
  • Linux下修改文件許可權,所有權
    Linux與Unix是多用戶操作系統，所以文件的許可權與所有權的實現就顯得很有必要；每個文件主要與三組許可權打交道，分別是用戶(user)，用戶組(group)，其他用戶(other) 用戶(u)是文件的所有者，通常有所有的文件的操作許可權 用戶組(g)是多個用戶的集合，可能有文件的部分訪問權，相當於各用 ...
  • vi 上下左右變ABCD亂碼解決方法
    CentOS debian ...
  • Linux配置SSH和Xshell連接伺服器
    >>>>>Ubuntu安裝和配置ssh教程 SSH分為客戶端 openssh-client 和伺服器 openssh-server，可以利用以下命令確認電腦 上是否安裝了客戶端和伺服器。如果只是想遠程登陸別的機器只需要安裝客戶端 （Ubuntu預設安裝了客戶端），如果要本機的SSH服務就需要安裝服務 ...
  • 服務狀態控制
    systemctl restart 服務名 重啟服務 systemctl start 服務名 啟動服務 systemctl stop 服務名 關閉服務 systemctl reload 服務名 更新服務參數 systemctl enable 服務名 加入開機啟動 systemctl status 服 ...
  • centOS7安裝mysql8.0完美教程！！只要按照步驟，無腦操作，一次成功！
    查看防火牆systemctl status firewalld重啟防火牆systemctl start firewalld 1、mysql 首先關閉防火牆 systemctl stop firewalld 1.1 檢查系統是否已經安裝過mysql rpm -qa|grep mariadb 如果查詢到 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類