談?wù)凮ceanBase 單機(jī)分布式一體化的思考

編者按：在國產(chǎn)替代浪潮下，國產(chǎn)自主數(shù)據(jù)庫正在快速崛起。在眾多頭部國產(chǎn)數(shù)據(jù)庫玩家中，低調(diào)耕耘多年的螞蟻 OceanBase 一直是“掃地僧”一般的存在。OceanBase 生于大數(shù)據(jù)時代，2010 年支付寶正式成立 OceanBase，當(dāng)時云計算方興未艾，互聯(lián)網(wǎng)正高速發(fā)展。OceanBase 創(chuàng)建初心是要解決“海量數(shù)據(jù)管理的難題”，真正做一個“頂天立地”的通用性產(chǎn)品，如今 OceanBase 已成為國產(chǎn)分布式數(shù)據(jù)庫的代表產(chǎn)品。螞蟻 OceanBase 作為一家獨立的數(shù)據(jù)庫廠商，也一直穩(wěn)居國產(chǎn)數(shù)據(jù)庫市場第一梯隊。此前羅超頻道對OceanBase 也有多次專題報道。

那么，OceanBase 的架構(gòu)是如何演進(jìn)的？OceanBase 的架構(gòu)設(shè)計背后有什么技術(shù)考量？其獨創(chuàng)的“單機(jī)分布式一體化”架構(gòu)會不會成為數(shù)據(jù)庫未來？今天分享一篇干貨筆記，作者為現(xiàn)任螞蟻OceanBase CTO楊傳輝，他時也是中國計算機(jī)學(xué)會（CCF）數(shù)據(jù)庫專委會執(zhí)行委員，他帶領(lǐng) OceanBase 技術(shù)團(tuán)隊成功打造了下一代企業(yè)級分布式數(shù)據(jù)庫。

以下為正文：

我從07年開始研究大規(guī)模分布式系統(tǒng)，剛開始參照Google三駕馬車（GFS/MapReduce/Bigtable），10年開始加入當(dāng)時的淘寶做OceanBase。OceanBase最初是一個分布式架構(gòu)，支持的SQL功能非常有限，后來逐步加入SQL功能并通用化。

剛開始接觸大規(guī)模分布式系統(tǒng)的時候，我覺得這個領(lǐng)域特別高大上，當(dāng)年的分布式系統(tǒng)有點像今天的ChatGPT，涉及的技術(shù)很前沿，而且有些協(xié)議非常難，我記得當(dāng)時僅僅理解Paxos協(xié)議就花費了一年多的時間，看了十幾篇相關(guān)論文且和小伙伴們做了大量的技術(shù)討論。

曾經(jīng)有一段時間，我覺得分布式是IT軟件技術(shù)皇冠上的明珠，所有系統(tǒng)只有做成分布式才顯檔次。但是，當(dāng)我們將OceanBase早期版本應(yīng)用到淘寶和支付寶時，用戶和DBA給我們提出的都是SQL兼容性和性能成本相關(guān)的需求，把我們和單機(jī)的MySQL數(shù)據(jù)庫做比較，只有完全兼容且性價比更高才會選擇OceanBase。他們告訴我，OceanBase的擴(kuò)展性和無損容災(zāi)確實很好，也認(rèn)同分布式這個方向，但是對不起，老板說今年業(yè)務(wù)發(fā)展太快，不能投入額外人力做數(shù)據(jù)庫改造，也不能投入額外的數(shù)據(jù)庫服務(wù)器。阿里有一句土話叫“既要也要還要”，小孩才做選擇，用戶和DBA想要的就是一個不要做選擇的“成年人的數(shù)據(jù)庫”。我記得當(dāng)時還和Google Spanner的研發(fā)人員做過一次技術(shù)討論，我問他們?yōu)槭裁碐oogle內(nèi)部能夠接受Spanner很差的單機(jī)性能，他們告訴我Google內(nèi)部的程序員很強(qiáng)，大家都可以把應(yīng)用修改為異步程序。另外一點就是，Google有Jeff Dean，只要他想統(tǒng)一基礎(chǔ)架構(gòu)就可以自上而下推進(jìn)。我很羨慕Google內(nèi)部做基礎(chǔ)設(shè)施的研發(fā)人員，同時，我也意識到，這種模式是不可擴(kuò)展的。對于開發(fā)者來講，一定要把單機(jī)的高性能低門檻融入到分布式的可擴(kuò)展高可用才能做出一個真正好用的分布式數(shù)據(jù)庫。

我們在2016年發(fā)布了全分布式架構(gòu)OceanBase 1.0版本，這個版本的所有節(jié)點都是可讀可寫的，但是，有一個問題，那就是每個節(jié)點用于分布式相關(guān)的overhead比較大，當(dāng)表格和分區(qū)較多時，即使系統(tǒng)空轉(zhuǎn)，也會消耗好幾個CPU核用于分布式相關(guān)操作。這個問題使得OceanBase 1.x系列的版本只能幫助較大規(guī)模的企業(yè)解決數(shù)據(jù)庫的問題，很難在中小企業(yè)做規(guī)?；瘡?fù)制。于是，我們在2018年開始討論如何降低分布式數(shù)據(jù)庫的門檻，讓分布式數(shù)據(jù)庫成為一個人人皆可觸達(dá)的東西。

數(shù)據(jù)庫底層架構(gòu)的調(diào)整需要非常慎重，我們足足花費了兩年多的時間完成了技術(shù)討論和總體架構(gòu)的設(shè)計，并在2020年年中左右開始做詳細(xì)設(shè)計和代碼開發(fā)，再經(jīng)過兩年多的時間才在2022年8月份發(fā)布了第一個OceanBase 4.0版本，代號“小魚”。4.0版本奠定了單機(jī)分布式一體化架構(gòu)的底座，但是還有很多的遺留問題，在3月份開發(fā)者大會發(fā)布的4.1版本中解決。

我從2021年開始對外鋪墊一體化架構(gòu)的概念，在2021年10月22日的云棲大會上分享了<<OceanBase一體化架構(gòu)助力核心系統(tǒng)>>。最早的一體化架構(gòu)叫做“集中式分布式一體化“，當(dāng)時我們認(rèn)為DBA更加熟悉集中式這個說法。不過，市場品牌的負(fù)責(zé)人建議修改成 “單機(jī)分布式一體化”，這樣會更加形象直觀，能夠更好地表達(dá)OceanBase的技術(shù)特點，開發(fā)者也更容易理解。

可行性分析，如何消除分布式帶來的overhead？

架構(gòu)設(shè)計首先要做的就是可行性分析。做技術(shù)的同學(xué)肯定都很熟悉，架構(gòu)設(shè)計的核心在于取舍，為什么能夠做到，背后的原理是什么，舍棄了什么。我們在設(shè)計一體化架構(gòu)時，也做了一個設(shè)計假設(shè)，那就是：對于一個分布式數(shù)據(jù)庫，雖然數(shù)據(jù)量很大，但是大部分操作仍然為單機(jī)操作（>80%），少部分操作才是跨機(jī)操作（<20%）。

OceanBase早期在阿里系內(nèi)部推廣時，我自己就是內(nèi)部的BD/SA，我會主動去和每個業(yè)務(wù)的開發(fā)人員交流，最后發(fā)現(xiàn)，雖然阿里系的業(yè)務(wù)很復(fù)雜，有電商，金融，物流，本地生活，文娛，地圖，醫(yī)療健康，但是，所有的互聯(lián)網(wǎng)to C的在線業(yè)務(wù)基本都能夠按照用戶號(user_id)做sharding來實現(xiàn)分布式。按照user_id做完sharding之后，絕大部分操作都是單用戶內(nèi)部的操作，只有非常少數(shù)的跨用戶操作。

金融行業(yè)也是類似的，我們都用過網(wǎng)銀系統(tǒng)，大部分時間都是在讀寫自己的賬戶，少部分時間才是做轉(zhuǎn)賬這樣的跨賬戶操作。

于是，系統(tǒng)的優(yōu)化目標(biāo)就變成：首先確保80%的單機(jī)操作沒有任何分布式相關(guān)的overhead，這部分操作能夠和單機(jī)數(shù)據(jù)庫站在同一個起點上PK性能，接下來才是優(yōu)化另外20%跨機(jī)操作的性能，盡可能追求極致。

單機(jī)操作的分布式相關(guān)overhead主要來自于兩個方面：一個是高可用帶來的，一個是可擴(kuò)展性帶來的。

2013年的時候當(dāng)時的支付寶Oracle DBA告訴我一個經(jīng)驗數(shù)據(jù)，當(dāng)Oracle打開強(qiáng)同步的時候，性能降低至少30%以上。OceanBase為了實現(xiàn)無損容災(zāi)，底層采用了基于Paxos的強(qiáng)同步方案，如果不在架構(gòu)上有所變化，肯定做不到單機(jī)高性能。我們的做法是把數(shù)據(jù)庫中的redo日志提交給異步化，這樣就避免了數(shù)據(jù)庫內(nèi)部的工作線程等待日志提交返回結(jié)果，即使網(wǎng)絡(luò)和磁盤比較差，強(qiáng)同步帶來的開銷也比較小。我們用sysbench對OceanBase三臺機(jī)器強(qiáng)同步做了性能評測，結(jié)果表明Paxos強(qiáng)同步對于OceanBase的性能損失只有8%左右。這個損失是完全可以接受的，可以通過其它模塊的優(yōu)化給彌補(bǔ)回來。可擴(kuò)展性帶來的性能損耗主要是數(shù)據(jù)分片導(dǎo)致的，每個數(shù)據(jù)分片都需要寫單獨的redo日志，可以簡單地把每個數(shù)據(jù)分片想象成一個mini數(shù)據(jù)庫，分片越多，每臺機(jī)器上分片管理相關(guān)的分布式overhead就越大。

4.0單機(jī)分布式一體化架構(gòu)的創(chuàng)新就在于動態(tài)單日志流。每臺機(jī)器上的每個租戶只有一個日志流，這個租戶上的所有數(shù)據(jù)分區(qū)都動態(tài)綁定都該日志流之上，從而避免了大量日志流導(dǎo)致的overhead。另外，分區(qū)到日志流是動態(tài)綁定的，當(dāng)系統(tǒng)增加新的服務(wù)器時，可以把分區(qū)從源端的日志流動態(tài)解綁并重新綁定到目的端的日志流，從而實現(xiàn)分區(qū)動態(tài)遷移。

很多人可能會想，數(shù)據(jù)庫發(fā)展了這么多年，為什么OceanBase想到了這么做，其他人都沒有想到？這里面其實也沒有什么魔法，我認(rèn)為關(guān)鍵點在于全球分布式數(shù)據(jù)庫很少有像OceanBase，必須抗住支付寶雙十一這樣的極限業(yè)務(wù)場景，并且多年被業(yè)務(wù)方“既要也要還要”給逼出來的。

業(yè)界對于可擴(kuò)展性也有不同的做法：經(jīng)典的單機(jī)數(shù)據(jù)庫干脆就不支持可擴(kuò)展，想要分布式的時候讓應(yīng)用做改造；NewSQL系統(tǒng)的思路是把可擴(kuò)展性下沉到存儲層，將系統(tǒng)劃分為SQL層和存儲層，SQL層做功能，存儲層做可擴(kuò)展性，這種實現(xiàn)方式更加簡單，但會帶來一個問題，那就是每個SQL請求都需要一次額外的遠(yuǎn)程訪問，即使是訪問自己賬戶也是一樣；OceanBase的做法是先實現(xiàn)全分布式架構(gòu)1.x/2.x/3.x，再逐步演進(jìn)到單機(jī)分布式一體化架構(gòu)4.x。

單機(jī)分布式一體化架構(gòu)對開發(fā)者意味著什么？

單機(jī)分布式一體化架構(gòu)看起來什么都行，既能做單機(jī)，又能分布式，現(xiàn)階段的側(cè)重點到底是什么？我認(rèn)為一方面，單機(jī)分布式一體化架構(gòu)是一種技術(shù)的升維，對于用戶和開發(fā)者比之前更加友好，會逐步成為主流選擇。另一方面，新技術(shù)肯定有一段成熟期，尤其是用戶體驗和生態(tài)一開始不如單機(jī)數(shù)據(jù)庫，需要一段時間來打磨。短期來看，單機(jī)分布式一體化架構(gòu)對于開發(fā)者的價值在于如下幾個方面：

1) 極大地降低分布式數(shù)據(jù)庫的門檻。原先的NewSQL單機(jī)性能太差，業(yè)界主流的NewSQL系統(tǒng)，比如CockroachDB和YugabyteDB的單機(jī)sysbench性能只有MySQL的1/5 ~ 1/10。隨著單機(jī)分布式一體化數(shù)據(jù)庫逐步成熟，這類NewSQL會被逐步取代，我也確實看到很多用戶把原先使用的NewSQL系統(tǒng)換成OceanBase來實現(xiàn)降本增效。

2) 解決用戶從小到大擴(kuò)展的需求。我在和很多中小企業(yè)溝通的過程中發(fā)現(xiàn)，大多數(shù)中小企業(yè)都是很有追求的，雖然目前階段他們的數(shù)據(jù)量不大，單機(jī)數(shù)據(jù)庫也能支撐，但是他們也對未來幾年的業(yè)務(wù)發(fā)展充滿期待，不希望等到業(yè)務(wù)發(fā)展之后再修改應(yīng)用更換數(shù)據(jù)庫，他們愿意一開始就選擇單機(jī)分布式一體化數(shù)據(jù)庫。

單機(jī)分布式一體化數(shù)據(jù)庫最終會不會取代單機(jī)數(shù)據(jù)庫？我認(rèn)為從技術(shù)趨勢上來看會逐步替代，但是整個過程比較長，需要很長一段時間。

聊聊核心技術(shù)原理

單機(jī)分布式一體化架構(gòu)的核心技術(shù)是動態(tài)單日志流。為了真正實現(xiàn)一體化，需要解決如下幾個關(guān)鍵的技術(shù)問題：

應(yīng)用透明：從單機(jī)到多機(jī)不需要應(yīng)用做改造，需要客戶端支持動態(tài)路由技術(shù)，當(dāng)后端數(shù)據(jù)庫發(fā)生分區(qū)遷移時，能夠動態(tài)路由到目的服務(wù)器上。另外，不管是單機(jī)還是分布式，需要支持全部的SQL功能。

單機(jī)操作：單機(jī)只有一個redo日志，單機(jī)事務(wù)寫redo日志的方式與經(jīng)典的單機(jī)數(shù)據(jù)庫比較像。OceanBase還做了一項技術(shù)創(chuàng)新，經(jīng)典的單機(jī)數(shù)據(jù)庫采用的是B+樹存儲引擎，OceanBase的做法是將B+樹數(shù)據(jù)分塊的思路融入到LSM樹存儲引擎，一方面能夠像LSM樹一樣具備高壓縮能力，并把熱點數(shù)據(jù)放在內(nèi)存中提供服務(wù)，另一方面通過類似B+樹的數(shù)據(jù)分塊思路來減少LSM樹的寫入放大。最終使得OceanBase 4.1即使在三臺機(jī)器做強(qiáng)同步的情況之下無論是單機(jī)的性能還是存儲成本都好于MySQL 8.0。

跨機(jī)操作：跨機(jī)操作通過底層的分布式架構(gòu)提供，上層的SQL功能不受影響。如果事務(wù)只涉及一臺機(jī)器，走單機(jī)事務(wù)；如果涉及多臺機(jī)器，通過兩階段提交實現(xiàn)分布式事務(wù)。另外，通過分布式、并行、異步化等技術(shù)手段盡可能地優(yōu)化性能。

遷移代價：遷移操作后臺進(jìn)行，實際運行時一般會對遷移限速。假設(shè)遷移最大限速200MB/s，占用萬兆網(wǎng)卡20%左右的帶寬，遷移操作只是拷貝數(shù)據(jù)，CPU占用比較少，只要不是在雙十一零點這樣的極端場景，后臺遷移都不會影響前臺的在線交易請求。假設(shè)數(shù)據(jù)量為1TB，遷移時間為1TB / 200MB/s = 5000s，大約1個半小時。

再聊聊實際效果

今年3月份我們在開發(fā)者大會分享了OceanBase的性能數(shù)據(jù)，過去也在TPC-C測試展示了OceanBase的擴(kuò)展能力：

單機(jī)性能：32C場景，OceanBase 4.1在sysbench所有場景(point select/read only/write only/read write/insert/update)都好于MySQL 8.0，在最為綜合的readwrite場景OceanBase 4.1比MySQL 8.0高39%。

公有云性價比：采用4C16G CPU，MySQL部署主備兩臺機(jī)器，OceanBase部署三臺機(jī)器，兩臺為全功能副本，一臺為日志副本。無論存儲多大，從100GB，300GB，500GB到1TB，OceanBase 4.1在阿里云和AWS的性價比都好于MySQL 8.0，且存儲容量越大，OceanBase的優(yōu)勢越明顯。整體上看，同樣的性能，相比云上的MySQL，OceanBase可以幫助用戶節(jié)省18.57%到42.05%整體擁有成本，且OceanBase還有更好的三副本無損容災(zāi)能力。

TPC-C擴(kuò)展性：OceanBase參加過兩次TPC-C測試，最后一次測試中采用了超過1500臺機(jī)器，TPC-C的workload里面有10%~15%分布式事務(wù)，本地事務(wù)85%-90%，與真實場景比較接近。通過TPC-C官網(wǎng)公布的報告可以看到，OceanBase的性能基本能夠做到隨著服務(wù)器的增加而線性增長。

一些關(guān)鍵問題探討

當(dāng)然，單機(jī)分布式一體化架構(gòu)也不是完美的，有一些問題仍然值得探討，也希望未來和開發(fā)者用戶做更深入的探討：

1) 分布式到單機(jī) vs 單機(jī)到分布式

到底是選擇分布式到單機(jī)（先做分布式再做單機(jī)），還是單機(jī)到分布式（先做單機(jī)再做分布式）的技術(shù)路線？我認(rèn)為只有分布式到單機(jī)才是可行的。因為分布式的技術(shù)難度比單機(jī)要高一個數(shù)量級，再加上單機(jī)的場景是主流場景。

從ROI的角度看，不太可能出現(xiàn)一個主流場景的單機(jī)數(shù)據(jù)庫，在已經(jīng)有大量技術(shù)債的前提之下，舍棄部分主流場景的支持，花費更高一個量級的代價去支持一個規(guī)模更小的高端場景。這也是為什么所有的商業(yè)案例中，只有先做高端，再做低端的降維做法才能成功。

技術(shù)創(chuàng)新也往往在外部才會發(fā)生，比如電動車領(lǐng)域的Tesla，分布式技術(shù)有點像電動車的電池，并不是燃油汽車廠商在內(nèi)部實現(xiàn)了電動化的變革，而是一個外部的Tesla先做好高端的Model X/Model S，再逐步通過大眾車Model 3去占領(lǐng)主流市場。

2) 全分布式場景

單機(jī)分布式一體化架構(gòu)有一個假設(shè)，那就是：在分布式數(shù)據(jù)庫中，大部分請求仍然是單機(jī)讀寫，少部分請求才是跨機(jī)讀寫。如果這個假設(shè)不成立，也就是大部分請求都是跨機(jī)讀寫，那么，分布式數(shù)據(jù)庫性能的擴(kuò)展比會大幅下降。怎么看待這個問題？

我認(rèn)為可以進(jìn)一步把全分布式的場景分為兩類：

一類是OLAP場景，OLAP場景單個用戶的數(shù)據(jù)量都很大，且維度會比較復(fù)雜，這個場景確實很難做到本地化。但是，這個場景的并發(fā)量很小，優(yōu)化的關(guān)鍵點在于盡可能地把所有機(jī)器的資源通過并行化、向量化等手段盡可能地利用起來。每次運行的SQL都比較大，一次額外的網(wǎng)絡(luò)請求開銷在整個SQL語句執(zhí)行過程中占比很少。

另外一類是OLTP場景，假設(shè)某個OLTP業(yè)務(wù)全部都是跨用戶轉(zhuǎn)賬操作，那么，如果數(shù)據(jù)量比較小，單機(jī)分布式一體化架構(gòu)可以只部署單機(jī)，沒有額外的分布式開銷；如果數(shù)據(jù)量比較大，必須采用多機(jī)部署，那么，性能的擴(kuò)展比雖然會大幅下降，但是，這是業(yè)務(wù)無法避免的，這種場景下單機(jī)分布式一體化數(shù)據(jù)庫相比其它的shared nothing數(shù)據(jù)庫在架構(gòu)上也沒有劣勢。

生成海報

免責(zé)聲明：此文內(nèi)容為第三方自媒體作者發(fā)布的觀察或評論性文章，所有文字和圖片版權(quán)歸作者所有，且僅代表作者個人觀點，與極客網(wǎng)無關(guān)。文章僅供讀者參考，并請自行核實相關(guān)內(nèi)容。投訴郵箱：editor@fromgeek.com。

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。