精品国产一级在线观看,国产成人综合久久精品亚洲,免费一级欧美大片在线观看

數據庫管理系統（簡稱 DBMS）無疑是任何數據密集型應用程序當中最為重要的組成部分，其肩負著處理大量數據以及高復雜性工作負載的重任。然而，數據庫管理系統本身卻往往難于管理，因為其中通常包含數百種配置“旋鈕”，用于控制諸如緩存內存分配量以及存儲介質數據寫入頻率等要素。各類企業一般需要聘請專業人士以協助相關調配工作，但對于大多數企業而言，此類專業人才的開價亦相當高昂。

面對這一難題，卡耐基 - 梅隆大學數據庫小組（Carnegie Mellon Database Group）的學生及研究人員們共同開發出一款名為 OtterTune 的新型工具，其能夠以自動化方式識別出最適當當前數據庫管理系統配置需求的設置組合。其目標在于有效簡化用戶對 DBMS 的部署流程，確保那些在數據庫管理層面不具備任何專業知識的朋友亦能輕松完成任務。

OtterTune 與其它 DBMS 配置工具之間的主要差別在于，其能夠利用自此前 DBMS 部署工作當中積累到的知識指導新系統的配置工作。這一設計思路顯然降低了新 DBMS 部署方案在調整當中所需要的時間與資源投入。而為了實現這一目標，OtterTune 專門建立起一套數據庫，用以收集從此前調節會話中提取到的重要信息。其利用這部分數據建立機器學習（簡稱 ML）模型，用以捕捉 DBMS 在面對不同配置方案時作出怎樣的響應。OtterTune 還利用這些模型以指導新型應用程序的配置實驗，并提供推薦設置以提升目標運作效果（例如減少延遲或者提高數據吞吐量）。

在今天的文章中，我們將探討 OtterTune 機器學習管道當中的每個組成部分，同時展示其如何彼此交互以實現 DBMS 配置調節。在此之后，我們還將立足 MySQL 與 PostgreSQL 評估 OtterTune 的調節效果，包括將其最佳配置方案與數據庫管理員（簡稱 DBA）以及其它自動化調節工具給出的答案進行比對。

OtterTune 是一款開源工具，由卡耐基 - 梅隆大學數據庫小組的學生及研究人員們共同開發而成。其全部代碼皆可點擊此處通過 GitHub 訪問，且基于 Apache License 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 的機器學習管道實現移動與處理。全部觀察結果皆被保留在 OtterTune 的存儲庫當中。

OtterTune 首先會將觀察結果交付至 Workload Characterization 組件當中。此組件負責識別其中一小部分 DBMS 指標，從而更好地把握性能差異以及不同工作負載之間的區別性特征。

接下來，Knob Indetification 組件會生成一份與可調節項目相關之排名清單，其具體排序根據對 DBMS 性能之影響力而定。OtterTune 隨后會將全部信息饋送至 Automatic Tuner 當中。此組件負責將目標 DBMS 的工作負載與現有數據存儲庫內最為相似的工作負載進行映射，而后利用對應工作負載數據以生成更適用的配置方案。

　　下面讓我們深入了解機器學習管道當中所涉及的每一個組件。

Workload Characterization: OtterTune 利用 DBMS 的各內部運行時指標以表征某一工作負載的行為方式。這些指標能夠對工作負載作出準確表示，因為其能夠確切捕捉到其運行時行為當中的各項細節。然而，亦有許多度量完全不必要存在：其中一部分屬于不同單元記錄當中的同一量度結果，另一些不必要指標則代表著某些數值存在高度互關聯性的 DBMS 獨立組件。因此，對其中的冗余度量進行排除將非常重要，這將有效幫助我們降低機器學習模型的復雜性水平。為此，我們將面向 DBMS 對相關模型的度量進行收斂。此后，我們將從每個群集當中選擇出一個代表性度量，并確保其為最靠近群集中心的度量。機器學習管道當中的后續組件將對這些度量加以使用。

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 以實現相應的機器學習算法。這些算法在后臺進程當中運行，并使用來自 OtterTune 存儲庫的新數據。

對于 Automatic Tuner，這些機器學習算法則變得更為關鍵。其需要在每一輪觀察周期后運行，同時結合新數據以確保 OtterTune 能夠選擇一項對應調節條目進行下一步嘗試。在這一流程中，由于性能成為更加重要的考量因素，因此我們使用 TensorFlow 以實現這些算法。

為了收集與 DBMS 硬件、調節配置以及運行時性能指標相關的數據，我們將 OtterTune 控制器同 OLTP-Bench 基準測試框架進行了整合。

實驗性設計

為了完成評估，我們利用 OtterTune 所給出的以下最佳配置選項對 MySQL 及 Postgres 性能進行了比較：

我們在 Amazon EC2 現貨實例之上進行了全部實驗。我們分別在兩套實例之上執行實驗過程：其一作為 OtterTune 控制器，其二則作為目標 DBMS 部署系統。我們在這里分別使用了 m4.large 與 m3.xlarge 實例類型。我們將 OtterTune 的調節管理器與數據存儲庫部署在一套本地服務器之上，其配置為 20 計算核心與 128 GB 內存。

我們還用到了 TPC-C 工作負載，其屬于業界標準的在線事務處理（簡稱 OLTP）系統性能評估工作負載類型。

評估方式

對于我們在實驗當中所使用的 MySQL 與 Postgres 兩套數據庫，我們分別對其延遲水平與數據吞吐量進行了觀察。以下圖表給出了對應結果。第一份圖表所示為第 99 百分位處的延遲水平，意味著“最壞情況”下完成事務處理所需要的時長。第二份圖表則顯示了數據吞吐量結果，即每秒完成的平均事務數量。

MySQL 測試結果

將 OtterTune 所生成的最佳配置與 Tuning Script 以及 RDS 相關配置進行比較可以發現，MySQL 在延遲水平方面降低了約 60%，而數據吞吐量則在 OtterTune 配置的幫助下提升 22% 到 35% 之間。與此同時，OtterTune 的生成的配置方案在實際效果上與人類數據庫管理員幾乎不相上下。

一部分特定 MySQL 調節項目對其 TPC-C 工作負載性能表現產生了顯著影響。OtterTune 與數據庫管理員提供的配置方案可為每一調節選項帶來良好的設置效果。RDS 的執行水平稍差一點，在設置效果上略遜一籌。而 Tuning Script 的配置效果最差——因為其只對其中一個調節選項作出了變更。

Postgres 測試結果

在延遲方面，OtterTune、調節工具、數據庫管理員以及 RDS 所給出的配置建議全部優于 Postgres 的默認設置，且提升效果基本類似。我們可以將這一結果歸結于 OLTP-Bench 客戶端與 DBMS 之間的往返路由造成了巨大的性能影響。在數據吞吐量方面，Postgres 在使用 OtterTune 建議配置時，實際效果較數據庫管理員及 Tuning Script 配置選項大約提升 12%，而與 RDS 間的比較優勢更是達到 32%。

與 MySQL 類似，只有少數幾個調節選項會對 Postgres 性能產生顯著影響。OtterTune、數據庫管理員、Tuning Script 以及 RDS 所生成的配置都對這些條目進行了修改，且其中多數能夠帶來相當不錯的設置效果。

總結意見

OtterTune 能夠以自動化方式為 DBMS 各配置選項找到良好的設置方式。為了對新的 DBMS 部署系統進行調整，OtterTune 會使用以往調優會話當中收集到的訓練數據。由于 OtterTune 并不需要在每次生成操作當中再次利用初始數據集進行機器學習模型訓練，因此整個調節時間周期得到大幅縮減。

未來的發展目標是什么？為了進一步適應日益普及的 DBaaS 部署場景（此類場景下，將無法以遠程方式訪問 DBMS 主機設備），OtterTune 將很快能夠自動檢測目標 DBMS 的硬件功能，且無需進行任何遠程訪問。

欲了解更多與 OtterTune 項目相關的細節信息，請點擊此處參閱我們的論文（英文原文）或者 GitHub 上的代碼。亦歡迎大家關注我們的網站，我們將盡快通過本網站以在線調優服務的形式將 OtterTune 交付到您的手中。