資料庫DBMS的「Self-Driving「之路

本文為Andrew Pavlo教授博客《What is a Self-Driving Database Management System?》的筆記。

筆者註：本文對DBMS的發展歷程進行了回顧，並對新一代Self-Driving DBMS提出了具體要求，是本領域中難得的一篇概述，非常值得認真讀一下。

自從Oracle在2017年的OpenWorld中宣布其下一代Oracle資料庫將是全球首個「self-driving」的資料庫開始，似乎機器學習與資料庫的關係才進入了大眾視野，而深度學習更是因為在其他領域的頻頻露臉而強行被綁定在智能資料庫的研究上。

本文主要來梳理一下資料庫在過去的幾十年中往「self-driving」這個目標所經歷的幾個階段。

自適應資料庫（1970s-1990s）

自1970年起，採用DBMS來降低開發人員的數據管理成本就是各種關係型模型或者聲明式語言的宣傳口號。在這個思路指導下，開發人員只需要根據所需要的數據編寫特定的查詢語句即可，而資料庫內部選擇何種演算法如何執行該語句，以及資料庫內對數據的存儲方式均對開發人員透明。資料庫自身來管理數據被訪問的方式。

與此同時，組織理想地希望一個DBMS為他們的應用程序選擇一個全局策略，處理管理和優化資料庫的全部。在1970年代，這種叫做自適應資料庫（self-adaptive）。從理論層面來講，這些系統運行的方式與現在的工具運行的本質是相同的，系統首先要收集應用讀取數據時的性能指標，然後基於代價模型來尋找一個最優策略來提升訪問性能。

然而，早期的自適應資料庫更側重於物理數據看的設計，尤其是索引選擇方面。例如，Michael Hammer教授的《Index Selection in A Self-Adaptive Data Base Management System》論文。同時，IBM、Berkeley、CMU等機構也都在對這方面進行研究，這個研究方向一直持續到了80年代，以IBM的DBDSGN為代表。

除了索引選擇這個研究方向，另外一個被廣泛研究的問題是資料庫分區問題。這時期的代表論文有《A Heuristic Approach to Attribute Partitioning》。直到90年代，資料庫自動分區和數據切分方法在分散式資料庫系統中變得比較普遍。Dewitter和IBM在這個領域也有代表論文。

自調優資料庫（1990s-2000s）

在90年代和2000年代又掀起了一波自調優資料庫的研究熱潮。其中以微軟的AutoAdmin最具代表性，該工具幫助DBA根據workload選擇優化索引、物化視圖和分區表。而AutoAdmin最主要的貢獻在於What-if API的發展。在它的幫助下，調優工具為潛在的設計決策(例如，添加一個索引)創建虛擬目錄條目，然後使用查詢優化器的代價模型來確定該決策的好處。這使得工具可以使用DBMS現有的代價模型來估算任意的索引組合，以獲得更好的索引策略。

在2000年代，自動化參數配置也有了初步研究。這些參數主要是允許DBA來控制DBMS運行時的狀態，例如BufferPool的大小。與物理設計工具的區別在於，參數配置工具無法利用內置的代價模型。這類工具是對執行特定查詢的工作量進行估計，並在同一個環境下比較不同查詢執行策略。

不同公司都有自己的調優工具，例如DB2的Performance Wizard與自調優內存工具，Oracle的性能瓶頸識別器和SQL analyzer tool 以及微軟的SQL Server。

然而上述工具依然需要一個手工過程：DBA提供一個workload的採樣，然後工具給出一些提升性能的建議，再由DBA決定是否應用這些優化建議。由於這類優化建議需要專家經驗，DB2提供了兩個自動化控制項LEarning Optimizer (LEO) 和 Self-Adaptive Set of Histograms (SASH)。它們的設計思想是：首先，DBMS的代價模型根據統計信息選擇查詢計劃並作出估計。然後，系統執行這條查詢並基於真實數據檢查這些估計指標是否符合預期。若不符合預期，系統將提供一個反饋建議給代價模型。儘管這個設計思想非常的正確並且看起來很屌，事實上DB2的DBA通常都是不使用這個功能，估計是實際效果並不理想。

雲資料庫（2010s早期）

隨著雲計算的崛起，在雲平台的規模與複雜性條件下，自治系統變得尤為重要。所有的雲服務商均提供定製化工具來控制部署。Azure利用內部遙測數據對DBMS容器資源使用情況進行建模，並自動調整分配以滿足QoS和預算約束。

雲平台上還提供黑盒的編排工具，便於修改集群中的機器數目。

理論上講，雲平台上有著無限的計算資源和存儲資源，DBMS可以任意的擴容或者縮容。未來DBMS的設計可能會側重於共享磁碟的架構設計。雲提供商將處於這一領域的最前沿，因為他們控制了整個堆棧。這意味著它們可以將DBMS特定的邏輯推入到網路層中，並在存儲層中向下運行，從而使那些簡單地在其平台內部運行的供應商無法做到這一點。

自動駕駛的資料庫（2010s晚期）

自動駕駛是一個非常熱門的研究領域。與此同時，這個詞也被用於各個領域。在資料庫領域的自動駕駛需要滿足以下幾個條件：

1. 具備自動選擇操作以提升某個目標（如吞吐量、延遲等）的能力，包括使用多少資源以應用這個操作。
2. 具備自動決定何時應用這個操作的能力。
3. 具備自動學習該操作的反饋並優化決策過程的能力。

這裡的操作主要是包括如下三類：

1. 修改資料庫的物理設計（例如，增加或者刪除索引）
2. 修改DBMS的控制參數（例如，調整BufferPool大小）
3. 修改DBMS的物理資源（例如，增加或者刪除集群中的機器）

對於第一個條件，已經有一些研究工作來解決這個問題，然而很少有嘗試解決第二個問題的研究。因為系統必須根據workload來決定這些操作在何時被執行，而系統需要預測在未來時間中workload的特點。

在一個動態變化的場景中預測workload是非常困難的事情。因為workload可能會隨著時間、日期、月份而變化，而查詢的資源使用情況又與資料庫的物理設計密切相關。在這方面的研究較少，目前只有CMU2018年發布的論文《Query-based Workload Forecasting for Self-Driving Database Management Systems》。

從前面介紹的幾個階段來看，資料庫智能一直都在探索「自動駕駛」這個領域，受限於技術的發展，前期的資料庫智能還停留在自動化階段，而部分自優化的功能在實際應用的效果也不盡如人意。現在藉助深度神經網路的能力，能否真正實現智能資料庫，達到「自動駕駛」呢？一起拭目以待吧。

延伸閱讀

What is a Self-Driving Database Management System??

www.cs.cmu.edu阿里在資料庫智能優化路上，做了哪些探索與實踐？-博客-雲棲社區-阿里雲?

yq.aliyun.com使用 Azure SQL 資料庫 Intelligent Insights 監視資料庫使用情況?

docs.microsoft.com
推薦閱讀：