資料庫管理系統（DBMS）配置優化是任何資料密集型應用程式努力的基本方面。但這在歷史上是一項艱鉅的任務，因為DBMS有數百個配置引數，控制系統中的一切，比如快取記憶體使用的記憶體量和資料寫入儲存的頻率。這些引數的問題在於它們不標準化（即，兩個DBMS相同引數卻使用了不同的名稱），不獨立（即改變一個引數可能影響其他），不通用（適用於一個應用程式，但是對於另一個來說是次優的）。更糟的是，有關這些引數的選取通常只來自寶貴的經驗。

       為了克服這些挑戰，我們提出了一種自動化方法。利用過去的經驗並收集新資訊進行調整DBMS配置：我們使用有監督和無監督的組合機器學習方法要（1）選擇最有影響力的引數，（2）將看不見的資料庫工作負載對映到以前的工作負載，從中我們可以轉移經驗，（3）推薦引數設定。我們OtterTune工具中實現了我們的技術並在三個DBMS上進行了測試。 我們的評估表明OtterTune建議配置儘可能好或更好與現有工具或人類專家產生的。
 

1. 引言

       收集，處理和分析大量資料的能力對於能夠推斷出商業新知識至關重要和科學領域。 對於資料密集型（“大資料”）應用程式，DBMS是關鍵元件。 這些系統的表現通常以諸如此類的指標來衡量吞吐量（例如，它可以多快收集新資料）和延遲（例如，它能夠以多快的速度響應請求）。

       在DBMS中實現良好的效能並非易事因為具有許多可調引數幾乎可以控制他們執行時操作的各個方面[。 這樣的配置引數允許資料庫管理員（DBA）控制DBMS的執行時行為。 例如，他們可以設定資料快取分配的記憶體相對於事務日誌緩衝區。 現代DBMS因擁有許多配置而臭名昭著。 DBMS的如此神祕的一部分原因就在於他們的效能和可擴充套件性高度依賴在他們的配置上。 進一步加劇了這個問題是這些預設配置是出了名的壞。

       鑑於此，許多組織都在招聘昂貴的專家為預期的工作負載配置系統的引數。但是作為資料庫和應用程式在規模和複雜性方面都在增長，滿足應用程式需求的DBMS已經超越人類的能力。這是因為配置正確的DBMS高度依賴於許多因素，超出人類可以推理的範圍。
以前嘗試使用自動DBMS配置工具有某些缺陷使它們不適合一般用途資料庫應用。許多調整工具都是建立的供應商，因此他們只支援該特定公司DBMS 。少數支援的調優工具，多個DBMS仍然需要手動步驟，例如擁有DBA（1）部署資料庫的第二個副本，（2）對映引數之間的依賴關係或（3）指導訓練過程。所有這些工具還獨立檢查每個DBMS部署，因此無法應用從以前獲得的知識進行調整。這是低效的，因為每個調整工作都可以需要很長時間並且使用大量資源。

       在本文中，我們提出了一種重用訓練資料的技術從以前的會話中調整新的DBMS部署。我們方法的關鍵是培養機器學習（ML）模型
從這些先前的調優收集的測量結果，並使用模型要（1）選擇最重要的引數，（2）對映看不見的資料庫工作負載到已知的工作負載，以便我們可以轉移以前的經驗，以及（3）推薦引數設定，提高目標（例如，延遲，吞吐量）。重用過去的經驗減少了所需的時間和資源
為新應用程式調整DBMS。為了評估我們的工作，我們在OtterTune的調優工具中使用Google TensorFlow 和Python的scikit-learn，
併為兩個OLTP DBMS（MySQL，Postgres）進行了實驗和一個OLAP DBMS（Vector）。我們的結果顯示了OtterTune
為這些工作負載生成DBMS配置與預設設定或由其他調優顧問生成的配置相比，延遲降低了58-94％
。我們也表明OtterTune在60分鐘內生成配置佔專家DBA建立的94％以內。

2. 挑戰

       有一般規則或“最佳實踐”指南可用用於調優DBMS，但這些並不總能提供良好的結果適用於各種應用和硬體配置。雖然
人們可以依靠某些規則來實現良好的表現特別是DBMS，它們並非適用於所有應用程式。從而，許多組織都聘請昂貴的專家來調整他們的
系統。例如，2013年的一項調查發現，40％的參與度對一家大型Postgres服務公司的請求是用於DBMS調優的
和引數配置問題。

       調優DBMS的一種常用方法是DBA進行復制資料庫到另一臺機器，並手動測量效能來自實際應用程式的示例工作負載。基於
這個測試的結果，然後他們將調整DBMS的配置。由過去的經驗和調整指南以及直覺的某種組合選擇引數，然後DBA重複實驗
看效能是否有所改善。這樣一個“三分之二 - 錯誤“DBMS調優的方法繁瑣，昂貴，而且
效率低下。因為（1）許多引數不是獨立的，（2）某些引數的值是連續的，（3）通常不能從一個應用程式到下一個應用程式重用相同的配置（4）DBMS總是新增新的引數

        依賴關係：DBMS調優指南強烈建議DBA一次只能更換一個引數。這是明智但可悲的。鑑於大量的引數，速度很慢。它也不是完全有用的，因為改變一個引數可能會影響另一個引數的好處。但人類很難理解一個引數的影響，更不用說多個之間的相互作用了。不同的引數設定的組合意味著找到最佳配置是NP-hard 。為了證明這一點，我們進行了測量MySQL針對不同配置的效能改變其緩衝池的大小和日誌檔案的大小。結果表明DBMS實現了更好的效能當緩衝池和日誌檔案大小都很大時。但總的來說，當緩衝池大小和日誌檔案大小時，延遲很低“平衡。”如果緩衝池很大，日誌檔案大小是小，然後DBMS維護較少數量的髒頁因此必須執行更多的重新整理到磁碟。

      連續設定：DBMS調優的另一個難點是有很多可能的旋鈕設定，和不同的設定。例如，DBMS緩衝池的大小可以是
任意值從零到系統上的DRAM量。在某些範圍內，此引數增加0.1 GB可能無關緊要，而在其他範圍內，增加0.1 GB可能會導致效能急劇下降，當DBMS耗盡實體記憶體時。 為了說明這一點，我們進行了另一個實驗。我們將MySQL的緩衝池大小從10 MB增加到3 GB。結果表明延遲持續改善直到1.5 GB，之後效能下降，因為DBMS耗盡了實體記憶體。

不可重用的配置：DBA花費的精力在調優一個DBMS時，不會更容易調整下一個DBMS。
這是因為一個應用程式的最佳配置可能對另一個來說不是最好的。 

調整複雜性：最後，DBMS引數的數量總是如此。隨著新版本和功能的釋出而增加。 它是
DBA很難跟上這些變化並瞭解它們這將如何影響他們的系統。 這種複雜性是導致高總成本的主要因素。 人員估計是
幾乎佔大型DBMS擁有成本的50％，許多DBA將近25％的時間花在調優上。比單獨檢查每個資料庫應用程式更好的方法
是使用利用知識的自動化工具從一個應用程式獲得，以協助調整其他人。

3. 系統概覽

我們現在介紹我們的自動資料庫調整工具，克服了我們上面描述的問題。 OtterTune是一個調整適用於任何DBMS的服務。 它維護著一個儲存庫從先前的調優會話收集的資料，並使用此資料建立DBMS如何響應不同旋鈕配置的模型。對於新應用程式，它使用這些模型來指導實驗並建議最佳設定。 每個推薦在一個反饋迴圈中為OtterTune提供更多資訊允許它改進模型並提高其準確性。

 顯示了OtterTune架構的概述。系統由兩部分組成。第一個是客戶端控制器與要調整的目標DBMS互動。它收集執行時
來自DBMS的資訊使用標準API（例如，JDBC）進行安裝新配置，並收集效能測量。第二部分是OtterTune的調優管理器。它收到了
從控制器收集的資訊並將其儲存在其儲存庫中使用先前調優會話的資料。這個儲存庫確實不包含任何有關DBMS或其內容的機密資訊，資料庫只包含引數配置和效能資料。 調優管理器支援訓練OtterTune的內部ML模型通過持續分析新資料和改進的後臺流程。這些模型允許它在沒有人為輸入的情況下識別相關的引數和指標，以及在儲存庫中查詢與目標類似的工作負載。

3.1 舉例

       在新的調優會話開始時，DBA告訴OtterTune選擇配置時要優化的指標（例如，延遲，
吞吐量）。 OtterTune控制器然後連線到目標DBMS並收集其硬體配置檔案和當前引數配置。 我們假設這個硬體配置檔案是單一的
來自預定義型別列表的識別符號（例如，例項型別亞馬遜EC2）。

       控制器開始第一個觀察期。控制器將觀察DBMS的一段時間並測量由DBA選擇的獨立於DBMS的外部指標（例如，延遲）。 DBA可以選擇執行一組固定時間段的查詢或特定工作負載跟蹤。如果DBA選擇一組固定時間段的查詢，那麼選擇觀察的長度等於固定的時間段。否則，持續時間取決於DBMS重放工作負載所需的時間跟蹤。固定觀察期非常適合快速，簡單查詢(這是OLTP工作負載的特徵)，而執行長時間執行通常需要可變長度的週期，(OLAP工作負載中存在複雜查詢).

       在觀察期結束時，控制器收集其他DBMS特定的內部指標。 比如包括MySQL用於讀取或寫入磁碟頁面的計數器。 其他DBMS提供類似的指標，但OtterTune不需要來自DBA的任何有關其含義的資訊，無論是否表示效能好壞，或指標是否表示不同的名稱在不同的DBMS中（相同的引數含義）

        當OtterTune的調優管理器從控制器觀察期間收到新的結果時，它首先儲存該資訊在其儲存庫中。從此，OtterTune然後計算下一個配置(收集器安裝在目標DBMS）。在OtterTune中，選擇下一個配置是至關重要的。在每個觀察期後（確定系統推薦哪一種配置）有兩個不同的步驟發生。在第一步，OtterTune嘗試“理解”目標工作負載並將其對映到過去的工作負載(相同的DBMS和硬體配置檔案)。一旦調優管理器使用它到目前為止收集的資料找到了最佳匹配，然後開始第二個步驟，它推薦一個特定的引數配置
旨在改善當前工作負載，資料庫，硬體的目標，為了協助DBA決定是否終止調優會話，OtterTune的控制器提供了更多推薦配置
與目前為止看到的最佳配置進行比較。此過程一直持續到DBA對改進感到滿意為止與初始配置相比。

3.2 假設和限制

       OtterTune功能我們必須強調幾個方面。最重要的是我們假設控制器具有管理性
修改DBMS配置的許可權（包括必要時重新啟動DBMS）。如果這是不可能的，對於OtterTune的除錯試驗，那麼
DBA可以在單獨的硬體上部署資料庫的第二個副本。這要求DBA要麼重放工作負載跟蹤或轉發生產中的查詢
DBMS。這與以前的工具中使用的方法相同。通常需要重新啟動DBMS，因為有些配置僅在系統停止並啟動後生效。一些引數
導致DBMS在執行時需要額外處理當聯機時（例如，調整日誌檔案的大小），這可能會佔用幾分鐘，具體取決於資料庫和硬體。 OtterTune目前忽略了重新啟動DBMS的成本建議。我們推遲自動識別的問題這些引數並考慮重新啟動的成本選擇配置作為未來的工作。

       因為不希望重新啟動DBMS，所以許多DBMS都支援動態更改一些引數而無需重新啟動
系統。 OtterTune儲存了一系列動態引數在它支援的每個DBMS版本上都可用，以及有關如何更新它們的說明。重新啟動DBMS，只有當調整的一組引數需要重啟時。 DBA可以只調優動態引數，如果禁止資料庫重啟的話。我們保留了OtterTune支援的每個DBMS版的引數黑名單。在每個調整會話的開始時，DBA需提供引數列表的黑名單。允許DBA新增任何引數到黑名單中，DBA希望OtterTune避免調優的任何其他引數，比如沒有意義調整的引數（例如，DBMS儲存檔案的路徑名，或者隱藏的或有嚴重的後果的引數（例如，可能導致DBMS丟失資料）。再次，自動確定是否更改引數將導致應用程式可能丟失資料超出了我們在這裡工作的範圍。

      最後，我們還假設資料庫的物理設計是合理的。 這意味著DBA已經安裝了適當的索引，物化檢視和其他資料庫元素。

       在接下來的部分中，我們將介紹OtterTune如何收集調優會話期間來自DBMS的執行時指標。 然後從這些資料建立模型，允許它（1）選擇最多有影響力的引數，（2）將以前看不見的資料庫工作負載對映到已知的工作負載，以及（3）推薦引數設定。 我們一開始討論如何識別調優工具收集的指標最能表徵應用程式的工作負載。 整個過程見下圖