機器學習是否會使資料庫管理系統的維運人員失業？

導讀	資料庫管理系統（DBMS）是任何資料密集型應用系統中最重要的部分。它們可以處理大量的資料和複雜的工作負載。但由於它們有成百上千個配置「按鈕」（knob），這些配置按鈕控制著許多因素，例如用於快取的記憶體容量和資料寫入到儲存設備的頻次，因而管理起來很難。企業組織常常聘請專家幫忙調校活動，不過對許多企業來說專家的成本高得離譜。

本文是由卡內基·梅隆大學的三位嘉賓達娜·範·阿肯（Dana Van Aken）、安迪·帕夫洛（Andy Pavlo）和傑夫·戈登（Geoff Gordon）共同撰寫的文章。該計畫展示了學術研究人員如何可以使用AWS Cloud Credits for Research Program（https://aws.amazon.com/research-credits/）來支持其科學研究突破。

OtterTune是由卡內基·梅隆大學資料庫小組（http://db.cs.cmu.edu/projects/autotune/）的學生和研究人員開發的一種新工具，它能自動為DBMS的配置按鈕找到合適的設定。目的在於讓任何人都更容易部署DBMS，甚至是資料庫管理方面毫無專長的人。

OtterTune有別於其他的DBMS配置工具，原因在於它充分利用從調優之前部署的DBMS所獲得的知識來調優新部署的DBMS。這大大減少了調優新部署的DBMS所需的時間和資源。為此，OtterTune維護一個資料庫，包含從先前的調優會話收集而來的調優資料。它使用該數據來建立機器學習模型，這些模型採集了DBMS對不同配置作出反應的資訊。 OtterTune使用這些模型來引導使用者針對新的應用程式進行嘗試，建議使用改善特定目標（例如縮短延遲或提高吞吐量）的設定。

我們在本文中探討了OtterTune的機器學習管道的每個組件，並演示了它們彼此如何联系，從而調優DBMS的配置。之後，我們評估了OtterTune對MySQL和Postgres的調優效果：將其最佳配置的效能與資料庫管理員（DBA）及其他自動調優工具選擇的配置作了一番比較。

OtterTune是由卡內基·梅隆大學資料庫小組的學生和研究人員開發的開源工具。所有程式碼都放在GitHub上（https://github.com/cmu-db/ottertune），並採用了Apache License 2.0這種授權來發行。

工作原理

下面這張圖顯示了OtterTune的元件及工作流程。

#在新的調優會話的開始階段，使用者告訴OtterTune優化哪個特定目標（例如延遲或吞吐量）。用戶端控制器連接至目標DBMS，並收集Amazon EC2執行個體類型和目前目標。

然後，控制器開始了第一個觀察期，在此期間它觀察DBMS，並記錄特定目標。觀察期結束後，控制器收集來自DBMS的內部度量指標，例如MySQL針對從磁碟讀取的頁面和寫入到磁碟的頁面的計數。控制器將特定目標和內部度量指標都傳回給調優管理器。

OtterTune的調優管理器收到度量指標後，將它們儲存在資料庫中。 OtterTune使用結果來計算控制器應安裝到目標DBMS上的下一個配置。調優管理器將該配置傳回控制器，並透過實際運行來估計預期的改進。使用者可以決定繼續調優會話，還是終結調優會話。

說明

OtterTune為它支援的每個DBMS版本維護一份按鈕黑名單。此黑名單包含沒必要調優的按鈕（例如DBMS儲存檔案的路徑名稱），或可能有嚴重後果或隱性後果的按鈕（例如可能會造成DBMS遺失資料）。在每次調優會話的開始階段，OtterTune都會提供使用者黑名單，讓使用者可以新增他們想要OtterTune避免調優的其他任何按鈕。

OtterTune作出某些假設，可能會限制其對某些使用者而言的用處。比如說，它假設使用者擁有管理員權限，讓控制器可以修改DBMS的設定。如果使用者沒有管理員權限，那麼他們可以將資料庫的第二個副本部署到其他硬體上，以便OtterTune的調優試驗。這要求用戶重播工作負載跟踪，或轉發來自生產級DBMS的查詢。想了解假設和限制方面的完整討論，請參閱我們的論文（http://db.cs.cmu.edu/papers/2017/tuning-sigmod2017.pdf）。

機器學習管道

下面這張圖顯示了資料在透過OtterTune的機器學習管道傳輸時如何加以處理。所有觀察結果都放在OtterTune的資料庫中。

OtterTune先把觀察結果傳送到Workload Characterization元件。此組件可辨識一小批最準確地採集效能變化和不同工作負載獨特特點的DBMS度量指標。

接下來，Knob Identification元件產生一份按鈕排序表，列出了對DBMS的效能影響最大的按鈕。然後，OtterTune將所有這些資訊饋送給Automatic Tuner。此元件將目標DBMS的工作負載與資料資料庫中最相似的工作負載對應起來，並重複使用該工作負載數據，產生更合適的配置。

現在不妨深入探討機器學習管道中的每一個元件。

Workload Characterization：OtterTune使用DBMS的內部執行時間度量指標來描述工作負載的行為特性。這些度量指標準確地表達了工作負載，因為它們採集了運行時行為的許多方面。然而，許多度量指標是冗餘的：有些是以不同單位記錄的同一個度量值，有些則表示DBMS中數值高度關聯的獨立部分。精簡冗餘的度量指標很重要，因為這降低了使用它們的機器學習模型的複雜性。為此，我們基於關聯模式，將DBMS的測量指標分成聚類（cluster）。然後，我們從每個聚類中選擇一個代表性度量指標，具體來說是最靠近聚類中心的那個度量指標。機器學習管道中的後續組件使用這些度量指標。

Knob Identification：DBMS可能有數百個按鈕，但只有一小批按鈕會影響DBMS的效能。 OtterTune使用一種流行的特徵選擇技術（名為Lasso），決定哪些按鈕顯著影響系統的整體效能。透過將此技術運用於資料庫中的數據，OtterTune可識別DBMS的按鈕重要性次序。

隨後，OtterTune得決定在建議配置時要使用多少個按鈕。使用太多的按鈕大大增加了OtterTune的最佳化時間。使用太少的按鈕又讓OtterTune無法找到最佳設定。為了使這個過程自動化，OtterTune使用了一種增量方法。它逐步增加用於調優會話中的按鈕數量。這種方法讓OtterTune得以為一小批最重要的按鈕探究和優化配置，然後擴大範圍、考慮其他按鈕。

Automatic Tuner：Automated Tuning元件透過在每個觀察期之後執行分兩步驟的分析，決定OtterTune應該建議使用哪個配置。

首先，系統使用針對Workload Characterization元件中識別的度量指標的效能數據，從最能表示目標DBMS工作負載的先前調優會話識別工作負載。它將會話的測量指標與來自先前工作負載的測量指標進行比較，看看哪些對不同的按鈕設定有類似的反應。

然後，OtterTune選擇另一個按鈕配置來試試看。它使統計模型適合已收集的數據，以及來自資料庫中最相似的工作負載的數據。此模型讓OtterTune可以預測DBMS使用每一種可能的配置會有怎樣的效能。 OtterTune優化下一個配置，在探索（收集資訊以改善模型）和利用（盡可能在特定度量指標方面表現不俗）之間求得平衡。

實作

OtterTune是用Python寫的。

就Workload Characterization和Knob Identification這兩個元件而言，執行階段效能並不是擔心的主要問題，於是我們用scikit-learn實作了對應的機器學習演算法。這些演算法在後台進程中運行，一旦OtterTune的資料庫中有了新的數據，就會整合新數據。

至於Automatic Tuner，機器學習演算法位於關鍵路徑上。它們在每次觀察期後運行，整合新數據，這樣OtterTune可以選擇一個按鈕配置接下來嘗試。由於效能是個考慮因素，我們使用TensorFlow實作了這些演算法。

為了收集DBMS硬體方面的資料、按鈕配置和執行時間效能度量指標，我們將OtterTune的控制器與OLTP-Bench基準測試框架整合起來。

評估

為了評估，我們針對MySQL和Postgres的效能，將OtterTune選擇的最佳配置與下列配置進行了比較：

• 預設：DBMS提供的設定
• 調優腳本：開源調優顧問工具產生的設定
• DBA：資料庫管理員產生的設定
• RDS：為DBMS客​​製化的配置，由Amazon RD管理，部署在同樣類型的EC2實例上。

我們在Amazon EC2 Spot Instances（現貨實例）上進行了所有的試驗。我們在兩個實例上進行了每個試驗：一個實例用於OtterTune的控制器，另一個用於部署的目標DBMS系統。我們分別使用了m4.large和m3.xlarge實例類型。我們將OtterTune的調優管理器和資料資料庫部署在了搭載20個核心、128GB記憶體的本機伺服器上。

我們使用了TPC-C工作負載，這是評估線上事務處理（OLTP）系統效能的業界標準。

針對我們在試驗中使用的每個資料庫：MySQL和Postgres，我們測量了延遲和吞吐量。下面幾張圖顯示了結果。第一張圖顯示了第99個百分位延遲的數量，這表示「在最糟糕情況下」事務完成所花費的時間。第二張圖顯示了吞吐量的結果，以每秒完成的交易平均數量來測量。

 

MySQL的結果：

#將OtterTune產生的最佳配置與調優腳本和RDS產生的配置進行比較，就會發現：如果使用OtterTune配置，MySQL的延遲縮短了約60%，吞吐量提升了35%。 OtterTune也產生了結果與資料庫管理員選擇的配置一樣好的配置。

少數幾個MySQL的按鈕對TPC-C工作負載的效能有重大影響。 OtterTune和資料庫管理員產生的配置為這每一個按鈕提供了很好的設定。由於為一個按鈕提供了未達到最佳標準的設置，RDS的表現要遜色一點。由於只修改了一個按鈕，調優腳本的配置表現最差。

Postgres的結果：

#就延遲而言，OtterTune、調優工具、資料庫管理和RDS產生的配置都比Postgres的預設設定有了相似的改進。我們或許可以將此歸因於網路上OLTP-Bench的客戶機和DBMS之間的往返所需的開銷。至於吞吐量，如果使用OtterTune建議的配置，Postgres的效能比資料庫管理員和調優腳本選擇的配置高出了約12%，比RDS更是高出了約32%。

類似MySQL，只有少數幾個按鈕對Postgres的效能有重大影響。 OtterTune、資料庫管理員、調優腳本和RDS產生的配置都修改了這些按鈕，大多數提供了相當好的設定。

結束語

OtterTune使得為DBMS的配置按鈕找到合適的設定這個過程實現了自動化。為了調優新部署的DBMS，它重複使用從先前的調優會話收集而來的訓練資料。由於OtterTune不需要產生用於訓練機器學習模型的初始資料集，因而顯著縮短了調優時間。

接下來是什麼？為了適應部署的DBaaS越來越流行這個狀況（無法遠端存取DBMS的主機系統），OtterTune很快就能夠自動偵測目標DMBS的硬體功能，而不需要遠端存取。

想了解OtterTune方面的更多細節，請參考我們的論文或放在GitHub上的程式碼。請關注這個網站（http://ottertune.cs.cmu.edu/），我們很快就會推出OtterTune這項線上調優服務。
作者簡介：

達娜·範·阿肯（Dana Van Aken）是卡內基·梅隆大學的電腦學博士生，指導教授是安德魯·帕夫洛博士。

安迪·帕夫洛（Andy Pavlo）是卡內基·梅隆大學的電腦學系資料庫學助理教授。

傑夫·戈登（Geoff Gordon）是卡內基·梅隆大學的副教授兼機器學習系教育部副主任。

以上是機器學習是否會使資料庫管理系統的維運人員失業？的詳細內容。更多資訊請關注PHP中文網其他相關文章！