談談OceanBase 單機分布式一體化的思考

編者按：在國產(chǎn)替代浪潮下，國產(chǎn)自主數(shù)據(jù)庫正在快速崛起。在眾多頭部國產(chǎn)數(shù)據(jù)庫玩家中，低調(diào)耕耘多年的螞蟻 OceanBase 一直是“掃地僧”一般的存在。OceanBase 生于大數(shù)據(jù)時代，2010 年支付寶正式成立 OceanBase，當時云計算方興未艾，互聯(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 的架構是如何演進的？OceanBase 的架構設計背后有什么技術考量？其獨創(chuàng)的“單機分布式一體化”架構會不會成為數(shù)據(jù)庫未來？今天分享一篇干貨筆記，作者為現(xiàn)任螞蟻OceanBase CTO楊傳輝，他時也是中國計算機學會（CCF）數(shù)據(jù)庫專委會執(zhí)行委員，他帶領 OceanBase 技術團隊成功打造了下一代企業(yè)級分布式數(shù)據(jù)庫。

以下為正文：

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

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

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

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

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

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

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

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

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

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

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

單機操作的分布式相關overhead主要來自于兩個方面：一個是高可用帶來的，一個是可擴展性帶來的。

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

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

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

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

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

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

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

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

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

聊聊核心技術原理

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

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

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

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

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

再聊聊實際效果

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

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

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

一些關鍵問題探討

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

1) 分布式到單機 vs 單機到分布式

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

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

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

2) 全分布式場景

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

我認為可以進一步把全分布式的場景分為兩類：

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

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

生成海報

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

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