核心創新,這才是國產資料庫該有的樣子
缺乏自主的關鍵技術是國產資料庫被詬病最多的痛點。
眾所周之,國產資料庫中,絕大多數是基於開源資料庫改造的,尤其是基MySQL或 PostgreSQL改造的居多,這本身無可厚非。
自研,並非只有從0開始完全自研一條路,基於開源資料庫做半自研,然後逐漸深入關鍵核心模組,直至最終完全掌控開源資料庫,也是自研。但是,這絕不是在開源資料庫上穿個“衣”帶個“帽”。毫無疑問,在資料庫市場中,自研、核心創新、核心業務系統等詞被濫用了。
那麼,基於開源資料庫的國產資料庫中,到底有沒有,具有自己的技術創新,甚至核心級創新的產品呢?答案,當然是有的。
今天,老魚就想來聊一聊openGauss的技術創新,為此,老魚採訪了openGauss 技術委員會主席李國良,openGauss開源資料庫首席架構師黃凱耀,聽他們說一說openGauss核心與架構技術創新的故事。
李國良,清華大學計算機系副主任、教授、博士生導師。在資料庫會議和期刊上發表論文150餘篇,他引10000餘次。獲得了VLDB 2017 Early Career Research Contributions Award(亞洲首位)、IEEE TCDE Early Career Award(亞洲首位)。SIGMOD 2021大會主席,VLDB 2021 Demo 主席,ICDE 2022 Industry Chair,獲國家科技進步二等獎、江蘇省科技進步一等獎。
黃凱耀,openGauss開源資料庫首席架構師,負責openGauss的技術規劃與產品設計工作,在資料庫高效能架構、高可用架構、OLTP效能最佳化、OLAP效能最佳化、一體化架構、軟硬協同等領域有豐富的理論、工程與實踐經驗。
什麼是資料庫核心?學過資料庫的都知道,核心通常指資料庫最核心的部分,比如:最佳化器、解析器、執行器、儲存引擎等。
openGauss對核心如何界定?老魚找到一張官方圖:
如上圖,粉色的部分就是openGauss界定的核心部分,包括執行緒管理、通訊管理、SQL引擎、儲存引擎、安全管理、AI。那麼,openGauss在核心上都有哪些創新?其實,上圖已經能看出一部分東西。
眾所周之,openGauss核心早期衍生自PostgreSQL-XC,但如今,openGauss與PostgreSQL-在架構和核心上,已經有了極大的差異。
如上圖,openGauss執行模型,採用執行緒池模型。而PostgreSQL是程式模型。這麼改有什麼好處?程式模型,資料庫程式透過共享記憶體實現通訊和資料共享,每個程式對應一個併發連線,這就存在高併發下,程式切換效能損耗,導致多核擴充套件性問題。而執行緒池技術的整體設計思想是執行緒資源池化、並且在不同連線之間複用,因此,高併發連線切換代價小,記憶體損耗小,執行效率高。
李國良說,openGauss尤其在核心的最佳化器、執行器、儲存引擎方面,做了很多的改進和最佳化,與傳統的關係型資料庫,有了本質區別。
儲存引擎方面,openGauss實現儲存引擎融合,即一套架構支援多種儲存模式。openGauss支援多引擎(行儲存引擎、列儲存引擎、記憶體引擎),而PostgreSQL僅支援行儲存引擎。看起來只是多支援了2個引擎,但其中涉及很多關鍵技術。比如:openGauss行儲存引擎採用原地更新(in-place update)設計(又名:Ustore儲存引擎),追加寫引擎(HEAP),支援MVCC(Multi-Version Concurrency Control,多版本併發控制),同時支援本地儲存和儲存、計算分離部署方式。
原地更新相比非原地更新有什麼好處?李國良給老魚打了個比方,簡單的說,非原地更新是一張表一直往上加,有刪有增,維護這張表代價非常大。openGauss 核心此前的版本使用的行儲存引擎是Append Update(追加更新)模式,追加更新對於業務中的增、刪以及HOT(Heap Only Tuple) Update(即同一頁面內更新)有很好的表現,但對於跨資料頁面的非HOT UPDATE場景,垃圾回收不夠高效,因此,Ustore儲存引擎應運而生。
眾所周知,最佳化器的好壞會直接決定關係型資料庫的強弱,最佳化器一般分為RBO(Rule-Based Optimizer)基於規則的最佳化器和CBO(Cost-Based Optimizer)基於代價的最佳化器,PostgreSQL支援CBO,openGauss支援CBO,SQL by pass。
雖然都支援CBO,但對複雜場景的最佳化能力是完全不同的。李國良說,openGauss在最佳化器的CBO上做了很多技術創新。首先,openGauss新增了很多查詢重寫規則,查詢重寫最佳化;其次,openGauss做了很多CBO代價的調優模型,適應不同場景;最後,openGauss加了基於機器學習的代價估計方法和最佳化演算法,使得最佳化器更智慧,適用於更多、更全面的複雜場景。
Sql-bypass是openGauss針對OLTP場景開發的一個輕量化執行器,它解決的是什麼問題?在典型的OLTP場景中,簡單SQL查詢佔了很大部分比例。試想一下,如果一個簡單的SQL查詢因為複雜的CBO邏輯,而消耗不必要的CPU資源浪費執行時間,那肯定是不行的。SQL by pass就是為了加速這類查詢設計的,可以極大地縮短執行器通用框架處理邏輯,極大地提升執行的效能。
執行器方面,為了提高SQL的執行速度,解決傳統資料處理引擎條件邏輯冗餘的問題,openGauss執行器引入了自適應實時編譯(Codegen)技術,其核心思想是為具體的查詢生成定製化的機器碼代替通用的函式實現,並儘可能地將資料儲存在CPU暫存器中。
總的來說,openGauss核心創新圍繞“四高”原則,即:高效能、高可用、高安全、高智慧。比如:高效能,openGauss聚焦了很多新型技術,包括NUMA-Aware技術、智慧最佳化技術、核心並行執行的技術,這些都是在核心創新方面引領的一些新型技術。
高智慧,在資料庫核心方面涉及到很多最佳化技術,包括很多最佳化NP問題,以及代價估算技術。傳統方式都是基於一些獨立性假設、均勻分佈假設,這導致估算結果非常不準確,而openGauss透過眾多智慧技術(智慧索引技術、智慧資料化分析技術、智慧最佳化核心技術)提升準確性、提升資料庫核心最佳化效率,提高可複製性。
(密態資料庫總體架構)
高安全,是openGauss非常重視的一個特性,openGauss引領了防篡改、全密態資料庫發展,也得到了一些POC的測試。此後,openGauss會持續構築這些能力,打造安全、穩定的資料庫密態核心,達到商用產品化標準,保護使用者敏感、隱私資料的全生命週期的安全。
黃凱耀則給老魚分享了4個架構創新,工具創新的故事,分別是外掛化架構、可觀測核心架構、資源池化架構、資料安全架構,而這四個架構創新是基於使用者場景驅動的,解決的是易遷移、易運維、易開發、易擴充套件的剛需問題。
篇幅所限,本文只解析外掛化架構及可觀測核心架構。
黃凱耀告訴老魚,外掛化架構的提出,是為了易遷移的目標,也就是為了實現方便簡單的把其它資料庫往openGauss遷移。為了達成這個目標,openGauss設計了資料庫的外掛化架構。首先,在計算引擎這一層上面,定義了資料庫的擴充套件點。資料庫核心開發者可以基於這些擴充套件點,去實現其它資料庫語法的相容外掛。
同時,為了更方便支援應用開發者把原有的資料庫遷移到openGauss上,在核心層面,openGauss實現了SQL相容性評估外掛。基於應用提供的SQL語句,去呼叫相應的資料庫外掛,基於該外掛的能力,對SQL語句進行評估並得出可讀性很強的評估報告,為什麼說可讀性很強?因為,它是從其它資料庫遷移到openGauss的遷移建議的中文提示,而非模糊化的英文提示。
第二個故事,是可觀測架構。可觀測與可運維是社群開發者對openGauss提出的另外一項重大訴求,並不亞於遷移方面的呼聲。黃凱耀說,解決的問題是怎樣對openGauss進行更加全面系統地效能監控和故障診斷。
搞過資料庫運維的人都知道一個棘手的場景,就是業務部門反饋系統慢,但DBA從有限的資料庫監控指標上卻看不出任何問題。因此,加強資料庫可觀測性是降低資料庫使用成本一個非常重要的手段。
相較而言,要實現全棧的可觀測、可跟蹤架構,技術難度很高。因為,這不僅涉及到資料庫核心,資料庫運維,還涉及作業系統核心等,黃凱耀說。
openGauss透過資源消耗鏈的角度,把整個系統的資源消耗分為三類:
儲存資源消耗鏈
網路資源消耗鏈
CPU記憶體資源消耗鏈
在每一個資源消耗鏈上,可以透過上鑽下探的方法,去實現系統效能問題的最佳化或者故障問題的定位。透過這種全面系統的上鑽下探,就可以實現一個良好的可觀測架構。
而這背後,需要對資料庫核心程式碼做更多的增強,並且僅資料庫核心增強還不夠,還需要藉助作業系統最先進的eBPF技術,才可能提供更全面、更豐富的可觀測資料。而有了豐富的資料,診斷系統就可以基於這些資料做基於專家模型的推理或AI診斷。
通常,從一個業務指標,關聯到資料庫等待時間指標,再關聯到作業系統的資源消耗指標,是目前主流資料庫所提供的可觀測能力。但openGauss更進了一步,直接把資料庫核心中的熱點函式也追蹤起來,這樣,實現了在等待事件之下的進一步的觀測與診斷。
因此,openGauss可觀測架構實現了從觀測資料到診斷定位的全鏈條打通。
實際上,openGauss核心與架構技術創新的故事遠不止這些,本文也只是管中窺豹,無法一一列舉。比如:在Oracle 21c中才出現的區塊連結串列 ,在openGauss 2.0中就已經被實現 。當然,即便如此,openGauss依然還需要持續提升和完善,創新之路上還有很長的路要走。但本文想表達的是,無論是核心創新,還是架構創新,事實上,無論是那種架構的創新,最終都與核心息息相關,只有完全掌握消化核心並在此基礎上持續創新,才算是真正的自主可控。
資料庫發展了半個多世紀,在舊的資料庫技術上,中國與西方差距其實不大,大家都知道怎麼去做。李國良說,但在軟體工程能力上,我們與國外是有差距的,這需要我們努力,而超越機會更大的是創新性,我們要去引領創新,而不是跟隨別人創新。
因為,你走別人的路,一直跟別人學,是永遠不可能成功的。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31545803/viewspace-2907511/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 這才是!21 世紀的 API 文件該有的樣子!API
- 這才是國產BI軟體該有的財務資料分析效果
- 這才是免費OA辦公系統該有的樣子
- 這才是數字孿生汙水處理廠該有的樣子
- 這就是現代php該有的樣子(一)PHP
- 這就是現代php該有的樣子(二)PHP
- 新華三全球首發智原生Wi-Fi 7 AP,這才是未來網路該有的樣子
- 這就是我心目中獨立遊戲應該有的樣子遊戲
- 阿凡達壓軸亮相騰訊遊戲釋出會!這才是3A手遊大作該有的模樣遊戲
- 「信創」風口,國產資料庫的新機遇資料庫
- 識人、識貨、識場—— 這就是智慧零售該有的樣子
- EF Core助力信創國產資料庫資料庫
- 方案|美創科技資料庫國產信創改造方案資料庫
- 鬧鐘、相框、視訊通話、助眠神器,不務正業的Echo Spot才是智慧音響該有的樣子
- Oracle資料庫遷移到國產資料庫核心難點解析 | 聯盟釋出Oracle資料庫
- 【國產資料庫名錄一覽】竟有這麼多國產資料庫產品?很多沒聽過資料庫
- TapData 信創資料來源 | 國產信創資料庫達夢(Dameng)資料遷移指南,加速國產化程序,推進自主創新建設資料庫
- 網站創新才是硬道理網站
- 國產資料庫源流史:AntDB資料庫資料庫
- 分散式改造進入核心深水區,國產資料庫如何渡河分散式資料庫
- 某城商行核心系統國產資料庫選型方法論資料庫
- 某保險公司的核心繫統國產資料庫升級之路資料庫
- 這才是網站盈利的核心問題網站
- 除了一鍵啟動Copilot,什麼是AI PC本來該有的樣子?AI
- 這樣也能連線資料庫[zt]資料庫
- 創意AI將給電子遊戲帶來怎樣的創新?AI遊戲
- 聊新基建、信創,資料庫不能少!資料庫
- 金融業資料庫自主創新之路資料庫
- 國產資料庫知多少?資料庫
- 國產資料庫調研之——AntDB資料庫資料庫
- 資料庫系統概述之國產資料庫資料庫
- 國產多維資料庫NeuralCube!中國人自己的大資料底層核心技術!資料庫大資料
- DTCC2022精彩預告 | 趙培:GoldenDB聚焦核心技術創新,打造國產分散式資料庫第一品牌Go分散式資料庫
- 國產資料庫廠商如何掘金50萬億新基建市場?資料庫
- 2019,國產資料庫元年開啟新紀元資料庫
- 新資料時代,科研需要什麼樣的創新基礎設施
- 通過現有的資料庫備份建立新的資料庫資料庫
- 原創|高逼格企業級MySQL資料庫備份方案,原來是這樣....MySql資料庫