本客座文章由卡內基梅隆大學的 Dana Van Aken、Geoff Gordon 和 Andy Pavlo 釋出。本專案演示學術研究人員如何利用我們的 AWS Cloud Credits for Research Program 實現科學突破。點選：原文連結

資料庫管理系統 (DBMS) 是所有資料密集型應用程式最重要的組成部分。它們可以處理大量資料和複雜工作負載。但它們擁有成百上千的配置“開關”，控制了諸如用於快取的記憶體量以及將資料寫入儲存的頻率等諸多因素，因此管理起來很困難。組織通常會聘請專家來幫助完成優化活動，但對許多組織來說專家的費用過於高昂。

與其他 DBMS 配置工具不同，OtterTune 利用在優化之前的 DBMS 部署期間獲得的知識來優化新的部署。這可以顯著縮短優化新 DBMS 部署所需的時間以及減少所需的資源。為此，OtterTune 維護了一個儲存庫，用於儲存在之前的優化會話中收集的優化資料。它利用此類資料來構建機器學習 (ML) 模型，以捕獲 DBMS 對不同配置的響應方式。OtterTune 使用這些模型來指導新應用程式的試驗，進而推薦可改善最終目標 (例如，減少延遲或提高吞吐量) 的設定。

在本文中，我們將討論 OtterTune ML 管道中的每一個元件，並演示這些元件如何彼此互動以優化 DBMS 配置。然後，我們將通過比較 OtterTune 推薦的最佳配置與資料庫管理員 (DBA) 及其他自動優化工具選擇的配置的效能，評估 OtterTune 對 MySQL 和 Postgres 的優化效力。

OtterTune 是一款開源工具，由卡內基梅隆大學資料庫研究組的學生和研究人員開發。GitHub 上提供了所有程式碼，並且程式碼已獲得 Apache 2.0 許可。

OtterTune 工作原理

下圖顯示了 OtterTune 的元件和工作流。

在新的優化會話開始時，使用者須告知 OtterTune 要優化的最終目標 (例如，延遲或吞吐量)。客戶端控制器連線到目標 DBMS，並收集其 Amazon EC2 例項型別和當前配置。

然後，控制器開始第一個觀察期，觀察 DBMS 並記錄最終目標。該觀察期結束後，控制器收集 DBMS 中的內部指標，例如，MySQL 從磁碟讀取的頁數以及寫入磁碟的頁數。控制器向優化管理器返回最終目標和內部指標。

OtterTune 的優化管理器收到指標時，將指標儲存在儲存庫中。OtterTune 根據結果計算控制器應在目標 DBMS 上安裝的下一個配置。優化管理器向控制器返回此配置，並估計優化此配置能夠獲得的預期改進。使用者可以決定是繼續還是終止優化會話。

備註

OtterTune 維護其支援的各 DBMS 版本的開關黑名單。該黑名單中包含無優化意義的開關 (例如，DBMS 儲存檔案的路徑名稱)，或者可能導致嚴重或隱藏後果 (例如，可能導致 DBMS 丟失資料) 的開關。每個優化會話開始時，OtterTune 會向用戶提供該黑名單，讓使用者新增他們不希望 OtterTune 優化的任何其他開關。

OtterTune 做出了一些假設，這些假設可能會限制其對某些使用者的有用程度。例如，它假設使用者擁有管理許可權，允許控制器修改 DBMS 的配置。如果使用者不具備該許可權，則可以在其他硬體上部署另外一份資料庫，用於進行 OtterTune 優化試驗。這要求使用者重播工作負載跟蹤或轉發來自生產 DBMS 的查詢。有關假設和限制的完整討論，請參閱我們的文章。

機器學習管道

下圖顯示了在資料流過 OtterTune 的 ML 管道時如何得到處理。所有觀察結果都儲存在 OtterTune 的儲存庫中。

OtterTune 先將觀察結果傳入 Workload Characterization 元件。此元件確定能夠最準確地捕獲不同工作負載的效能差異和顯著特點的一小部分 DBMS 指標。

接下來，Knob Identification 元件生成對 DBMS 效能影響最大的開關的排序列表。OtterTune 隨後將所有此類資訊饋送到 Automatic Tuner。此元件將目標 DBMS 工作負載對映到其資料儲存庫中最相似的工作負載，並再次使用此工作負載資料生成更好的配置。

我們來詳細討論一下 ML 管道中的每個元件。

Workload Characterization： OtterTune 使用 DBMS 的內部執行時指標來確定工作負載行為方式的特徵。這些指標準確代表了工作負載，因為它們捕獲了其執行時行為的許多方面。不過，許多指標都是多餘的：一些指標其實是相同的，只是單位不同；還有一些指標表示 DBMS 的各獨立元件，但它們的值高度相關。必須清除多餘的指標，這可以降低使用這些指標的 ML 模型的複雜性。為此，我們基於 DBMS 指標的關聯模式將它們叢集化。然後，我們從每個叢集中選擇一個具有代表性的指標，具體而言就是最接近叢集中心的指標。ML 管道中的後續元件會使用這些指標。

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 來實現對應的 ML 演算法。這些演算法在後臺程序中執行，從而在 OtterTune 儲存庫中有新資料可用時納入這些資料。

而對於 Automatic Tuner，ML 演算法是關鍵。它們在每個觀察期之後執行，從而納入新資料，以便 OtterTune 能夠選取下一次嘗試的開關配置。由於要考慮效能，我們使用 TensorFlow 來實現這些演算法。

為了收集有關 DBMS 硬體、開關配置和執行時效能指標的資料，我們將 OtterTune 的控制器與 OLTP-Bench 基準測試框架整合在了一起。

試驗設計

為進行評估，我們比較了使用 OtterTune 選擇的最佳配置與使用以下配置的 MySQL 和 Postgres 的效能：

• 預設：DBMS 提供的配置
• 優化指令碼：開源優化顧問工具生成的配置
• DBA：DBA 選擇的配置
• RDS：由 Amazon RD 管理並部署在相同 EC2 例項型別上的 DBMS 的自定義配置

我們在 Amazon EC2 競價型例項上進行了所有試驗。我們在兩個例項上運行了每個試驗：一個針對 OtterTune 控制器，另一個針對目標 DBMS 部署。我們分別使用了 m4.large 和 m3.xlarge 例項型別。我們在配備 20 個核心和 128 GB RAM 的本地計算機上部署了 OtterTune 的優化管理器和資料儲存庫。

我們使用了 TPC-C 工作負載，它是評估聯機事務處理 (OLTP) 系統性能的行業標準。

評估

對於我們在試驗中使用的每個資料庫 (MySQL 和 Postgres)，我們測量了延遲和吞吐量。下圖顯示了結果。第一張圖顯示 99% 的延遲，表示最壞情況下完成事務的時間。第二張圖顯示吞吐量結果，以每秒完成的平均事務數衡量。

MySQL 結果

比較 OtterTune 生成的最佳配置與優化指令碼和 RDS 生成的配置後發現，使用 OtterTune 配置，MySQL 的延遲減少了大約 60%，吞吐量提高了 22%-35%。OtterTune 還生成了幾乎與 DBA 選擇的配置一樣出色的配置。

只有少數幾個 MySQL 開關顯著影響 TPC-C 工作負載的效能。OtterTune 和 DBA 生成的配置為每個這些開關提供了理想的設定。RDS 的表現稍差一些，因為它為一個開關提供了次優的設定。優化指令碼的配置效果最差，因為它只修改了一個開關。

Postgres 結果

在延遲方面，與 Postgres 的預設設定相比，優化工具 OtterTune、DBA 和 RDS 生成的配置全都獲得了類似的改善。我們或許可以把這些改善歸功於 OLTP-Bench 客戶端與 DBMS 之間的網路往返行程所需的開銷。在吞吐量方面，與 DBA 和優化指令碼選擇的配置相比，OtterTune 建議的配置使 Postgres 的吞吐量提高了大約 12%，與 RDS 相比，提高了大約 32%。

與 MySQL 類似，只有少數幾個開關顯著影響 Postgres 的效能。OtterTune、DBA、優化指令碼以及 RDS 生成的配置全都修改了這些開關，並且大部分提供了非常理想的設定。

結論

OtterTune 可自動完成為 DBMS 的配置開關尋找理想設定的過程。為優化新的 DBMS 部署，它會再次使用之前優化會話中收集的訓練資料。由於 OtterTune 不需要生成初始資料集即可訓練其 ML 模型，因此優化時間明顯縮短。

接下來做什麼？為適應 DBaaS 部署 (無法遠端訪問 DBMS 主機計算機) 的日益普及，OtterTune 將很快能夠在無需遠端訪問的情況下，自動檢測目標 DBMS 的硬體功能。

有關 OtterTune 的更多詳細資訊，請參閱我們的文章或 GitHub 上的程式碼。請密切關注本網站，我們即將在網站中提供 OtterTune 作為聯機優化服務。
作者簡介

Dana Van Aken 是卡內基梅隆大學計算機科學系的博士生，由 Andrew Pavlo 博士指導。她的主要研究課題是資料庫管理系統。她目前的工作重點是開發自動化技術以使用機器學習來優化資料庫管理系統。

Andy Pavlo 博士是卡內基梅隆大學計算機科學系資料庫學科的助理教授，也是卡內基梅隆大學資料庫研究組和並行資料實驗室的一名成員。他的工作還需要與英特爾大資料科技中心協作。

Geoff Gordon 博士是卡內基梅隆大學機器學習系的副教授兼副教導主任。他的研究課題包括人工智慧、統計機器學習、教育資料、遊戲理論、多機器人系統，以及概率域、對立域和常規求和域的規劃。

本文首發於亞馬遜AWS官方部落格網站，原創文章如轉載，請註明出處。