自治資料庫旨在完全自動化資料庫部署中的配置和運維任務，例如建立索引和進行引數調優。實現自治資料庫的關鍵是建立能夠預測各種最佳化任務的開銷和收益的行為模型。但資料庫的系統複雜度、併發操作、以及訓練資料的獲取代價使得建模具有挑戰性。

基於此，今天為大家帶來 OceanBase Paper Time 第二期文字版分享回顧，由 卡耐基梅隆大學博士後馬林分享《為自治資料庫建立行為模型》，原論文名為“MB2: Decomposed Behavior Modeling for Self-Driving Database Management Systems”。為大家介紹一種分解式的建模框架解決上述難點，並利用所建模型準確預測不同最佳化任務的開銷和收益，歡迎大家一起學習討論分享。

以下為直播實錄：

大家好，我是馬林，現在 CMU 博士後在讀，今天我跟大家分享的論文為“MB2: Decomposed Behavior Modeling for Self-Driving Database Management Systems”，是 2021 SIGMOD 上發表的論文。

MB2 是一個分解式的自治資料庫建立行為模型的框架。在現在網際網路時代，各種資源、資料非常多的情況下，人們通常會用資料管理系統去控制資料的儲存和訪問。但隨著資料的爆發式增長，資料管理本身也變得越來越複雜，尤其伴隨資料量級和資料多樣性的增長，這些系統本身需要有很多的設定任務。

我們通常需要 DBA 去管理資料庫系統部署中的各種任務，比如說資料管理員需要設定各種各樣的索引（一種加速部分資料訪問的一種資料結構）；或者資料管理員要設定資料庫各種各樣的引數，比如說進行日誌管理的間隔等；尤其是雲時代，資料庫管理員要去設定資料庫資源的大小，有多少 CPU，多少 Memory，多少 IO 等等。這就導致企業需要花費很大成本去僱傭資料庫管理員，對於很多大公司或者雲資料庫的服務商，可能要管理幾千個、幾十萬個資料庫，如果每一個資料庫都要分配一個資料庫管理員的話，就很不現實。

供＜求，驅動資料管理思維變更

當今時代已經對資料驅動、資料密集型應用的部署造成了很多挑戰，目前也有很多的解決辦法。在資料庫行業發展的很多年裡，各個廠商、研究員開發了很多幫助資料管理的工具。但在工具使用的場景中，還需要藉助很多人為的力量去使用這些工具。比如一個資料管理員想設定資料庫的索引，或者設定一些引數。他先要準備一個具有代表性的資料庫負載(workload)，同時還要準備一些空餘的硬體，然後再在硬體上去複製一些資料庫的內容。要在空餘的硬體上和準備好的 workload 上，去執行資料庫調優、或者是推薦索引的工具。拿到這些推薦之後，在各種各樣推薦的索引當中選擇一個比較好的或者最優的索引，最後決定什麼時間更改，這都需要人為的更改。通常這些更改都需要在資料庫負載比較低的時候，比如凌晨三四點，對於資料庫管理人員來說，這種流程很是痛苦。

之前‍這些大部分管理工具都是關注在資料庫的某一個方面。比如說有的工具關注索引，有的工具關注怎麼和使用者協同，不同的資料放到不同的分割槽，然後很多工具進行引數的調整。很多工具要一遍一遍的重複這個過程，不同的工具都要用一遍是非常繁瑣的過程。正因此，我今天為大家帶來一種新思路。

我在另一篇論文中對資料庫的自主幫助管理、自動部署的等級進行了區分(Make Your Database System Dream of Electric Sheep: Towards Self-Driving Operation, VLDB 2021)。

最低階，所有的資料都需要資料管理員自己用。有一些不同的廠商，會在中間層次幫助資料庫進行自我管理的工具，比如說去控制某一個小的部分。但是我們在這裡的專案就是希望達到最高等級——自動駕駛（self-driving）或者是自治的級別。意思是資料庫可以完全自動管理不同的方面，包括索引、引數等等，透過一個統一的關鍵框架去管理，這個自治資料庫不僅僅是給 DBA 去進行一些推薦，而且能預知之後的事情，就比如說資料庫的負載是什麼？怎麼去進行資料庫的自動調優、改變安排，並且完全可以自動的進行，不需要人為干預，這是我們要達到的目標。

簡單定義下自治資料庫：自治資料庫是一個可以完全能夠設定調優並且最佳化系統的各個方面，也不需要任何人為干預的資料庫。

具體來說就是它可以自動最佳化任何跟資料庫效能相關的方面。比如說 physical design(索引)，或者冷熱分離、調引數、資源配置。但是有一些設定還是需要人去進行價值判斷，比如說資料庫的哪一個表，或者哪一列，什麼人會有許可權去操作，資料庫的本身仍然不能確定。

為什麼在這個時代有可能做自治資料庫？有幾方面原因。

首先，在資料驅動的時代，不光是資料庫本身可以儲存很多客戶的資料，同時資料庫可以去對資料庫本身的執行狀態，去記錄很多的指標、引數、執行狀態的歷史記錄，還有資料庫本身的執行狀態。我們也可以嘗試去發掘支援、幫助資料庫進行自動最佳化。第二，我們這裡有很多更好的硬體，可以儲存更多這樣的資料，也可以更快速地處理這些資料，並且完成資料庫的自動最佳化。最後，現在這個時代有很多方便的人工智慧、機器學習方面的庫和工具，來幫助我們去部署這些自動調節的演算法。

自治資料庫的挑戰

聽起來有很多的機會、趨勢去幫助我們完成這個任務，甚至感覺將一個現成的人工智慧演算法往資料庫的系統上一套，就能實現完全的“自動駕駛”，但在現實當中還是有一些挑戰。

第一，資料庫本身是一個非常複雜的系統，如果你想要一個統一的框架去完全的去控制資料庫各個方面複雜度很高。

第二，在資料庫當中的很多操作，比如說想使用機器學習這些演算法去訓練模型、去控制智慧化的資料庫，需要資料去訓練這些模型，但是資料庫當中的很多操作，它其實是要花很多時間的，獲取這些模型的訓練資料也要花很多時間。比如說建一個索引，如果這個表上有幾十億個行，建一個可能就要好幾個小時，好幾天。

第三，你在實驗室或者開發環境當中訓練了一些模型，然後去部署這個智慧資料庫。但模型不是百分之百準確的，很難保證在這個開發環境當中訓練的這些模型，在部署當中還能有好的效果。

還有一些其他的方面，比如說智慧資料庫或者自己資料庫的可解釋性，這個排除故障的難易程度等等，對於一個實際比較現實的自治資料庫開發來說，這些方面都是需要解決的難點。

我們稱之為自治資料庫（self-driving database），其開發系統是受了自動駕駛的啟發。但是我要說的是，現實當中自動駕駛的技術是非常複雜的，但是我覺得在這兒作為一個比喻對於理解還是很有幫助的。

一輛自動駕駛的汽車，它大概是這麼幾個部分。首先是感知部分，汽車需要感知其他的汽車、行人在路上的位置，並且也要預測一下車或者行人往哪移動，然後計算了一個汽車。第二，它對它自己控制的這些操作有一些模型可以預測，比如說方向盤打了多少度、汽車往哪拐，他需要有模型，這裡資料庫稍微有點不同，待會可以講一下。

第三點，資料庫對於道路其他東西的感知和一些操作模型。這個資料庫最終要一個計劃階段，我們設計的自治資料庫架構和自動駕駛汽車有很多相似。

首先，感知部分。我們覺得資料庫首先要去接收和監測收到了哪些工作負載，並且他也要預測未來資料庫一段時間內的工作負載是什麼樣。比如說負載高，負載低等等，因為未來這些負載，就是資料庫它要自動最佳化的目標，我們叫這個為負載預測。

第二，資料庫要進行不同的自動最佳化操作。比如說建索引，調引數等等。那你還是需要模型去估計你不同操作的開銷和收益。因為這是你做決定的依據，這裡和汽車不太一樣，需要你自己建立一些模型。

第三，如果我們有了一些可能備選的最佳化操作，並且我們也知道未來的負載形態，我們最後就要選擇在什麼時間段去應用什麼樣的最佳化。比如說這個時間段的負載量比較低，我們可以在這個時間段內建一個索引。如果你要達到這個目標，你需要一個計劃，根據預測和資料庫操作開銷和收益的模型等操作去自動最佳化資料庫的效能。

關於自治資料庫的框架。我們是整合在 CMU 資料庫系統裡面，叫做NoisePage，我們這個是從頭開發的去支援自動化的操作。它既支援這個事務型，也支援分析型，並且它是MIT license，相容 Postgres 介面和 Arrow 儲存格式。

行為建模

接下來分享一下怎麼給這個自治資料庫去建立這些模型——即行為建模。具體來說，用行為模型的目標去估計不同資料庫自動化的操作、開銷和收益。這個模型輸入包括兩部分，一部分是預測的未來資料庫負載。假設我們可以預測未來資料庫裡有什麼負載，並且同時也要給這些模型一個可能的操作。比如說建立一個索引，或者是找一個引數，輸出這個可能的操作在預測未來負載上的開銷和收益。

稍微更進一步的闡釋為什麼這些模型很重要，我們用一個簡單的實驗來說明。假設我們有一個資料集，但它一開始沒有合適的二級索引，但我們要去假設有自治的操作，然後建一個二級索引，對這個負載進行加速。我們有兩個選項，八個執行緒或四個執行緒，我們試圖去加速查詢。在這個負載一開始的時候，沒有二級索引，它的查詢相對延遲比較高。然後我們大概在 50 秒鐘的時候去建立索引。在不同的情形當中，雖然說最終查詢都被加速了，但是它對資料庫效能的影響非常不一樣。如果你用八個執行緒，這個索引完成的特別快，但在這個完成的過程當中他有更大的開銷，他對資料庫過程中的影響非常大。而四個索引說就是反面，就是說在不同的應用的操作選擇、時間點，實際上根據不同客戶的要求、系統的要求、系統的實際狀態，然後他最終的選擇都是很不一樣的，所以說能準確的預測自動化操作的影響，對自治資料庫至關重要。但這裡面也有幾個挑戰。

第一，現在的資料庫非常複雜，可能有很多不同的負載。如果你想用一個單一的機器模型，去包括資料庫的各個方面、各個操作等等。這個模型就很容易非常高維，作為結果，這個模型可能需要很多的訓練資料去訓練，並且可能也不太容易去排除故障，不太容易解釋等等。

第二，現在的這些資料庫在硬體上，大部分情況下都不是單執行緒的，很多時候都是多執行緒併發操作。這種情況下，不同執行緒上的併發操作互相之間可能會有影響，比如資源競爭等。那就是說這個模型要包括這些可能的操作情況，隨著併發競爭維度的上升，它就呈指數級別、至少是組合數級別上升。

第三，很多資料庫操作非常費時，怎麼高效獲取高質量的訓練資料很有挑戰。如果你獲取一個新的資料就已經花了幾個小時，這就很不現實。當然有一些其他的演算法對資料庫操作、執行狀態、執行進行了一些建模。

它的建模方式大概可以分為兩種。

第一種叫分析性模型，主要針對查詢的執行，往往針對資料庫的其他部分有專家去分析各個部分的操作特性，不需要任何的訓練資料去寫各種各樣的公式，去刻畫操作的行為。但這也有兩方面的缺點，一方面需要專家非常瞭解資料庫的每個部分，具體的行為是什麼，可能有哪些的輸入的變數，操作怎麼用一個數學公式去表達，對於專家來說，要花很多時間才能把這個公式寫出來。另一方面，它是比較難以遷移的。比如說資料庫有一個模組進行了程式碼更新，進行了替換，那之前寫的公式就不管用了，那就要重新再寫一個公式。

第二種，機器學習類模型。用一些機器學習的方式去對這個資料庫的操作，尤其是對查詢的執行進行建模。這個好處是不需要太過於專家的分析，也不需要數學公式對資料庫的操作有非常深的理解，也比較容易去進行遷移。但它的問題就是大部分技術模型它首先只關注單一查詢的。但是資料庫很多時候有不同的查詢，甚至是不同的組成。有的時候執行需要建索引時，有的時候要進行這個日誌的寫入和收集。這些資料庫的不同操作，不同部分之間怎麼進行建模，它沒有很好解決的。

根據之前的實驗結果，這些機器學習類模型往往有另一個問題，在實驗室或者開發環境當中，你建立一個模型並且測試好了，模型的準確度很高。但是當你把這個模型部署到不同的資料集上，或者是部署到實踐當中，這個模型的準確度，因為訓練資料不一樣，模型訓練資料都會大大下降。

MB2建模框架

我來介紹一下我們工作的主要解決方式，我們提供了 MB2 這樣一個為自治資料庫進行了建模的框架，它屬於中間型（半分析半學習的建模方式），大概結合了我們剛才說的分析性模型和機器學習模型的優點。它是一個線下的框架，在自己的開發或者實驗室環境當中就可以去做。當你建完這個模型之後，直接去進行部署，這裡由幾個部分組成。

首先，我們會有一些特定的 runner（執行器），去對資料庫不同部分，就比如說建索引、查詢執行等等，有特定的工作負載去測試資料庫不同的部分在不同的情況下透過不同的行為去獲得很多的訓練資料。雖然它們會有不同的執行器去測試，但是我們有一個統一的資料收集系統，主要使用執行緒本地的儲存去加速儲存，使得資料庫可以高效地去收集不同部分的訓練資料，然後將收集的資料送到訓練中心去測試不同的機器學習模型，最後去建立對資料庫的兩種模型，一種是我們叫 operating unit model——針對各個部分的操作單元模型，一種是 interference model ——針對不同的併發操作之間的互相影響。

很重要的一點，我要強調：MB2 是線下的建模框架，可能會稍微多一些開銷，但是它是和資料庫具體的負載和具體資料集什麼樣是獨立的。雖然這個線下模型你需要花一些時間去訓練資料，但是你把它部署在任何一個實際的或者資料集上面。資料集和工作負載本身沒有太多的關聯性。或者說這些模型儘量的去包括了各種各樣的不同的資料集和負載，所以說線上就不需要再確定，但大部分情況下，線上不需要做非常繁瑣的操作。

具體來說，這個自治資料庫建模的核心思想是用一個分解式的建模方式。意思就是說我們會去把資料庫的各種各樣的操作去分解成比較小的操作單元。對於每一個操作單元，我們會去特定的收集訓練資料，並且去建立模型。好處就是每一個模型它比較小，不需要很多很多的訓練資料，比較容易去解釋，如果出了問題也比較容易排除故障。如果這個資料庫有一個軟體的部分進行了更新，那也比較容易更新這些模型，因為每一個模型都是獨立的。如果說資料庫的某一個部分結構性的，你只需要把針對這一個部分，就比如說它的索引部分更新了，那你就根據這一個部分的模型，進行重新的訓練就可以了，你不需要把所有的這些模型都重新的實驗室資料收集和訓練。

舉一個稍微具體的例子，比如說我們的 NoisePage 系統，我們大概把它分成了 20 個基礎的操作單元，比如說建雜湊表、建索引、序列化日誌等等，針對不同的操作單元，我們叫 input feature（輸入特徵），不同的操作單元有不同的輸入特徵，這些輸入特徵也會包括資料庫的不同引數，如果這些引數影響到某一個操作單元，當中也會包括這些引數，但是所有的這些操作單元的模型，它的輸出標籤都是統一的。這些輸出的標籤會包括這些操作單元的完成時間、進行某個操作需要多少 CPU、多少 CPU、IO、多少 memory 等等。最後，如果說資料庫要估計某一個自動化操作的開銷和收益，它就先把這些自動化操作在具體的負載上，它有各種各樣可能的影響都會分解成操作單元，進行分別預測並相加。

具體來說，在我們這個 NoisePage 的資料庫當中，我們大概是有三種不同型別的操作單元。

第一種是單一的操作單元。比如說我們建一個雜湊表，或者我們對某些資料進行一次排序這種簡單的操作。

第二種是批處理的操作單元。就是說資料庫當中有一些任務，它是分週期的被喚醒然後執行，比如說他們會去寫日誌，很難預測單一一次寫了多少，寫到哪兒。透過這種週期性進行喚醒的工作去預測一段時間之內這些操作帶來的開銷和影響。

第三種是併發的操作單元。資料庫中有一些操作可能會進行多執行緒執行。比如說去建一個索引，建立索引本身就有多個執行緒同時完成。在這種情況下，多執行緒完成之間會有同步的機制，這些同步的機制會產生開銷。所以說這些操作單元和相應的操作單元的輸入特徵當中，要包括這些同步機制的資訊、執行緒、鎖等等。

舉例來說，我們建一個雜湊表就是資料庫中的一個操作單元。一個操作單元我們去用模型去刻畫它有什麼樣的特徵呢？這個雜湊表有多少行，每一行總共的資料有多大大小，它的 cardinality estimation 是多少。建立雜湊表有一些相關的引數可能會影響這個效果。比如說在我們的配置系統裡面，它的解釋模式、編譯模式等等都會影響操作單元的執行狀態。

在資料庫當中，你需要收集、產生和訓練資料去建立這些模型，去解決這個問題可以去應用一些定製的執行器去充分測試每個操作單元，然後去遍歷它各種各樣可能的輸入特徵的情況，並收集訓練資料。比如說資料庫有 N 個操作單元，相應的就有 N 個執行器，執行器它會執行一些工作負載，但這些都是我們自己寫的合成的負載。它們去遍歷各種可能的輸入特徵。比如說剛才這個建立雜湊表的操作單元，它的執行去遍歷了不同的行，不同的列、不同的列大小、不同的引數等等。這些組合對測試雜湊表，在不同情況下測試它的執行效果，然後我們收集訓練資料送到訓練的中心，訓練中心用一個 cross validation 的方式去遍歷各種各樣的比較流行的機器學習模型。比如說線性迴歸、隨機森林、深度神經網路等等，去為每一個操作單元選擇對他來說最好的模型。

在我們的觀察當中，對於大部分操作人員，對我們資料的體量和特徵情況來說，這個 gradient boosting 模型在大部分時候表現最好。

還有一個最佳化點，在資料庫當中很多時候它收集訓練資料非常昂貴，建一個索引可能就花了幾個小時甚至更長的時間。這種開銷是你不太能夠承受的。我們觀察到在資料庫當中，其實很多我們規定出來的操作單元有確定的複雜度。比如說建一個雜湊表，它的複雜度是 O(N) 的，排序的複雜度是 O(NlogN) 的。

因為它是漸進的複雜度，當這個 N 大到一定程度的時候，這個操作單元的開銷複雜度和 N 的複雜度是成比例關係的。我們可以把每一個單元輸出的標籤去除以對應的複雜度，差不多可以得到每一個記錄的操作單元的輸出標籤。

所以說如果我們用這種方式去進行預測的時候，我們其實並不需要收集到非常多的資料。因為我們只要收集到N大到一定量級，比如說在我們觀察當中 100 萬行的時候，它的輸出已經非常穩定。你只需要再往上給這個標籤的數量給它成比例的增加就可以了，這樣我們需要訓練的資料量就會大大減小。

給大家展示模型框架的預測結果：首先展示在單一執行緒裡面的結果，對這個結果我們去測試了它既在分析場景下，又在事務場景下的預測效果。我們對於 MB2 的線下框架，他永遠用的統一系列、一次建成的這些操作單元的行為目標模型，只是一套模型，但可以應用在不同的資料集上。

作為一個比較的 baseline，我們用的方法叫做 QPPNet，它是之前在資料庫領域進行查詢執行預測最好的 baseline，但是這個 QPPNet 就和很多其他的資料庫模型一樣，它是你在某一個資料集上訓練，然後在其他的資料集上測試，問題就是它沒有一個系統性的產生訓練資料的方式，所以我們在不同的workload上面，選某一個負載去訓練這個 QPPNet，並且在其他的負載進行測試。

這是 MB2 和 QPPNet 預測某個查詢的執行時間在不同的資料集上的結果。這裡的縱軸代表預測的錯誤，就是說這個縱軸越低，這個預測的錯誤率越低。如果你先去看這些資料集，既訓練了 QPPNet，並且在同樣的資料集上再進行測試，在這樣的資料集上，QPPNet 的準確度和 MB2 相比是相似的，甚至更好。那是因為我們就是在某個資料集上訓練的 QPPNet 的模型，同時我們又在這個資料集上進行測試，同一個資料集 QPPNet 有很多的模型結構，去捕捉訓練資料集上具體特性，所以它的預測性比較好。

但是當你遷移到不同的資料集上，比如說你在某個資料集上訓練 QPPNet，但是你在不同的資料集上測試，這個時候它的預測結果大大不如 MB2。MB2 是同一個模型定位在不同的資料庫上，因為 MB2 有一個框架去把這個複雜的資料庫裡面的各種操作解構成單一獨立的操作，並且每一個操作單元收集了足夠的資料去建立準確的小模型，它更容易在不同的場景下進行遷移。這和機器學習，或者資料為中心的人工智慧的一些觀察是相似的。

對於應用機器學習的場景當中，很多時候除了機器學習優秀模型之外，怎麼樣去系統性的收集高質量的訓練資料，這對模型的準確度有非常大的影響的。剛才我們展示的實驗，只是在單一執行緒的情況下且沒有任何併發情況下對某一個查詢的執行時間預測。但是在現實當中，資料庫通常是多執行緒的，在多執行緒的情況下，資料庫的幾個、10 個、20 個核都跑滿了，此時查詢執行時間可能會成倍延長，此時用之前的單一模型分解獨立預測出來就不準了，所以需要有一個模型去捕捉有很多工在併發執行的情況下，他們之間的競爭是什麼樣的，負載非常高的時候怎麼對每一個操作檯進行影響的。

我們建立了另外一個干擾/競爭模型（Interference model）去捕捉影響，干擾模型利用的資訊恰好就是剛剛操作單元模型的輸出。因為每個操作單元的輸出，就是每一個操作單元的執行時間、CPU 消耗、memory 消耗等等，所以我們就利用這些作為輸出。具體一點，根據我們之前對於負載的預測，在某一個時間段內併發的操作，我們先用操作單元模型預測資源消耗，然後利用一些統計資料，比如說操作單元總共的資源消耗的時間負載，或者 50 percentile，90 percentile 等等，作為這個時間段內這些操作單元它可能的影響的負載的刻畫，這是它的輸入特徵。

影響干擾模型的輸出特徵，就是在這個時間段內，我有這些操作單元的負載及分佈等等，它的輸出在平均情況下，它對每一個查詢會造成多大的影響，比如說每個查詢慢了一倍，慢了兩倍等等，這個類似的我們之前的對每個操作單元有一些執行去收集資料、訓練這個模型。

MB2模型使用

我們回顧一下怎麼使用整個模型。首先對於我們預測出來的某一個時間段內的資料庫的負載，和某一個我們要想要進行的自動化的可能最佳化，我們先把它拆解成各個不同的小的操作單元。比如說建一個索引，比如說去掃描一些資料，建立雜湊表等等，這是在同一個時間段內的。

對於這些操作，我們先用這個操作單元模型去預測。如果說是他自己的情況下，完全獨立的情況下，他有多少的開銷，有多少的時間等等。我們就把這些開銷稍微彙總一下，作為輸入資料放到干擾模型裡邊，然後去預測在這個複雜的情況下，我們該怎麼樣對每一個操作的執行時間進行調整，把它變成了兩倍長等等，然後最後把所有的結果加起來，這就是資料庫最終的行為。

Paper Time 回顧｜MB2：為自治資料庫建立行為模型

我們用一個端到端的實驗去展示一下。我們去測試一個資料庫正常的執行情況下，去應用各種各樣不同的自動化操作，這個模型能不能對這些操作的開銷和好處進行準確的預測。這裡我們首先是用了一個模擬的日夜週期，就是說白天是事務性，晚上是分析模擬的負載，但是這個時間就縮小了，只有兩分鐘。白天用 TPCC 模擬，晚上用 TPCH 模擬。很重要的一點就是說我們關注模型的預測，所以我們假設未來的負載預測和最後的計劃都已經給定，然後看看我們這個模型預測的效果。

首先負載分為幾個階段。白天 TPCC 到晚上的 TPCH 再到白天的 TPCC，然後延遲也合標準，就是把它放到同一個規格上。在這個開始階段沒有最優的設定，沒有最優的索引，所以它的延遲相對來說比較高。然後在 TPCH 階段，資料庫自動改變了一個查詢執行模式的引數操作，MB2 這個模型就很準確地預測了這個操作對資料庫可能有什麼樣的影響。

剛才是某一個引數，資料庫對於分析型工作負載有一定的最佳化，但是對於事務型工作負載，資料庫需要建一個索引。在這個時候，我們就應用了建立八個索引的操作。在這個操作上，不光是說我們這個模型準確預測操作之後，對這個資料庫有什麼樣的好處，並且應用這個資料庫操作的時候，我們也預測到了這個操作對這個資料庫有什麼樣的影響，因為資源競爭的關係，他的延遲其實在增加。

不僅如此，這個分解式的建模方式還能夠去預測具體的某一個資料庫的查詢變慢或者變快的原因。比如說資源怎麼樣增加？或者是某一個查詢因為這個多維的索引怎麼樣繼續加速？這些具體的對於某一個資料庫的各個部分都能進行準確的預測，我覺得最終對一個自治資料庫去高效進行自動化操作，有非常多的幫助。

結語

稍微總結一下，我們認為對於資料庫進行了行為建模，構造模型去預測各種資料庫的自動化操作的分銷和收益，對於建立一個自治資料庫，是一個基礎性的步驟。我們今天介紹了一種解構式/分解式的對於資料庫進行行為建模的方式，尤其是我們用各個執行器去對每一個資料庫的操作單元去收集足夠的訓練資料，然後去建立準確的模型。

還有一點非常重要，就像在機器學習資料裡觀察到的，現在很多機器學習的應用都是以資料為中心。資料對機器學習的效果有大大的影響。我們也觀察到很多時候如果是應用機器學習或者人工智慧的技術在資料庫裡面，怎麼樣系統、高效的去搜集高質量的訓練資料，對最終模型的準確度、智慧度也是至關重要的。

以上為馬林老師上期直播的全部分享實錄，希望大家有所收穫！

第三期 Paper Time 由武漢大學計算機學院副教授王勝為大家帶來“開放式時空大資料助力智慧公交路線規劃”的分享。

本週三晚 19:00

我們 Paper Time No.3 不見不散

歡迎大家微信掃描上方二維碼預約報名~