從物理讀突增的複雜分析路徑談起

物理讀與邏輯讀的概念在很多資料庫中都存在，只不過針對PG這樣使用DOUBLE BUFFER的資料庫，物理讀與邏輯讀之間的開銷差異並不是特別容易評估。Oracle對二者的差異就很容易評估了，物理讀的平均IO延時在1-2毫秒左右，而邏輯讀的延時要低數個數量級。不管如何，物理讀的大小對於評估資料庫效能來說還是有一定的意義的，無論是Oracle或其他使用DOUBLE BUFFER策略的資料庫產品。一個有經驗的DBA能夠從物理讀指標的變化中看出一些資料庫存在的問題與隱患，在D-SMART中，也針對這個場景定義了故障模型，遇到物理讀突增的情況會自動產生報警，並且提供一個完整的專家診斷建議。

我們今天以Oracle資料庫為例，來探討一下這個問題，其他資料庫的診斷路徑有些類似，比Oracle略微簡單而已。引發此類問題的主要路徑有5條，每條主路徑上又會有幾條子路徑。因為圖不能太大，我把四級以上的路徑以及一部分三級路徑都做了裁剪。一般來說，遇到這種場景，應用出問題的可能性比較大。因此最可能出問題的路徑來自於物理讀較大的TOP SQL，這些SQL可能是以前沒有出現過，而突然出現的物理讀極高的SQL，有可能是以前物理讀不高，今天突然變高的SQL，這種情況很可能是執行計劃出現了變化(往往系統中存在多種執行計劃)，還有就是某條單次執行物理讀並不太高，但是執行次數較多的SQL的執行次數發生了巨大的增長。如果這些問題存在，那麼我們可以初步認為大機率情況是出現了應用的異常。但是哪怕這些問題真的存在，也並不一定說明根因就是應用的問題。因為DB CACHE、大事務異常、直接路徑讀異常等也可能是這個問題的根因。

透過這5條主路徑，幾十條三四級路徑的分析，我們大致可以找出存在問題的點，但是哪個是因，哪個是果，還需要進一步的分析。

其實針對這個問題，我前幾天針對日誌分析的問題，發過今天有個網友給我留言，對於AIOPS中的專家知識還是演算法方面提出了一些不同的看法。

我十分感謝這位朋友，只有經過不同觀點之間的碰撞，才能把問題考慮得更為清晰，看到留言後，我也思考了很久。從留言上看，這位朋友很可能也是從事資料庫行業的工作的，提出了資料庫應該朝AIOPS方向發展，產品更智慧化，更低TCO，實現彎道超車。這也是很多資料庫企業與客戶的期望。

我們目前遇到了一個知識障礙，以我目前對資料庫問題分析的複雜性的認知，找不到特別好的自動化的方法來解決複雜性和多樣性的問題。實際上Oracle提出自治資料庫的概念也有好多年了，只是目前能夠實現真正“自治”的能力也十分有限，Oracle的自治資料庫的基礎也是基於TIME MODEL這樣的以OWI為基礎的可觀測性介面的深度統計的，實際上裡面更多的還是對資料庫產品自身規則的認知體現，和AIOPS還差的很遠。

事實上目前我們的國產資料庫最主要的問題是在底層的引擎的技術上與Oracle還有代差，比如SQL引擎對複雜計算的支援還不夠好;運算元分解，下推，並行處理的演算法還比較簡單;最佳化器還無法為某些SQL提供最佳的執行計劃;SQL解析時還經常無法獲得最佳的執行計劃;儲存引擎還無法更好的支撐某些高開銷的計算;鎖和閂鎖的併發能力還不夠強;DB CACHE的訪問演算法還不夠最佳化;WAL的併發寫入演算法還不夠高效，等等等等。如果不把這些底層基礎打好，那麼加持再多的AIOPS演算法也是白搭的。

從另外一個角度上看，我們的資料庫核心開發人員哪怕水平再高，也不大可能瞭解客戶的各種應用場景，因此他們考慮問題的時候，或者在設計資料庫產品的功能的時候，往往只能從一些基礎的場景去考慮，因此在資料庫核心引擎中植入AIOPS演算法的難度也是相當大的，目前看到最多的還是在CBO最佳化器中引入一些AI的演算法。實際上AI演算法在CBO最佳化器中的引入最主要的場景還是多種執行計劃的選擇上，透過歷史執行情況進行建模，為後續的SQL執行提供輔助。這對於某些核心SQL上面有一定的效果，不過真正在客戶那邊被用的很好的真實案例目前還相當少，實際上這也只是解決了很少一部分問題。在複雜SQL的執行計劃選擇上，最容易出問題的是HASH JOIN和NESTED LOOP JOIN的選擇錯誤。針對這個問題，ORACLE 12C已經有了動態執行計劃的解決方案，只是目前還不夠成熟，經常出現誤判，導致更嚴重的問題，因此在大多數客戶的核心繫統中，都是關閉此功能的。PG 資料庫目前也有類似的外掛，也是因為成熟度的問題，使用甚少。

不過CBO中引入再多的AI演算法，如果CBO本身的能力不行，那也是白搭。這種需要簡單高效的引擎中，AI演算法大多數也只能是一些旁路的輔助功能，真正核心演算法，還是應該以簡要為主，基於規則是可控的，容易修正的，而基於AI演算法作為核心，也許目前的AI技術還不足以支撐吧。

實際上，目前我們國產資料庫最需要補的課是可觀測性的增強，我和很多資料庫核心研發人員討論過，想要了解他們的資料庫產品中某個指標或者某個等待事件代表的含義，以及在資料庫中影響的因素，幾乎沒有一個人說的清楚，哪怕對著程式碼，也僅僅能夠給出一些十分模糊的解釋。這是因為我們的國產資料庫產品連最基礎的TIME MODEL都沒有很好的構建起來，很多指標雖然統計了，但是某些指標的異常可能意味著什麼，或者和資料庫的哪個BUG有關，這些知識實際上都沒有建立起來。連資料庫廠商都解釋不清的事情，那客戶就用起來就更是一頭霧水了。

AIOPS是好東西，彎道超車也是大家所期望的，我以前也曾經提過，彎道超車有幾個條件，首先自己的車的速度比前車要快，最起碼也是差不多的;其次自己的駕駛技術要夠好，起碼比前車要好;第三是存在合適的彎道，比較適合超車;第四是賽車手的感覺要好，能夠捕捉到最佳的超車時機。當我們還被別人套著圈，人家的車速遠遠快於我們的時候，我們不考慮如何提高自己的駕駛技術和車子的基礎水平，就想著彎道超車，恐怕最後也只能是空想。

國產資料庫實現超車還是有可能的，在某些Oracle不擅長的領域實現超越和替代的例子已經很多了。而在主戰場上，想要超車，恐怕還是先要先把內功練好。因為有著全世界最豐富的資料庫應用場景，經過十幾二十年的磨練，這一天有可能會到來。