關(guān)于作者：

楊傳輝，OceanBase CTO。2010年作為創(chuàng)始成員之一加入 OceanBase 團(tuán)隊(duì)，主導(dǎo)了 OceanBase 歷次架構(gòu)設(shè)計(jì)和技術(shù)研發(fā)，從無到有實(shí)現(xiàn) OceanBase 在螞蟻集團(tuán)全面落地。同時(shí)，他也主導(dǎo)了兩次 OceanBase TPC-C 測試并打破世界紀(jì)錄，著有《大規(guī)模分布式存儲系統(tǒng)：原理與實(shí)踐》。目前，楊傳輝帶領(lǐng) OceanBase 技術(shù)團(tuán)隊(duì)致力于打造更加開放、靈活、高效、易用的下一代企業(yè)級分布式數(shù)據(jù)庫。

2022 年 8 月 10 日，OceanBase 4.0 小魚在年度發(fā)布會亮相，單機(jī)分布式一體化架構(gòu)也正式和大家見面。從我的角度看，OceanBase 總共經(jīng)歷了三次大的架構(gòu)升級：第一次架構(gòu)升級是 OceanBase 0.1~0.5 版本（2010 年~2015 年），當(dāng)時(shí)的 OceanBase 通過單寫多讀架構(gòu)實(shí)現(xiàn)了準(zhǔn)分布式，有 UpdateServer、ChunkServer、MergeServer 等多種不同的角色；第二次是 OceanBase 1.0~3.0 版本（2016 年~2022 年），OceanBase 成為一個(gè)對等的全分布式架構(gòu)，所有節(jié)點(diǎn)可讀可寫，逐步支持了完整的 SQL 功能；第三次架構(gòu)升級就是這次發(fā)布的 4.0 版本，我們正式提出了單機(jī)分布式一體化架構(gòu)。

這篇文章主要和大家分享， 4.0 背后的設(shè)計(jì)理念和技術(shù)思考。

面向云設(shè)計(jì)，以分布式為基石

在過去 70 余年的數(shù)據(jù)庫發(fā)展歷程中，集中式數(shù)據(jù)庫誕生了 Oracle、SQL Server、MySQL、PostgreSQL 等眾多優(yōu)秀作品，它們在單機(jī)性能和 SQL 功能做得非常出色，但是沒有辦法水平擴(kuò)展；分布式數(shù)據(jù)庫的出現(xiàn)解決了水平擴(kuò)展的難題，但是單機(jī)性能和 SQL 功能相比集中式數(shù)據(jù)庫有明顯差距。這個(gè)過程出現(xiàn)很多的分布式數(shù)據(jù)庫，其中有些分布式數(shù)據(jù)庫其實(shí)是分布式存儲系統(tǒng)，只支持簡單的 NoSQL 功能或者有限的 SQL 功能；也有一些分布式數(shù)據(jù)庫同時(shí)支持水平擴(kuò)展和完整的 SQL 功能，這些系統(tǒng)常常被稱為 NewSQL，例如 CockroachDB，Google Spanner，但是，它們的單節(jié)點(diǎn)性能都不到 MySQL 的 1/3。

因此，單機(jī)和分布式如何選擇成為最讓人糾結(jié)難以選擇的問題，通常的做法是根據(jù)數(shù)據(jù)量來做：如果數(shù)據(jù)量比較小，選擇功能完備的集中式數(shù)據(jù)庫；如果數(shù)據(jù)量很大，則選擇分布式數(shù)據(jù)庫或者分布式存儲系統(tǒng)，犧牲功能和單機(jī)性能，通過修改業(yè)務(wù)或者堆機(jī)器來解決。

對于分布式數(shù)據(jù)庫，有不同的理念：很多人或者很多系統(tǒng)認(rèn)為分布式是數(shù)據(jù)庫的一種補(bǔ)充，適合某些數(shù)據(jù)量特別大或者并發(fā)量特別高的細(xì)分領(lǐng)域，而我的觀點(diǎn)是不同的：我認(rèn)為分布式是未來面向云的下一代數(shù)據(jù)庫的基石，未來云數(shù)據(jù)庫的底層都是原生分布式。

打個(gè)比方，云數(shù)據(jù)庫就像是電動(dòng)車，而分布式就是其中的電池技術(shù)，有了分布式之后，雖然數(shù)據(jù)庫的基本用法和之前差別不大，但用戶體驗(yàn)開始分化，我們已經(jīng)看到零配置、Serverless 等理念逐步融入到最新的云數(shù)據(jù)庫中。這就有點(diǎn)像電動(dòng)車，當(dāng)電池效率提升，充電樁逐步普及之后，電動(dòng)車開始在用戶體驗(yàn)上拉開與燃油車之間的差距。很多人對特斯拉最大的感受并不是所謂的自動(dòng)駕駛，而是操作簡單，踩油門加速，收油門減速，甚至都可以做到不需要?jiǎng)x車。剛開始還有點(diǎn)不適應(yīng)，但是過一段時(shí)間很快會發(fā)現(xiàn)這才是汽車本來應(yīng)該的樣子。分布式和云原生也應(yīng)該是數(shù)據(jù)庫本來應(yīng)該的樣子，未來的主流數(shù)據(jù)庫默認(rèn)都會具備面向云的靈活性、簡單性和開放性，包括：

1. 面向云的靈活性： 具備任意擴(kuò)展，支持按需擴(kuò)展存儲容量和計(jì)算能力，支持按需付費(fèi)（Pay as you go）。支持客戶從小到大全生命周期的數(shù)據(jù)庫需求，當(dāng)客戶業(yè)務(wù)量很小時(shí)，可以選擇很小規(guī)格的獨(dú)立實(shí)例（比如 4C8G）、甚至共享實(shí)例或者按請求付費(fèi)（Serverless）；當(dāng)業(yè)務(wù)量逐步增加時(shí)，能夠很靈活地增加數(shù)據(jù)庫的存儲和計(jì)算能力；當(dāng)業(yè)務(wù)量跨過洪峰回歸常規(guī)時(shí)，能夠很平滑地按照需求動(dòng)態(tài)縮容來降低成本。

2. 面向云的簡單性： 無論是功能，還是運(yùn)維，讓用戶少做選擇甚至不做選擇。盡可能由數(shù)據(jù)庫完成數(shù)據(jù)自動(dòng)分片、自動(dòng)容錯(cuò)、跨服務(wù)器分布式事務(wù)等操作，兼容 MySQL/Oracle/PostgreSQL 等用戶接口。支持 HTAP 混合負(fù)載，提升查詢優(yōu)化和自適應(yīng)處理能力，盡可能減少用戶配置。

3. 面向云的開放性： 以單一“云原生”，到客戶為中心的多云原生，減少 IaaS 層依賴。支持“一庫多云”、“一庫多芯”，能夠按業(yè)務(wù)需要快速高效適配新的云平臺和 CPU 等新硬件。

為此，我們提出了 OceanBase 4.0 單機(jī)分布式一體化理念，讓分布式成為數(shù)據(jù)庫的基石而不僅僅應(yīng)用到可擴(kuò)展這一細(xì)分場景。為了達(dá)成這個(gè)目標(biāo)，我們既要擴(kuò)展性，也要完整的 SQL 功能和極致的單機(jī)性能，從小到大支持用戶全生命周期的業(yè)務(wù)。由于單機(jī)分布式一體化架構(gòu)將入門門檻降低到與集中式數(shù)據(jù)庫基本相當(dāng)，且在面向云的高可用、可擴(kuò)展、性價(jià)比上具備明顯優(yōu)勢，我認(rèn)為，該架構(gòu)會逐步成為主流，并且發(fā)展出一個(gè)與 MySQL、PostgreSQL 平行且同等量級的開源社區(qū)。因此，我們決定從 OceanBase 4.0 開始把開源分支和商業(yè)分支統(tǒng)一成為一個(gè)分支，加快開源社區(qū)的發(fā)展。

必須攻克的難關(guān)：動(dòng)態(tài)日志流融合單機(jī)分布式

單機(jī)分布式一體化架構(gòu)要求兼具分布式的擴(kuò)展性和集中式數(shù)據(jù)庫的功能和單機(jī)性能。事務(wù)的 ACID（ Atomicity，Consistency，Isolation，Durability）是數(shù)據(jù)庫的基本要求，而分布式數(shù)據(jù)庫的難點(diǎn)就在于如何在異常場景下保證事務(wù)的 ACID，核心就是如何基于重做日志（Redo log）實(shí)現(xiàn)故障恢復(fù)，以及基于重做日志實(shí)現(xiàn)異常場景下分布式事務(wù)的原子性。

我們首先看看業(yè)內(nèi)的已有方案：

A) 服務(wù)器級靜態(tài)日志流： 典型的代表是基于中間件+開源數(shù)據(jù)庫（MySQL/PostgreSQL）分庫分表的方案。數(shù)據(jù)庫區(qū)分主庫和備庫，主庫將重做日志同步到備庫。這種方案不支持分區(qū)級的細(xì)粒度遷移復(fù)制，也就無法實(shí)現(xiàn)在線水平擴(kuò)展。當(dāng)需要擴(kuò)容時(shí)，往往采用按倍數(shù)擴(kuò)容的方案，且擴(kuò)容過程會影響業(yè)務(wù)，由 DBA 手動(dòng)執(zhí)行。

B) 分區(qū)級靜態(tài)日志流： 典型的代表是 CockroachDB/TiDB 代表的 NewSQL 數(shù)據(jù)庫，以及 OceanBase 1.0~3.0 版本。每個(gè)數(shù)據(jù)分區(qū)/數(shù)據(jù)分片有單獨(dú)的日志流，支持分區(qū)級的細(xì)粒度遷移復(fù)制，支持水平擴(kuò)展。這種方案的問題在于分布式開銷與分區(qū)的數(shù)量成正比，單臺服務(wù)器支持的表格數(shù)量有上限，即使業(yè)務(wù)的數(shù)據(jù)可以全部放到一臺服務(wù)器上，也需要承受分布式相關(guān)的 overhead。

C) 日志與數(shù)據(jù)分離： 典型的代表是 FoundationDB 數(shù)據(jù)庫。將存儲服務(wù)器和日志服務(wù)器分離開來，寫事務(wù)只寫日志服務(wù)器，存儲服務(wù)器會定期從日志服務(wù)器拉取日志并應(yīng)用到本地從而服務(wù)讀請求。這種方式的問題在于存儲服務(wù)器上的數(shù)據(jù)有很短的延遲，影響讀取最新數(shù)據(jù)的效率。

方案 A 的好處在于避免了分布式 overhead，單機(jī)性能更好，但是無法實(shí)現(xiàn)在線水平擴(kuò)展；方案 B 的好處在于支持在線水平擴(kuò)展，但引入了分布式 overhead，會造成額外性能開銷；方案 C 的好處在于部署靈活，但會影響讀取性能。因此，從 OceanBase 4.0 版本開始，通過動(dòng)態(tài)日志流將方案 A 和方案 B 融合起來，兼具單機(jī)性能和分布式的水平擴(kuò)展能力。 當(dāng)系統(tǒng)處于穩(wěn)定狀態(tài)時(shí)，動(dòng)態(tài)日志流類似方案A，每臺服務(wù)器只有固定數(shù)量的日志流；但與方案 A 不同的是，OceanBase 4.0 支持將一個(gè)分區(qū)從一個(gè)日志流遷移到另外一個(gè)日志流，這意味著可以實(shí)現(xiàn)與方案 B 類似的分區(qū)級在線水平擴(kuò)展能力。這個(gè)看似不難理解的方案，但實(shí)現(xiàn)起來卻極具挑戰(zhàn)，舉三個(gè)實(shí)際的場景：

第一，當(dāng)一個(gè)分區(qū)從一個(gè)日志流遷移到另外一個(gè)日志流時(shí)，如何確保遷移過程是原子的，也就是說，無論發(fā)生任何異常，該分區(qū)的所有的副本要么全部遷移成功，要么全部遷移失??；

第二，分區(qū)遷移時(shí)，如何確保不會影響正在進(jìn)行中的事務(wù)，我們必須考慮到這種情況，有些事務(wù)可能做到一半或者該事務(wù)正在運(yùn)行的SQL語句做到一半 ；

第三，分區(qū)遷移時(shí)，如何確保下游總是訂閱到正確的數(shù)據(jù)，無論什么情況發(fā)生，不會丟失也不會重復(fù)；

OceanBase 4.0 解決了這些技術(shù)難題，實(shí)現(xiàn)了在線水平擴(kuò)展的同時(shí)不增加分布式相關(guān) overhead，從而能夠像集中式數(shù)據(jù)庫一樣部署在小規(guī)格的服務(wù)器上，做到單節(jié)點(diǎn)性能達(dá)到甚至超越集中式數(shù)據(jù)庫的水平。

為多云架構(gòu)而生：從云原生，到多云原生

云計(jì)算從誕生之初到現(xiàn)在經(jīng)歷了多次技術(shù)迭代，從最早的托管虛擬機(jī)，到托管服務(wù)，再到今天的多云和 Serverless，不斷追求靈活、簡單、開放。OceanBase 4.0 正是為多云架構(gòu)設(shè)計(jì)的。

靈活：內(nèi)置自動(dòng)水平擴(kuò)展

云上用戶從小到大發(fā)展過程中，從共享實(shí)例，到小規(guī)格實(shí)例，到大規(guī)模實(shí)例，再到最后的分布式方案。OceanBase 通過內(nèi)置的多租戶隔離架構(gòu)，能夠?qū)崿F(xiàn)共享實(shí)例，從而盡可能降低成本。 當(dāng)用戶的業(yè)務(wù)量越來越大時(shí)，通過單機(jī)分布式一體化架構(gòu)，可以逐步從小規(guī)格實(shí)例擴(kuò)展到分布式實(shí)例，小規(guī)格實(shí)例沒有分布式相關(guān) overhead，分布式實(shí)例既能擴(kuò)展存儲容量，也能擴(kuò)展計(jì)算能力。支持 Pay as you go 的計(jì)費(fèi)模式，既支持快速擴(kuò)容，也支持快速縮容。

我們還將探索 Serverless 方案，從而實(shí)現(xiàn)按請求付費(fèi)。Serverless 方案涉及到幾個(gè)重要的技術(shù)點(diǎn)：

• 當(dāng)用戶完全沒有請求時(shí)，數(shù)據(jù)庫能否做到零消耗？

• 如何快速彈性擴(kuò)縮容，當(dāng)計(jì)算節(jié)點(diǎn)發(fā)生故障時(shí)，如何快速拉起新的計(jì)算節(jié)點(diǎn)繼續(xù)提供服務(wù)，做到秒級甚至更低？

• 如何衡量不同 SQL 請求的開銷，從而實(shí)現(xiàn)按請求計(jì)費(fèi)？有些 SQL 可能很簡單，有些 SQL 可能很復(fù)雜且需要訪問大量數(shù)據(jù)。

這些問題都很有意思，也歡迎大家和我們討論。

簡單：HTAP = OLTP+

OceanBase 4.0 希望降低數(shù)據(jù)庫選型和運(yùn)維的復(fù)雜度，盡可能用一套數(shù)據(jù)庫滿足不同場景的需求。一方面，單機(jī)和分布式的架構(gòu)差異可以通過前面提到的動(dòng)態(tài)日志流方案統(tǒng)一起來；另一方面，我們看到市面上大部分 NoSQL、NewSQL 以及OLAP 系統(tǒng)底層的存儲引擎都是類 LSM Tree 架構(gòu)，可以在一套系統(tǒng)中實(shí)現(xiàn) OLTP、實(shí)時(shí) OLAP、Key-Value、JSON、GIS 等多種數(shù)據(jù)模型的處理，避免用戶因?yàn)榛A(chǔ)設(shè)施能力不足而采用多套系統(tǒng)。

我并不支持"One Size Fit All"，單機(jī)分布式一體化架構(gòu)也不是萬能的，但是，我認(rèn)為，在不怎么犧牲性能成本的前提下"One Size Fit Bunch"。按照這個(gè)思路，我在前一段時(shí)間寫了一篇文章《真正的 HTAP 對用戶和開發(fā)者意味著什么》：我認(rèn)為的 HTAP 其實(shí)就是 OLTP+，先有高性能的 OLTP，然后在 OLTP 的基礎(chǔ)上支持實(shí)時(shí)分析，并增加 Key-Value、JSON、GIS 等多模支持，適合在線查詢和在線分析業(yè)務(wù)，對于離線分析和大數(shù)據(jù)分析并不是最優(yōu)的。

開放：面向多云的存儲計(jì)算分離

OceanBase 早期版本支持本地部署，后來逐步支持阿里云和 AWS 等多云部署，存儲計(jì)算分離是云數(shù)據(jù)庫的標(biāo)配，有兩種設(shè)計(jì)思路：

第一種，數(shù)據(jù)庫內(nèi)部實(shí)現(xiàn)存儲計(jì)算分離。 具體做法是將數(shù)據(jù)庫區(qū)分為 SQL 層和 KV 層， SQL 層無狀態(tài)用來做計(jì)算，KV 層用來做存儲。這種方式的好處是實(shí)現(xiàn)簡單，可以把可擴(kuò)展和高可用等分布式特性下移到 KV 層，事務(wù)處理構(gòu)建在一個(gè)可擴(kuò)展、高可用的分布式 KV 之上；當(dāng)然，問題也非常的顯著，這個(gè)方案犧牲了性能和開放性，每次 SQL 操作都需要一次 RPC 交互且需要首先將外部數(shù)據(jù)導(dǎo)入到數(shù)據(jù)庫中。

第二種，數(shù)據(jù)庫與文件層之間做存儲計(jì)算分離。 具體做法是拋開 SQL 和 KV 分層方案，數(shù)據(jù)庫讀寫數(shù)據(jù)塊時(shí)支持本地或者遠(yuǎn)程的各種分布式文件系統(tǒng)，數(shù)據(jù)庫用來做計(jì)算，文件層用來做存儲。這種方式最大的難點(diǎn)是需要將高可用和可擴(kuò)展的處理融入到分布式事務(wù)，實(shí)現(xiàn)復(fù)雜，好處是保證了性能和開放性，數(shù)據(jù)庫內(nèi)部的 SQL 和 KV 模塊之間不再需要 RPC 交互，且能夠適配多云平臺上的各種存儲系統(tǒng)。

OceanBase 4.0 選擇了第二種方案，我稱之為“開放的存儲計(jì)算分離”。 另外，為了更好地適配不同云平臺，OceanBase 在設(shè)計(jì)存儲格式時(shí)降低了對外部文件系統(tǒng)的依賴。OceanBase 存儲引擎是類 LSM Tree 格式，將 SSTable 劃分為 2MB 大小的宏塊，LSM Tree 引擎執(zhí)行 Compaction 操作時(shí)，只有修改過的 2MB 宏塊才需要被重寫。每次寫宏塊操作都是異步的，選擇 2MB 宏塊大小也能夠很好地發(fā)揮不同云平臺上各種分布式文件系統(tǒng)的性能。

通過這種方式，可以降低對底層存儲系統(tǒng)的依賴，用戶可按實(shí)際業(yè)務(wù)需求，將數(shù)據(jù)庫部署到不同的云平臺甚至多云，并確保系統(tǒng)穩(wěn)定和高性能。

小就是大：為規(guī)?；鴳?zhàn)

我認(rèn)為未來單機(jī)分布式一體化領(lǐng)域會發(fā)展出一個(gè)與 MySQL、PostgreSQL 同等規(guī)模的技術(shù)社區(qū)，這類系統(tǒng)也會有百萬量級的企業(yè)用戶。按照“二八原理”，大部分用戶的數(shù)據(jù)一臺機(jī)器就能放下，但用戶也有快速發(fā)展業(yè)務(wù)的需求，一體化架構(gòu)能夠很好地解決這個(gè)矛盾。分布式數(shù)據(jù)庫的復(fù)雜度肯定是遠(yuǎn)高于集中式數(shù)據(jù)庫的，一體化架構(gòu)能夠在用戶規(guī)模還小的時(shí)候?qū)⑹褂瞄T檻降低到集中式數(shù)據(jù)庫的水平，同時(shí)，不需要提前擔(dān)心業(yè)務(wù)發(fā)展帶來的擴(kuò)展性問題，一次選擇終身受用。為了擴(kuò)大使用規(guī)模，需要：

第一，支持單機(jī)部署和小規(guī)格部署。 OceanBase 有一個(gè)很有意思的設(shè)計(jì)：每個(gè)分布式系統(tǒng)都會有一個(gè)總控節(jié)點(diǎn)，用于全局管理調(diào)度。OceanBase 的總控節(jié)點(diǎn)并不是一個(gè)單獨(dú)的進(jìn)程，而是一個(gè)服務(wù) RootService，集成到 OBServer 里面。這個(gè)設(shè)計(jì)方案的好處就在于單節(jié)點(diǎn)部署只有一個(gè)進(jìn)程，且能夠在線增加 OBServer，既實(shí)現(xiàn)了單節(jié)點(diǎn)最低配置，又實(shí)現(xiàn)了單機(jī)和分布式架構(gòu)的統(tǒng)一。OceanBase 4.0 將部署規(guī)格降低到 4C8G，且未來還會進(jìn)一步降低。

第二，兼容集中式數(shù)據(jù)庫的行為和使用方式。 作為一個(gè)全新的自研數(shù)據(jù)庫，OceanBase 到今天為止仍然堅(jiān)持兼容 MySQL 和 Oracle 的技術(shù)路線，原則上不創(chuàng)造新的使用語法。我們希望能夠支持業(yè)務(wù)平滑遷移，基本不修改業(yè)務(wù)代碼即可由集中式數(shù)據(jù)庫遷移過來。OceanBase 3.x 已經(jīng)支持了存儲過程、觸發(fā)器、外鍵、XA 等功能，OceanBase 4.0 進(jìn)一步增強(qiáng)了對通用 DDL、表鎖、通用 LOB、GIS、JSON 等功能支持。

第三，走完全開源的技術(shù)路線。 2021 年 6 月 1 日我們宣布正式開源，當(dāng)時(shí)開源分支和商業(yè)分支還是兩個(gè)不同的代碼分支，由 OceanBase 研發(fā)團(tuán)隊(duì)定期將商業(yè)分支的代碼 patch 到開源分支。這種方式導(dǎo)致 OceanBase 開源分支總是會落后商業(yè)分支一段時(shí)間，而 OceanBase 4.0 之后我們更進(jìn)一步，把開源分支和商業(yè)分支合并成一個(gè)代碼分支，使得二者完全同步。

穩(wěn)定可靠是第一要素：追求極致性能和極致高可用

數(shù)據(jù)庫作為基礎(chǔ)軟件，需要滿足看得見的、看不見的很多需求，例如穩(wěn)定可靠、性能、成本、高可用、SQL 支持、易用性，等等。從 OceanBase 的技術(shù)理念角度看，首先必須確保穩(wěn)定可靠，所有其它需求都必須為之讓步。例如，OceanBase 系統(tǒng)內(nèi)部有一個(gè)數(shù)據(jù)校驗(yàn)機(jī)制，自動(dòng)對多個(gè)副本之間進(jìn)行實(shí)時(shí)的事務(wù)一致性校驗(yàn)和定期的基線數(shù)據(jù)一致性校驗(yàn)，為了實(shí)現(xiàn)該校驗(yàn)功能，會犧牲一些性能，且對存儲格式的設(shè)計(jì)方案有一定約束，但這是必須要做的，穩(wěn)定可靠是我們?yōu)榭蛻魣?jiān)守的第一要素，也是 OceanBase 數(shù)據(jù)庫最基本最樸素的第一原則。

數(shù)據(jù)庫本質(zhì)的東西還是跑得有多快，成本做到多低。只有追求極致性能的數(shù)據(jù)庫才可以應(yīng)用到核心場景。數(shù)據(jù)庫的性能相當(dāng)于芯片的制程，有的數(shù)據(jù)庫性能差，相當(dāng)于是 28nm 技術(shù)，也能應(yīng)用在一些模擬芯片的場景，有些數(shù)據(jù)庫性能好，相當(dāng)于是 7nm 技術(shù)，能夠應(yīng)用在所有場景，包括對性能要求很高的手機(jī)等。

OceanBase 4.0 使用 C++ 語言，但我們不允許使用 C++ 語言的高級功能（包括C++ STL），只使用 C++ class 等基礎(chǔ)功能用于組織代碼。我們在數(shù)據(jù)庫內(nèi)部管理所有的內(nèi)存和 IO 使用，而不是交給底層的操作系統(tǒng)。為了優(yōu)化性能，我們需要優(yōu)化每個(gè)算子，盡可能減少每條 SQL 語句執(zhí)行過程中的 CPU 指令數(shù)。對于一個(gè)分布式數(shù)據(jù)庫，往往還會遇到如下性能挑戰(zhàn)：

• 主備強(qiáng)同步。強(qiáng)同步會增加事務(wù)提交的延遲，如果讓 SQL 執(zhí)行線程等待強(qiáng)同步返回，將會帶來大量的線程上下文切換開銷。OceanBase 的做法是異步化，SQL 執(zhí)行線程提交同步任務(wù)后立即處理下一條 SQL 語句，等到強(qiáng)同步成功后再通過回調(diào)函數(shù)應(yīng)答客戶端。

• 類 LSM Tree 查詢性能。類 LSM Tree 引擎讀取時(shí)需要合并磁盤中的 SSTable 和內(nèi)存中的 MemTable，這個(gè)操作會影響查詢性能，涉及到 Compaction 策略，查詢算子的設(shè)計(jì)，等等，需要不斷優(yōu)化。

• 跨服務(wù)器操作性能。這里面既涉及到分布式事務(wù)，也涉及到 SQL 語句遠(yuǎn)程執(zhí)行的性能，需要將 SQL 執(zhí)行盡可能本地化，并不斷優(yōu)化遠(yuǎn)程執(zhí)行的效率。

OceanBase 從 0.5 版本開始就將 Paxos 融入到數(shù)據(jù)庫中實(shí)現(xiàn)無損容災(zāi)，今天，OceanBase 首創(chuàng)的“RPO=0，RTO < 30秒“已經(jīng)成為數(shù)據(jù)庫行業(yè)高可用的事實(shí)標(biāo)準(zhǔn)。當(dāng)然，30 秒之內(nèi)恢復(fù)（RTO < 30 秒）并不是絕對的，取決于大量分區(qū) Paxos 選舉的租約時(shí)間和改選時(shí)間。

隨著 OceanBase 4.0 進(jìn)入單機(jī)分布式一體化架構(gòu)，再加上我們進(jìn)一步優(yōu)化 Paxos 選舉協(xié)議及全面探活機(jī)制，最終能夠做到 RTO < 8秒，給業(yè)務(wù)帶來更強(qiáng)的的持續(xù)可用力。 從 30 秒到 8 秒，這短短 22 秒的提升看似簡單，但背后非常復(fù)雜。舉一個(gè)例子，F(xiàn)1 方程式比賽中有一個(gè)必須的環(huán)節(jié)就是換胎，這個(gè)過程是爭分奪秒的。從 1950 年代需要分鐘級到現(xiàn)在最快記錄 1.92 秒。數(shù)據(jù)庫的運(yùn)行就像持續(xù)運(yùn)行的賽車比賽，RTO 就像中間的換胎環(huán)節(jié)必須爭分奪秒。而我們更難的地方在于 F1 的換胎環(huán)節(jié)是提前規(guī)劃，一個(gè) 10 多人的團(tuán)隊(duì)來完成的。但數(shù)據(jù)庫的故障是任何時(shí)間都可能發(fā)生，且完全不需要人工參與。

寫在最后：與用戶和開發(fā)者共同成長

這次 OceanBase 發(fā)布會的 4.0 小魚通過動(dòng)態(tài)日志流實(shí)現(xiàn)了單機(jī)分布式一體化架構(gòu)，支持單機(jī)小規(guī)格部署，在現(xiàn)場演練的環(huán)節(jié)我們看到，在同等硬件環(huán)境下，OceanBase 4.0 單機(jī) sysbench 基準(zhǔn)測試性能好于 MySQL。同時(shí)，4.0 版本也具備面向多云的靈活、簡單、開放，以及規(guī)?；敵龅哪芰?。當(dāng)然，每個(gè)版本走向成熟都離不開大量真實(shí)業(yè)務(wù)場景的打磨，Serverless 和 HTAP 等特性也在不斷完善過程中。

OceanBase 4.0 的很多創(chuàng)新和想法來源于用戶的需求或者建議，我們也會一直堅(jiān)持 MySQL 模式完全開源的策略，和我們的用戶、開發(fā)者一起，把單機(jī)分布式一體化架構(gòu)真正做成數(shù)據(jù)庫的主流，發(fā)展出一個(gè)與 MySQL、PostgreSQL 同等規(guī)模的一體化數(shù)據(jù)庫產(chǎn)品和社區(qū)。文章來源地址http://www.zghlxwxcb.cn/news/detail-407710.html

到了這里，關(guān)于OceanBase 4.0：當(dāng)我們談單機(jī)分布式一體化架構(gòu)時(shí)，我們在說什么？的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！