摘要:SIGMOD數據管理國際會議是數據庫領域具備最高學術地位的國際性學術會議,位列數據庫方向的三大頂級會議之首(其次是VLDB及ICDE)。OceanBase的核心團隊成員有幸參與到了SIGMOD 2018會議中,本文由螞蟻金服OceanBase研究員日照爲你們帶來最專業、最前沿的大會獨家報道。
接下來幾天,咱們將爲你們持續帶來SIGMOD系列論文解讀,如下是精彩預告:算法
1. 細微處見匠心—2018 SIGMOD論文之傳統SQL領域數據庫
2. Joining the best—2018 SIGMOD論文之JOIN系列api
3. 新硬件的舞臺—2018 SIGMOD論文之硬件發展下的數據庫系統安全
本文做者:日照markdown
現任螞蟻金服OceanBase研究員,OceanBase初創成員之一,負責OceanBase 0.5 / 1.0 / 2.0版本的技術架構,著有《大規模分佈式存儲系統:原理解析與架構實踐》。
網絡
正文:session
今年的SIGMOD第一次在美國南部的石油城市休斯頓舉辦。提到休斯頓,大多數知道它以能源、航空和運河而聞名於世,固然,對於不少中國人來說,最知名的仍是姚明所在的休斯頓火箭隊。現在,這座城市卻由於SIGMOD這一數據庫領域的頂級盛世而再次熱鬧非凡。數據結構
這一次,來自全球各地的800名參會者,濟濟一堂,共襄盛會,於休斯頓,共同見證數據庫行業的飛速發展,探討業界最領先的數據庫應用方向。架構
(圖片來源:SIGMOD 2018官網 https://sigmod2018.org/)
框架
本屆SIGMOD和PODS會議合辦,一共持續6天,其中3天爲正會,其它時間是PODS和workshop。今年總共有90篇學術論文和15篇工業論文,參會的中國人衆多,而發表論文的中國人數量也很是可觀,阿里巴巴、螞蟻金服和華爲做爲中國企業贊助了本次會議,中國已經在最前沿的數據庫國際性學術會議中佔據了重要的一席。
SIGMOD會議包含2個主題演講(keynote),15個學術報告會(research session)以及4個工業報告會(industry session)。數據庫是一門側重工程的實踐類科學,而今年的會議安排和去年最大的差異在於增長了專門的industry session:來自Amazon、Microsoft、Alibaba等工業界的分享都極具含金量。
Alibaba做爲贊助商表明組織了一場主題爲「數據驅動及機器學習賦能的自治數據庫系統」的workshop,內容分爲兩個部分:第一部分由集團數據庫技術負責人分別介紹了阿里巴巴數據庫和計算平臺等產品,如何依靠創新解決阿里巴巴業務場景中傳統數據庫面臨的挑戰,第二部分則是邀請了五位學術界知名教授做爲嘉賓分享了他們在「AI+數據庫」領域的工做。
SIGMOD會議主題包括傳統數據庫事務和索引結構、查詢處理和優化、並行數據庫、圖數據庫、空間數據庫、近似處理和類似度查詢、數據集成與挖掘、安全與隱私以及最近幾年比較熱門的雲數據庫、新型硬件和機器學習。OceanBase參會人員關注的領域主要涉及事務和索引結構、查詢處理和優化、並行數據庫,雲數據庫、新型硬件和機器學習。本文旨在解讀工業界論文,後續的文章將進一步解讀這些領域的其它論文。
本次會議的最佳論文是CMU的"SuRF:Practical Range Query Filtering with Fast Succinct Tries」。布隆過濾器只適用於單行讀取(Get)操做,實際業務場景中OceanBase能夠經過對主鍵的前綴動態建立布隆過濾器來實現範圍過濾功能。這種方法不夠通用,論文中提出了一種新的數據結構,稱爲FST(Fast Succint Tries),除了用於過濾單行讀取,還能夠用來過濾範圍掃描(Scan)。FST在以前的研究成果基礎上作了進一步優化,很好地平衡了查詢性能和內存佔用,尤爲適用於各類類LSM存儲引擎。
論文中還嘗試將FST集成到RocksDB,單個key的存儲空間只須要10~14個bit,經濟實用。最佳論文的第一做者是Huanchen Zhang,是一個華人。其實,SIGMOD大會從2015年開始,每一年最佳論文的第一做者都是華人,2015年的Yufei Tao,2016年的Feifei Li,2017年的Wenfei Fan。PODS的最佳論文是「Entity Matching with Active Monotone Classification」,第一做者仍是YufeiTao。
今年的兩場keynote分別是EricBrewer(Google)的「Kubernetes and the New Cloud」以及Pedro Domingos(華盛頓大學)的「Machine Learning for Data Management:Problems and Solutions」。去年的兩場keynote分別是OLTP內存數據庫以及AQP近似查詢處理,聚焦在數據庫領域自己,而今年兩場keynote嚴格來說都不屬於數據庫領域的範疇。
說實話,這兩場keynote都沒有給我留下特別深的印象。其中,Eric Brewer的演講大部分是Kubernetes的產品介紹。聽演講的過程當中,我在思考一個問題:阿里巴巴以及不少互聯網公司也有相似的容器化產品,爲何Google最後成爲了標準?是由於技術,是由於生態,又或者是由於Eric Brewer等Google研發人員的業界影響力。這個問題我沒有答案,咱們須要不斷地探索,才能明白知足某個公司、某個行業、甚至多個行業的需求與成爲全行業事實標準之間的巨大鴻溝。
從數據庫發展趨勢的角度看,我認爲今年SIGMOD主要體如今以下幾個方面:雲數據庫、新型硬件,自治數據庫、AI+數據庫,圖數據庫。
雲數據庫:除了EricBrewer關於Kubernetes的keynote,還有一個關於雲數據庫的industry session。Amazon Aurora從理論和實踐上證實公有云場景能夠重構關係數據庫底層架構,Vertica這樣的老牌OLAP系統也上雲了。
新型硬件:存儲介質從SSD、大內存到非易失性內存,RDMA、GPU、FPGA這樣的硬件技術逐步普及。此次SIGMOD除了一場關於新硬件的research session,即「Databases for Emerging Hardware」,還有一場專門的workshop DaMoN(DataManagement on New Hardware)。Oracle Labs也有一個RAPID項目嘗試作一個基於專用的數據處理芯片的SQL執行優化框架,不過經過內部交流了解到,專用硬件在Oracle Labs前景也不明確,RAPID的項目不會集成到Oracle內核,只會考慮MySQL。
自治數據庫:自治數據庫在學術界和工業界都很熱,Oracle數據庫最近幾年最重要的研發工做就是自治數據庫。CMU的Andrew Pavlo團隊這幾年在學術界特別活躍,每一年都能抓住熱點並在SIGMOD和VLDB發表多篇論文,今年的最佳論文就是出自這個團隊,他們在自治數據庫上作的工做發表在「Query-based Workload Forecasting for Self-Driving DatabaseManagement Systems」。
AI+數據庫:這幾年國內不少高校的數據庫團隊都轉型大數據和AI了,北大數據庫實驗室在此次SIGMOD會議上也發表了兩篇AI方向的論文,可見AI的火熱。AI + System是這兩年興起的一個熱門方向,Google Jeff Dean團隊提出的Learned Index很好地利用AI統計實際數據的規律來設計更加高效的索引結構。此次SIGMOD除了Learned Index相關論文外,還有一個專門的關於機器學習的research session「Machine Learning & Knowledge-base Construction」。目前的AI和數據庫的結合仍是比較淺的,將來是否能夠用AI的方法來改進數據庫內核的核心組件,例如優化器,這點我不太肯定但充滿期待。
圖數據庫:去年SIGMOD的best paper就是關於圖計算的「ParallelizingSequential Graph Computations」,第一做者是Wenfei Fan,今年他們團隊又發表了多篇關於圖數據庫的paper,今年SIGMOD的research session和industry session都有關於圖數據庫的論文。
總體上看,傳統關係數據庫內核的突破性工做變得愈來愈少,大部分研究工做是多個領域相結合的成果。相對來說,工業界的實踐類論文對於工程人員更有借鑑意義。下面是我對本次大會industry session八篇論文的解讀。
Aurora團隊在2017 SIGMOD會議上發表了「AmazonAurora: Design Considerations for High Throughput Cloud-Native RelationalDatabases」。
Aurora數據庫採用存儲計算分離的技術架構,相比單機MySQL/PostgreSQL的主要優點有兩點:一是無損容災,將數據庫容災問題轉化爲更加成熟的分佈式存儲系統的容災問題,而類Paxos協議在分佈式存儲中普遍使用;二是存儲可擴展。存儲單元是分佈式的,能夠很容易突破單機存儲容量限制,而不須要涉及到複雜且性能更差的分佈式事務。固然,事務是不可擴展的,Aurora團隊正在開發的Multi-Master功能用於解決事務的擴展性問題。
Aurora提出了「the logis the database」的設計理念,數據庫實例往底層存儲只寫redo日誌,將日誌回放等操做下推到底層存儲,從而大大下降網絡開銷。去年SIGMOD的Aurora論文側重點在於設計理念和總體架構,而今年SIGMOD的Aurora論文側重幾個關鍵點的實現方案,包括寫流程和宕機恢復,快照讀取,如何避免讀取操做訪問多數派副本,以及成員變動。Aurora不須要使用兩階段提交協議,它的架構相似傳統關係數據庫的Oracle RAC,並在RAC基礎上經過日誌下推到存儲層來進一步優化。建議讀者結合去年的Aurora論文一塊兒閱讀這篇論文,去年的論文至關於整體設計方案,今年的論文至關於最核心的幾個模塊的概要設計方案。
SCOPE是微軟的大數據處理平臺,相似阿里巴巴的MaxCompute。大數據平臺一個常見的問題是有大量的重複計算,可能的緣由包括schema設計不合理,用戶互相拷貝腳本代碼,等等。這篇論文提出了一個對重複計算進行在線物化的框架CloudView,有兩個主要的特色:一個是在線建立物化視圖,另一個是借鑑了關係數據庫的漸進式優化思路(progressive query optimization),實現了反饋迴路(feedbackloop),將運行時收集到的統計信息反饋到優化器。
做爲一篇工業界論文,這篇文章還給出了不少SCOPE的運行數據和一些經驗教訓,對於阿里巴巴和其它大數據平臺都有不錯的借鑑意義。固然,物化視圖裏面有一個經典的難題,即在線更新的處理,這篇論文簡單地將物化視圖直接失效,這種作法還不夠精細。
3."Columnstoreand B+ tree - Are Hybrid Physical Designs Important?"
HTAP混合負載是工業界的一個熱點,通常來講,B+樹用於OLTP業務,列存用於OLAP業務。然而,真實的業務場景中很難區分workload究竟是OLTP仍是OLAP,主流的OLTP商業數據庫都會有比較強的OLAP分析能力。這篇論文研究如何在同一個數據庫中混合使用B+樹和列存這兩種不一樣類型的索引,它首先經過一個benchmark對這兩種索引在各類讀寫場景下的性能作了一個量化對比,接着講解SQL Server中使用的Database Engine Tuning Advisor來動態地選擇和推薦索引。
論文最後的測試代表,Hybrid方案的性能每每是優於單一的B+樹或者列存的,不過這件事情最關鍵的點還在混合負載這一假設的適用範圍,實際場景中我看到的OLTP業務每每只有不多一些分析型查詢,而專門的OLAP業務每每幾乎都是分析型查詢。
通常來說,數據庫的容量規劃都是針對峯值壓力,然而,天天高峯期和低峯期的壓力差異很是之大,實際生產系統中在線服務的利用率也都很低。P-Store提出,能夠經過動態預測負載來提早對數據庫擴容或者縮容,而不是等到負載發生變化以後再彈性伸縮。這篇論文最關鍵的地方在於提出了一個頗有意思的AI和數據庫相結合的問題,固然,論文中也給出了算法思路,即如何尋找一條具備最小成本的路徑,使得系統有效能力老是大於實際需求。彈性伸縮有一個經典的難題,擴容/縮容操做的代價,在share-nothing架構中由於拷貝大量數據實用性不佳,每每更加適合存儲計算分離的架構。互聯網在線服務通常均可以借鑑P-Store的思路,固然,對於極端的場景,例如一年一次的雙十一,流量突增到日常的幾十倍甚至上百倍,我和論文做者在Demo環節作了簡單交流,他們沒法解決也不許備解決。
Pinot是Linkedin開源的一個大數據分析系統,相似Apache Druid。Pinot採用Lambda架構,將實時數據流和批處理數據分開處理,支持Kafka準實時數據寫入以及Hadoop批量數據導入,支持類SQL查詢。這篇論文介紹了Pinot的技術架構、查詢執行流程、存儲索引結構,等等。相似的產品比較多,包括Apache的Druid和Kylin,Google Dremel以及其開源實現Apache Drill,其中,我認爲技術作得最好的是Google Dremel,值得深刻研究,其它論文能夠結合起來一塊兒閱讀。
Vertica是一個分析型數據庫,底層存儲分爲兩個部分,一部分爲針對寫優化的WOS(Write Optimized Store),一部分爲針對讀優化的ROS(Read Optimized Store),分別對應LSM存儲引擎中的MemTable和SSTable,且ROS採用列存實現,須要按期執行Tuple Mover操做,對應LSM存儲引擎中的compaction操做。
Eon Mode是Vertica的雲版本,有兩個主要的架構變化:一個是存儲計算分離,抽象了一層通用的文件系統訪問接口(UDFS API)支持本地文件系統或者S三、HDFS等通用分佈式文件系統;還有一個是線性可擴展的分佈式架構,支持動態擴容縮容,涉及的改造點包括數據劃分、容錯以及SQL優化和執行。採用存儲計算分離架構後,Tuple Mover操做也須要相應調整,之前的Enterprise版本每一個副本都須要執行Tuple Mover,如今只須要動態選擇一個副本執行Tuple Mover便可。另外,Eon Mode再也不支持WOS,不過我認爲這是Eon Mode的實現問題致使的。
這篇論文出自Azure SQLDatabase團隊,提出了一個很好的問題:在公有云環境下預測一個數據庫實例會在多久以後被刪除,從而將數據庫實例分紅兩類:short-lived(<=30天)以及long-lived(>30天)。
論文中採用了機器學習中的隨機森林算法,涉及的特徵包括:實例建立時間(例如週末建立的實例頗有可能由程序自動建立),數據庫實例的名稱(例如名字有意義的數據庫實例存活時間相對更長),數據庫大小,數據庫版本升級頻率,數據庫實例類型(Basic / Standard / Premium),用戶以前建立過的數據庫實例存活時間,等等。這種分類對於雲數據庫的資源調度、用戶隔離以及平常運營操做都有不錯的指導意義。另外,這篇論文還給出了大量Azure SQL DB團隊的運營數據,有很好的參考價值。
數據庫上雲面臨兩個主要的問題:一個是數據庫遷移,另一個是應用程序遷移。對於第一點,各個雲服務產商都有成熟的工具;對於第二點,目前沒有成熟的解決方案。Hyper-Q是一個能夠將不一樣數據庫系統的SQL請求互相翻譯的中間件,目標是應用代碼無需修改直接上雲。
這件事情的難度很大,並且極其繁瑣,論文中把SQL翻譯分紅三大類:1) Translation:簡單的語法修改,例如關鍵詞替換;2) Transformation:將用戶查詢轉化爲目標數據庫相似的功能,並對結果作必定的處理,例如不一樣數據庫的NULL列排序方式不一樣;3) Emulation:目標數據庫沒有相似的功能,須要在應用層模擬實現。演講者對Hyper-Q的能力很是有自信,讓人感受是什麼都能作,不過我並無這麼樂觀,可能只是一個簡單的數據類型或者語義的不一樣都須要作大量的工做,也可能帶來嚴重的性能問題。
想了解更多?您能夠關注OceanBase公衆號回覆關鍵詞「OB」,快速加入OceanBase數據庫技術交流羣!