如何評價cmu-db的peloton資料庫?

如何評價cmu-db的peloton資料庫,The Self-Driving Database Management System,當前實現的完善程度,優缺點,以及是否是下一步資料庫的重要發展方向?


一個非常有技術前瞻性的資料庫!

1. 方向正確。

Oracle老廠都靠Self-Driving來拯救自己了,瞧瞧這solgan:The World』s #1 Database Is Now the World』s First 「Self-Driving」 Database

2. 適應潮流

WBL:

隨著硬體的發展(NVM),IBM那幾十年的資料庫設計套路ARIES終於有所改變了,相對於WAL,PelotonDB提出了WBL。

這個技術比較簡單但是對新硬體很友好,說明Pavlo這種一流大嬸對資料庫的本質問題有著非常深刻的認識,研發資料庫的功力不在於我會寫資料庫(傳統資料庫理論已經很成熟了),而是在不同硬體等條件下認識到問題本質,實現靈活變通,PelotonDB做到了這點。

行列混合:

對row/column的存儲在底層進行處理,這也是self的一個重要點。而不是要麼row,要麼column,或row in memory row, column in disk。

PelotonDB主要是靠學生研發,也得到了Intel、Samsung的支持,但是發展還是較慢的,而且各個模塊還處於初級階段,還有不少的路要走: cmu-db/peloton

但是,目前看代表著未來... ...


做過科研原型應該可以更好的理解它的意義。新硬體上的新系統。也許某些具體特性可以被產品借鑒。詳細內容建議看它的主頁和論文。他們實驗室有華人畢業生,知道的可以請來回答一下啊。


首先放上cmu/pelotondb研究小組的鏈接。

PelotonDB最重要的特性是將數據挖掘技術引入到了資料庫管理系統中,通過感知應用工作負載自適應調整底層存儲方式, 進而達到融合OLTP/OLAP的效果, 實現無人工干預的自動調優資料庫管理系統: Self-Driving Database Management Systems。

從論文的圖中我們可以看出,系統基於歷史數據進行模型構建,將工作負載按照聚類的方式分成若干類,然後對接下來的查詢使用RNNLSTM訓練和預測落在各個工作負載上的比例,根據預測結果調整存儲結構/數據劃分/執行參數, 以期最小化查詢時延。

下面重點關注下數據布局。

OLTP場景由於需要高性能的寫入,最佳存儲形式當屬於行存(NSM, Nary Storage Model),常見於關係行資料庫; 而OLAP 場景由於需要對一些特定的列進行快速掃描分析,為了保證Cache的友好性和減少讀放大,最好使用列存(DSM, Decomposition Storage Model ),常見於NoSQL;現實場景中通常兼顧存儲和分析,所以又引入了上述兩種存儲的融合方式: FSM(Flexible Storage Model ), 又稱為HTAP (Hybrid Transactional/Analytical Processing)

關於行存和列存的研究由來已久,2001年VLDB上的Weaving Relations for Cache Performance一文就已經有深入探討,這篇文章提出了PAX(Partition Attributes Across)數據布局方式, 基本思想就是對於一個關係, 系統首先按頁(Page)的方式存儲數據,類似於NSM, 而在頁(Page)裡面使用了一種 mini page 的方式,將關係的各個屬性存儲到不同的 mini page 裡面, 類似於DSM。從整體來看,便是一個HTAP系統, 這在最新的Google Spanner(SIGMOD2017)也有所應用。而在SIGMOD2016會議上, peloton小組進一步發展了HTAP 設計理論: Bridging the Archipelago Between Row-Stores and Column-Stores for Hybrid Workloads, 最主要的是可根據工作負載自適應地在物理結構上將數據切分成不同的存儲布局,而在邏輯結構上保持一致。物理層存儲體系為: tile tuple → physical tile → tile group → table ,結構如下圖所示:

物理層這樣的劃分將非常容易地實現FSM目標。熱點數據最先以行存的方式存儲,當數據逐漸變冷,會演變成列式存儲。但直接使用物理層對於查詢並不友好,數據分布在不同的Tile里, 並且還會變化, 因此必須引入邏輯層來封裝成統一的介面。邏輯層隱藏了物理層的具體實現,邏輯層的每個列可以指向一個或者多個物理層的列,每個邏輯層列裡面存儲的是 tuple 在物理層裡面的偏移位置。結構如下圖所示:

有了物理層和邏輯層, 我們就可以定期地對每個table計算出最優數據布局, 然後進行重構。在論文中,計算主要通過監控器隨機的對查詢進行採樣統計,減少開銷,對冷數據進行重構。

最後總結一下, cmu-db小組的資料庫優化工作重點在於自適應動態調整上, 通過運行時動態配置技術獲取系統的最佳性能,這點啟發意義非常重要, 在現在的NewSQL領域會逐漸得到應用。


推薦閱讀:

從編程語言設計的角度,如何評價SQL語言?
一條LEFT JOIN+ORDER BY的sql語句優化問題?
為什麼MySQL對SQL標準的支持那麼不誠意?
SQL 設計得爛嗎,諸如redis,nosql又該如何選擇?
什麼是最好的oracle sql 開發工具?

TAG:資料庫 | SQL | 內存資料庫 | NewSQL | 分散式資料庫 |