谷歌論文yyds，你怎么看TiDB之后又一國產(chǎn)數(shù)據(jù)庫橫空出世？

時間：2023-03-13 09:12:01 | 來源：電子商務(wù)

時間：2023-03-13 09:12:01 來源：電子商務(wù)

出品|開源中國

文|大東

2012~2013 年，Google 相繼發(fā)表了 Spanner 和 F1 兩套系統(tǒng)的論文，讓業(yè)界第一次看到了關(guān)系模型和 NoSQL 的擴(kuò)展性在一個大規(guī)模生產(chǎn)系統(tǒng)上融合的可能性，這種新型的數(shù)據(jù)庫架構(gòu)被行業(yè)分析師 Matthew Aslett 稱為“NewSQL”。

隨后的幾年里，NewSQL 數(shù)據(jù)庫迎來大爆發(fā)，各大云服務(wù)廠商都基于 Spanner+F1 論文推出各自的 NewSQL 數(shù)據(jù)庫服務(wù)，開源領(lǐng)域也涌現(xiàn)出 CockroachDB 和 TiDB 這樣的人氣項目。

近日，浪潮宣布開源一款 NewSQL 分布式數(shù)據(jù)庫 ZNBase，引發(fā)了社區(qū)開發(fā)者的關(guān)注。據(jù)悉，浪潮的 ZNBase 數(shù)據(jù)庫同樣參考自谷歌 Spanner+F1 系統(tǒng)的設(shè)計思想，具備強(qiáng)一致、高可用分布式架構(gòu)、分布式水平擴(kuò)展、高性能、企業(yè)級安全等特性。

而作為一款主打 HTAP 混合場景的分布式數(shù)據(jù)庫產(chǎn)品，前有 TiDB 獲資本市場青睞并霸榜國產(chǎn)數(shù)據(jù)庫，后有阿里、百度等廠商陸續(xù)推出的自家 HTAP 分布式數(shù)據(jù)庫產(chǎn)品，浪潮的 ZNBase 又將憑借哪些優(yōu)勢在國內(nèi)市場中立足？

什么是 ZNBase ?

據(jù) ZNBase 產(chǎn)品負(fù)責(zé)人陳磊介紹，ZNBase 是一個 HTAP 分布式數(shù)據(jù)庫，采用云原生分布式架構(gòu)，Share Nothing 所有節(jié)點全部對等，每個節(jié)點均是完整功能的數(shù)據(jù)庫節(jié)點，每個節(jié)點都包括 SQL 層、事務(wù)層、副本層和存儲層。SQL 層包括協(xié)議和語法解析、優(yōu)化器和執(zhí)行器，事務(wù)層主要負(fù)責(zé)分布式事務(wù)，副本層負(fù)責(zé)副本調(diào)度和使用 Raft 算法保證多副本一致性，存儲層采用 KV 存儲引擎 RocksDB 負(fù)責(zé)存儲數(shù)據(jù)。

ZNBase 首先支持 OLTP 場景，產(chǎn)品完整的支持 SQL 與事務(wù)，表數(shù)據(jù)自動的劃分多個 Range 分布在不同的數(shù)據(jù)庫節(jié)點上。因此使用 ZNBase 數(shù)據(jù)庫再大數(shù)據(jù)表也不需要人工分庫分表，數(shù)據(jù)庫集群會自動處理，應(yīng)用只需要當(dāng)作單機(jī)庫表使用即可。

在 OLAP 場景支持方面，在 SQL 執(zhí)行方面做很多偏向 OLAP 場景的優(yōu)化，包括算子并行、異步、矢量計算、RBO優(yōu)化器等，得益于產(chǎn)品的分布式架構(gòu)，可以利用多節(jié)點的計算能力，產(chǎn)品可以滿足業(yè)務(wù)應(yīng)用的 AP 需求。

ZNBase 沒有類似 TiDB 包含的集群管理模塊（Placement Driver ，簡稱 PD），每個節(jié)點就是一個完整的數(shù)據(jù)庫，在每個節(jié)點里同時包含 AP 和 TP 的能力，可以完成處理 SQL 請求，進(jìn)行 SQL 計算，以及數(shù)據(jù)存儲引擎的全部工作。再通過這種分布式的架構(gòu)把每個節(jié)點聯(lián)系起來，形成 ZNBase 的數(shù)據(jù)庫系統(tǒng)。

取自社區(qū)，回饋社區(qū)

前文提到，市面上已經(jīng)有一些比較成熟的分布式數(shù)據(jù)庫解決方案，其中不乏受到資本追捧的優(yōu)秀開源項目，那么浪潮的技術(shù)團(tuán)隊當(dāng)初決定要重新做 ZNBase 是出于怎樣的考慮呢？

據(jù)陳磊回憶，ZNBase 的研發(fā)團(tuán)隊最開始是浪潮內(nèi)部的大數(shù)據(jù)團(tuán)隊，集團(tuán)內(nèi)部不同單位之間有很多交流，他們發(fā)現(xiàn)其他的單位有很多的大數(shù)據(jù)量應(yīng)用。因為浪潮做信息化比較早，最開始集團(tuán)內(nèi)部用的是免費(fèi)的 MySQL，Oracle 單機(jī)版，DB2 單機(jī)版等。隨著數(shù)據(jù)不斷積累，數(shù)據(jù)量越來越大，團(tuán)隊開始面臨一些新的問題：要不要購買這些數(shù)據(jù)庫的升級版本，或者要不要再升級硬件，但這些都不能解決根本問題，到未來數(shù)據(jù)量發(fā)展到一定程度時，還是會出現(xiàn)瓶頸。于是浪潮大數(shù)據(jù)團(tuán)隊綜合多方述求開始探索解決方案。

最初經(jīng)過調(diào)研，團(tuán)隊嘗試過使用分布式中間件的方法。但對于其他業(yè)務(wù)部門來說，他們還是希望解決方案對業(yè)務(wù)代碼本身沒有侵入，并且中間件的維護(hù)也過于復(fù)雜。因為浪潮的業(yè)務(wù)更多是面向傳統(tǒng)企業(yè)客戶，這與很多在自己的業(yè)務(wù)中使用分布式中間件的互聯(lián)網(wǎng)公司不同?！拔覀兊臉I(yè)務(wù)以響應(yīng)客戶為優(yōu)先級，必須為這些客戶提供一套完整且易用的解決方案?！?

“后來，我們的團(tuán)隊了解到了谷歌發(fā)布的 NewSQL 技術(shù)路線，覺得這種分布式的關(guān)系型數(shù)據(jù)庫還比較適合我們。最初我們是在內(nèi)部引入 CockroachDB，這是谷歌 NewSQL 產(chǎn)品 Spanner 的開源版本。當(dāng)時 CockroachDB 剛剛發(fā)布不久，我們就一直在關(guān)注這個項目，也開始給浪潮內(nèi)部的一些業(yè)務(wù)應(yīng)用推薦這個項目。但剛開始用的時候這些業(yè)務(wù)部門多多少少會遇到一些問題，于是我們大數(shù)據(jù)團(tuán)隊就開始給他們做一些技術(shù)支持的工作，在這個過程中我們的團(tuán)隊也深入到 CockroachDB 社區(qū)參與貢獻(xiàn)，并為社區(qū)提交代碼?！标惱诮榻B。

而到了 2019 年初，浪潮大數(shù)據(jù)團(tuán)隊部分已經(jīng)加入云服務(wù)集團(tuán)團(tuán)隊，面臨各項業(yè)務(wù)上云的工作。這時云服務(wù)團(tuán)隊就希望他們把基于 CockroachDB 的分布式數(shù)據(jù)庫也上云。而此時正好趕上了 CockroachDB 官方為了限制 AWS 等云廠商修改了項目的 License，不能把 CockroachDB 當(dāng)做云服務(wù)提供。

“雖然我們能夠理解 CockroachDB Labs 的這種做法，但我們也需要維持自己的業(yè)務(wù)?！庇谑菆F(tuán)隊只能基于 CockroachDB 的非商業(yè)限制版本重新分支立項，并投入大量人力來維護(hù)和開發(fā)，也就成了現(xiàn)在的 ZNBase。“當(dāng)然，我們在這個過程中也收到了很多用戶的反饋，也根據(jù)這些反饋做了一些工作，包括 SQL 的分析性能增強(qiáng)和各種語法特性優(yōu)化等?！?

因為 ZNBase 整個分布式數(shù)據(jù)庫系統(tǒng)最初都是基于開源項目研發(fā)，所以在開發(fā)過程中，浪潮也積極地回饋上游的開源社區(qū)。據(jù)統(tǒng)計，浪潮的技術(shù)團(tuán)隊為 Cockroach DB、RocksDB、kubernetes 等項目社區(qū)提交了 commit 80 多個，issue 50 多個，參與代碼貢獻(xiàn)的開發(fā)者有 30 余人。

看好 Rust，考慮替換 Go

由于 ZNBase 是基于 CockroachDB 而來，所以使用的開發(fā)語言也是該項目原本的 Go 語言；存儲層則是基于 RocksDB 開發(fā)，因此使用的也是該項目原本的 C++。

Rust 語言近年來在社區(qū)中的聲量很高，不少大廠也開始在內(nèi)部大規(guī)模啟用 Rust 來替換 C++。被問到 ZNBase 是否考慮過在未來將 C++ 替換為 Rust 時，陳磊表示：“Rust 最近確實很火。我個人其實早在 2016 年，也就是 Rust 的 1.0 版本還沒有正式發(fā)布的時候就開始關(guān)注了，它確實是一門非常有潛力的編程語言，不過我們的工作內(nèi)容更多的是解決客戶的實際問題。但目前也仍然保持對 Rust 的關(guān)注?！?br>
陳磊認(rèn)為，Rust 近年來的火爆，更多的是一些大公司在用這門語言，比如國外的亞馬遜、微軟、谷歌，國內(nèi)的阿里、華為等，首先這些大公司自身的軟件規(guī)模足夠龐大，C/C++語言在內(nèi)存管理方面的問題難以解決，他們就可以引入 Rust 來解決這些內(nèi)存安全的坑。

事實上，ZNBase 作為一款新的產(chǎn)品，在選擇技術(shù)路線的時候也確實會需要考慮這種未來的趨勢，但目前 ZNBase 團(tuán)隊還沒有考慮到用 Rust 完全去重寫原本用 C++ 開發(fā)的 RocksDB?！癛ocksDB 本身就是一個 C++ 寫的東西，除非我們發(fā)現(xiàn) RocksDB 的哪些特性，或者哪些問題無法滿足我們的產(chǎn)品需求時，我們才會去嘗試改造它。”

值得一提的是，雖然 ZNBase 團(tuán)隊暫時不會考慮用 Rust 去替換掉 C++，但出于對性能的考慮，他們可能會用 Rust 將 SQL 層的 Go 語言替換掉?！癛ust 確實是一門性能很高的語言，從技術(shù)規(guī)劃的角度來說，后邊我們是有計劃把 Go 語言替換成 Rust 的，因為 Go 的性能確實沒有 C/C++ 和 Rust 高，我們可能會用 Rust 替換掉 SQL 層和副本層的 GO 語言?！标惱谡f。

浪潮的硬件優(yōu)勢

浪潮在國內(nèi)市場以服務(wù)器硬件方面的技術(shù)聞名，那么 ZNBase 團(tuán)隊是否在硬件方面做了特別的工作？

陳磊透露，在硬件這一塊他們確實做了一些工作，比如在硬件存儲方面，浪潮開發(fā)了一種新型 ZNSSD 存儲設(shè)備，團(tuán)隊也是第一時間拿到這款設(shè)備進(jìn)行了軟硬件結(jié)合的適配，包括硬件底層與 ZNBase 的交互優(yōu)化，RDMA 的軟硬件融合等一些開發(fā)。另外浪潮本身還有 K1 的主機(jī)服務(wù)器，這部分目前也在與 ZNBase 進(jìn)行底層的適配，從而提高產(chǎn)品的性能和可用性等。

總的來說，得益于浪潮的硬件優(yōu)勢，在硬件方面的工作 ZNBase 團(tuán)隊做起來還是比較順利的，這也是浪潮 ZNBase 相對于其他分布式數(shù)據(jù)庫來說的一個優(yōu)勢。

與 TiDB 等分布式數(shù)據(jù)庫的區(qū)別

提到 HTAP 分布式數(shù)據(jù)庫，我們不得不提近年來在社區(qū)中人氣火爆的明星項目 TiDB，以及一些同樣主打 HTAP 場景融合特性的數(shù)據(jù)庫產(chǎn)品，比如國外的 Greenplum 、阿里云的 HybridDB for MySQL、百度的 BaikalDB 等。陳磊認(rèn)為，與這些數(shù)據(jù)庫相比，ZNBase 的優(yōu)勢主要體現(xiàn)在兩個方面。

第一是背景不同，其他的產(chǎn)品都是大的互聯(lián)網(wǎng)公司開發(fā)的或面向互聯(lián)網(wǎng)應(yīng)用的。浪潮是大型 IT 企業(yè)面向政府大數(shù)據(jù)、大型企業(yè)應(yīng)用而產(chǎn)生的。

第二是架構(gòu)或技術(shù)棧有所區(qū)別。雖然大部分分布式數(shù)據(jù)庫采用 KV 存儲，但剛談到 ZNBase 是 ShareNothing 架構(gòu)的，TiDB 則是共享存儲架構(gòu)。由此，浪潮 ZNBase 的優(yōu)勢是擴(kuò)展性更好，部署運(yùn)維更加容易，為用戶提供了可直接啟動的二進(jìn)制包；另外基于浪潮所服務(wù)的一些客戶的使用習(xí)慣，ZNBase 會兼容更多的 Oracle、DB2 等傳統(tǒng)商業(yè)數(shù)據(jù)庫的函數(shù)與語法。

在硬件方面，浪潮的技術(shù)團(tuán)隊在國產(chǎn)芯片及操作系統(tǒng)兼容和優(yōu)化方面做的更多些。浪潮有自己的分布式存儲、操作系統(tǒng)、云平臺研發(fā)團(tuán)隊，做了很多底層適配與底層優(yōu)化的工作，這使得 ZNBase 更加穩(wěn)定可靠。

詳細(xì)來說，ZNBase 與同樣基于 Spanner+F1 設(shè)計理念的 TiDB 在 HTAP 架構(gòu)上還是比較類似的，就是都會提供一個列存的副本，主打的是 OLTP 使用場景，OLAP 的場景應(yīng)用性能偏輕量級，同時在不斷地增強(qiáng)中。二者的主要區(qū)別在于面向的客戶群體不同。ZNBase 根據(jù)浪潮長期積累的大量政府、金融和傳統(tǒng)企業(yè)客戶的需求，對 Oracle、DB2 等傳統(tǒng)商用數(shù)據(jù)庫做了大量的兼容性工作，這對浪潮的客戶遷移到 ZNBase 很有幫助；而 TiDB 可能更多是面向互聯(lián)網(wǎng)行業(yè)的客戶，更多地兼容 MySQL 的生態(tài)。

而國外比較火的 Greenplum 是主打 OLAP 場景的產(chǎn)品，OLTP 方面在不斷增強(qiáng)；HybridDB for MySQL 和 BaikalDB 這兩款產(chǎn)品實際上與 Greenplum 類似，他們都是有一個獨(dú)立的列存引擎，也就是在表建立之前就已經(jīng)定義了是列存表還是行存表。而 ZNBase 和 TiDB 都是既有行存的數(shù)據(jù)副本，也有列存的數(shù)據(jù)副本，這個實際上是一個本質(zhì)的區(qū)別。

“所以說目前主流的 HTAP 分布式數(shù)據(jù)庫采用行存和列存副本，對同一份數(shù)據(jù)采用不同的存儲格式，應(yīng)該是未來的一個方向?！标惱诒硎荆安贿^目前我們暫時沒有能提供的具體對比數(shù)據(jù)，各位技術(shù)愛好者如果有興趣就可以自己拿來進(jìn)行對比，也可以為我們分享。”

HTAP 大有可為

關(guān)于近年來興起的 HTAP 概念，陳磊結(jié)合浪潮客戶對數(shù)據(jù)庫產(chǎn)品需求的變遷歷史，為我們描述了分布式數(shù)據(jù)庫從 OLTP 場景需求到與 OLAP 場景需求結(jié)合的進(jìn)化過程。

從浪潮一直以來接觸的一些客戶使用場景來看，目前的傳統(tǒng)企業(yè)市場需求主要還是以 OLTP 為主。主要體現(xiàn)在這些客戶的業(yè)務(wù)量規(guī)模擴(kuò)大了以后，比如說他們需要增加 10 臺服務(wù)器，可能同時要維護(hù)一個包含上百億數(shù)據(jù)量的表，這個時候數(shù)據(jù)還需要不斷往里加。這種場景就是分布式數(shù)據(jù)庫的 OLTP 部分可以滿足他們的需求。

在解決 OLTP 需求的基礎(chǔ)上，整個數(shù)據(jù)庫系統(tǒng)必然會有一些數(shù)據(jù)的沉淀，人們就需要從這些數(shù)據(jù)中挖掘出對自身業(yè)務(wù)有意義的價值，這就產(chǎn)生了對這些數(shù)據(jù)進(jìn)行分析的需求。而分布式數(shù)據(jù)庫承載的數(shù)據(jù)量通常要比傳統(tǒng)數(shù)據(jù)庫大得多，用傳統(tǒng)技術(shù)進(jìn)行數(shù)據(jù)分析就會很痛苦，可能一個查詢操作就要等上好幾天的時間，甚至無法返回結(jié)果?！斑@就是我們還要在解決 OLTP 的基礎(chǔ)上增加 OLAP 功能，做成一個融合二者的 HTAP 數(shù)據(jù)庫的原因。”

HTAP 數(shù)據(jù)庫將兩種需求場景合二為一的愿景固然美好，但在實際的開發(fā)過程中，要想實現(xiàn) HTAP 并不容易。陳磊介紹，實現(xiàn) HTAP 的難點主要有幾個方面：

首先需要解決的是數(shù)據(jù)存儲，大家知道列存是可以做這種分析型的運(yùn)算，研發(fā)高性能的列存引擎就是一個難點，當(dāng)然現(xiàn)在已經(jīng)有一些優(yōu)秀的開源列存引擎，開發(fā)者可以在此基礎(chǔ)上復(fù)用。

然后就是行存和列存數(shù)據(jù)的一致性問題。傳統(tǒng)的 HTAP 數(shù)據(jù)庫行存與列存是分開的兩張表，行列之間不需要保持?jǐn)?shù)據(jù)一致性，但是像 ZNBase 以及 TiDB 這種新型的 HTAP 數(shù)據(jù)庫，同樣的數(shù)據(jù)同時有行存和列存，就需要保證數(shù)據(jù)的一致性，但解決數(shù)據(jù)一致性問題也會帶來新的問題，比如影響數(shù)據(jù)寫入的性能，如何去解決數(shù)據(jù)寫入性能問題也是一個難點。

還有的話就是數(shù)據(jù)同時保存在列存和行存中，當(dāng)一個查詢命令過來的時候，應(yīng)該選擇哪一個存儲引擎來計算？這個時候給數(shù)據(jù)庫系統(tǒng)的 SQL 層、優(yōu)化器和執(zhí)行器帶來的挑戰(zhàn)也會更加大一些。

數(shù)據(jù)庫與 AI

AI 的高速發(fā)展影響著各行各業(yè)，如今也有一些數(shù)據(jù)庫廠商嘗試在 OLAP 的場景中加入 AI 輔助進(jìn)行數(shù)據(jù)分析，那么這種趨勢是否會給 ZNBase 的未來發(fā)展方向帶來一些啟示呢？

陳磊告訴我們，目前業(yè)內(nèi)在數(shù)據(jù)庫中引用 AI 輔助的模式主要有兩種，一種是 AI for DB，還有一種是 DB for AI。

DB for AI 就是為分布式數(shù)據(jù)庫提供 AI 分析的能力。就像 Greenplum 通過 MADlib 的第三方插件來實現(xiàn)一些機(jī)器學(xué)習(xí)、圖計算或者深度學(xué)習(xí)的一些算法，客戶直接使用AI算法對庫內(nèi)的數(shù)據(jù)進(jìn)行計算?！斑@樣的工作確實有廠商在做，但我認(rèn)為還不足以形成一種趨勢?！标惱诒硎?。

另外一種模式就是 AI for DB，這種模式有兩種，第一種是一些數(shù)據(jù)庫廠商提供的類似“數(shù)據(jù)庫大腦”或“數(shù)據(jù)庫自動駕駛”的外部工具，它通過分析數(shù)據(jù)庫日志或者一些視圖，得出數(shù)據(jù)庫的性能表現(xiàn)，然后去動態(tài)地調(diào)整數(shù)據(jù)庫參數(shù)，來達(dá)到優(yōu)化數(shù)據(jù)庫性能的目的。另外就是在數(shù)據(jù)庫中利用一些 AI 算法來進(jìn)行優(yōu)化，包括內(nèi)核優(yōu)化、運(yùn)維優(yōu)化等。比如在數(shù)據(jù)庫比較核心的執(zhí)行計劃、執(zhí)行計劃生成、優(yōu)化器等部分加入 AI 算法的能力輔助來實現(xiàn)性能優(yōu)化，這一塊確實是數(shù)據(jù)庫行業(yè)目前的趨勢，也是陳磊認(rèn)為最難做的部分。

ZNBase 的團(tuán)隊實際上也在做數(shù)據(jù)庫與 AI 結(jié)合的研究，而 AI for DB 是目前主要研究的一個方向。

未來規(guī)劃

最后，陳磊分別從開源運(yùn)營角度和產(chǎn)品研發(fā)角度介紹了 ZNBase 未來一段時間的發(fā)展規(guī)劃。

首先是開源規(guī)劃，目前團(tuán)隊暫時只開源了 ZNBase 的 KV 存儲部分，他們的計劃是爭取 6 月底把 ZNBase 的所有代碼全部開源，包括 SQL 層和一些上下層封裝接口，全部采用 Apache 2.0 協(xié)議。

而關(guān)于研發(fā)的規(guī)劃，陳磊向我們透露了大致的方向：“目前我們正在研發(fā)一個列存引擎，還有前面提到的 AI 方面的優(yōu)化，以及用 C++ 或 Rust 替代 Go 語言來重寫 ZNBase 的 SQL 層，這些工作都在我們的日程中。感謝大家對 ZNBase 的關(guān)注，我們也會盡快把所有的代碼開源出來，屆時歡迎感興趣的開發(fā)者加入到我們的社區(qū)中參與貢獻(xiàn)?！?br>

嘉賓介紹

陳磊，浪潮云溪數(shù)據(jù)庫研發(fā)副總經(jīng)理兼產(chǎn)品負(fù)責(zé)人