![](http://img.blog.itpub.net/blog/2023/01/09/7c84347e790d6626.png?x-oss-process=style/bb)

2022 年 12 月 14 日~16 日，由 IT168 聯合旗下 ITPUB、ChinaUnix 兩大技術社群主辦的第 13 屆中國資料庫技術大會（DTCC 2022）線上上隆重召開。大會以“資料智慧 價值創新”為主題，上百位技術領袖齊聚雲端，進行多維度、多視角、多層級的交流碰撞，為廣大資料領域從業人士提供一場年度技術盛宴。

**OceanBase 首席架構師楊志豐（花名：竹翁），在主論壇帶來題為《OceanBase 4.0：單機分散式一體化的技術演進》的演講，和業內分享 OceanBase 從 0.5 版本到 4.0 版本的技術架構發展與演變。**

![Image](https://img.alicdn.com/imgextra/i3/O1CN01zQq6d725yYva8nQQr_!!6000000007595-0-tps-1080-601.jpg)

**以下為 OceanBase 首席架構師楊志豐在 DTCC 2022 上的發言實錄。**

大家好，我是 OceanBase 的楊志豐，今天和大家分享的題目是《OceanBase 4.0：單機分散式一體化的技術演進》，主要內容更加偏向技術解讀，探討架構演進的同時，會與大家分享 OceanBase 對於單機分散式一體化架構的理解和思考。

在今年 8 月 10 日 OceanBase 年度釋出會上，我們正式釋出了 OceanBase 4.0 小魚，這個版本有一個形象的比喻叫做“小就是大”， **我們希望透過這個版本架構的變化，使得 OceanBase 可以從原來支援大型企業為主，真正走向中小型企業。** 使用者可以使用一個 OceanBase 資料庫，在企業或業務發展的不同階段都能使用單個資料庫，不用做遷移。我今天將從技術的視角去分享一下這背後技術的原理是如何思考的。

## 12年，從OceanBase0.5到4.0

### ▋ OceanBase 0.5~3.0

OceanBase 從 2010 年開始研發，下面是 OceanBase 0.5 版本的整體架構圖，彼時 OceanBase 分成儲存和計算兩層。上一層是無狀態提供 SQL 服務的服務層，下一層是由兩種 server 共同組成的儲存叢集。

![Image](https://img.alicdn.com/imgextra/i1/O1CN01BYxE041nl8E0iqcgJ_!!6000000005129-2-tps-769-388.png)

這樣的架構能夠使 OceanBase 比較好的支撐類似於淘寶收藏夾的業務，具有一定的擴充套件性，特別是讀的擴充套件性比較強，並且 SQL 層是無狀態的，可以自由的伸縮。

但同時，這個架構面臨最主要的問題是由於寫入的節點為 UpdateServer 節點，其是單點寫入、多點讀的架構，會導致在更大規模併發要求下，沒有辦法進行擴充套件。

僅從這幅圖上還有一個不容易被意識到的問題：我們發現以這樣一個方式去割裂儲存層和 SQL 層之後會有一個很大的問題，查詢時延不好控制。實際上網路服務很難控制時延，會有一些抖動，如果對時延要求極高情況下，很難控制時延抖動。

為了解決上述問題，OceanBase 摒棄之前的架構，發展出了 OceanBase1.0 - 3.0 的架構，整體上來說是一個完全對等的節點，所有的節點都可以在處理 SQL 的同時，處理事務並儲存資料。在這幅示意圖中，縱向方向是分散式可擴充套件層，橫向方向是複製層。橫向方向提供服務高可用能力，縱向是透過不斷加機器去提升整個服務的擴充套件性。

![Image](https://img.alicdn.com/imgextra/i2/O1CN01CRfQ2q1XxT2fZNiN9_!!6000000002990-2-tps-785-388.png)

演進到 4.0 版本之前，原有的架構已經有了非常好的擴充套件性。在這一擴充套件性下，我們用 3.0 版本參加了 TPC-C 測試，OceanBase 是當時唯一一個透過了 TPC-C 測試的分散式資料庫，也是唯一一個透過 TPC-C 測試的國產資料庫，而且到目前為止保持世界第一。

![Image](https://img.alicdn.com/imgextra/i3/O1CN01vC3Fmc264W4fpv9wN_!!6000000007608-2-tps-771-384.png)

這也反映出 OceanBase 3.0 架構在水平擴充套件性上有非常好的適應性，如圖可以看到，從三個節點到 OceanBase 打榜拿到了 7.07 億 tpmC 指標的情況下，隨著節點數增加，整個tpmC指標有非常好的線性擴充套件性。參加 TPC-C 評測時，OceanBase 透過 1557 臺機器組成的大叢集，在壓測 8 個小時之內，每秒鐘有 2000 萬次事務處理能力。這個結果說明，前面的架構是能支撐非常好的擴充套件性，幾乎這一擴充套件性和併發處理能力是可以滿足絕大多數當前世界上線上服務系統需求的。

### ▋ 引入動態日誌流的 OceanBase 4.0

但隨著業務需求的迭代，我們還是發展出了 4.0 架構，OceanBase 4.0 架構核心的變化，是引入動態日誌流的概念。原來把事務擴充套件和儲存擴充套件的粒度等同起來一起去看，但如果儲存分成了若干個分片，導致事務處理和高可用能力也是以這樣的分片為粒度的。我們在 4.0 版本里把這兩個概念進行了解耦，所以若干個儲存的分片會共享一個事務日誌流以及這個日誌流所對應後面的高可用服務。

![Image](https://img.alicdn.com/imgextra/i4/O1CN013b3y8a1LoVuWRlIvp_!!6000000001346-0-tps-771-385.jpg)

這一變化背後最核心的思路，是我們希望能夠支撐更小的規模下的一些應用。比如螞蟻這樣大規模應用裡，3.0 架構不會遇到瓶頸問題，但隨著 OceanBase 走向通用，特別是各種各樣的中小企業時，如果日誌流的數目和分割槽數繫結到一起的話，在很多場景下是不能適應對中小規模企業支撐的。也就是說，如果日誌流特別多，在越小規模下開銷顯得就會越大。

基於此，我們有必要從以下幾個方面對單機分散式一體化的概念進行解釋：

- OceanBase 單機分散式一體化資料庫體系結構

- OceanBase SQL 引擎的單機分散式一體化

- OceanBase 事務處理的單機分散式一體化

- OceanBase 單機的效能擴充套件性實驗

## OceanBase單機分散式一體化資料庫體系結構

4.0 架構既可以透過分散式方式使用 OceanBase 資料庫，也可以用大家原來熟悉的類似 MySQL 單機方式使用 OceanBase。

第一，如果以單機方式部署 OceanBase，或者在 OceanBase 叢集內部署單容器租戶，都能提供原來使用單機資料庫一樣的效率和效能。

第二，如果使用分散式模式，在租戶層面上、事務層面上以及單條 SQL 執行層面上，都不需要因為引入了分散式而付出額外代價。在這種情況下，需要我們在 SQL 層、儲存層、事務層各層設計上，以一種單機分散式一體化設計的方式去滿足各種情況，在各個層面上做到兼顧。

### ▋ shared-everything or shared-nothing？

在資料庫發展的階段有一個爭論：資料庫應該是基於無共享的叢集去設計，還是使用 shared-everything 架構去設計資料庫，才能夠提供最好的效率？

![Image](https://img.alicdn.com/imgextra/i1/O1CN01MzVT0c1QAjagyRASK_!!6000000001936-0-tps-771-387.jpg)

現在實際的叢集，從物理叢集角度來看，既不是完全 shared-everything，也不是完全 shared-nothing。在每個機器節點上去看單個節點，也是多處理器的結構，很多 CPU，現在有 96 核機器，甚至更大規格的機器，記憶體也是越來越大，使用非常高速系統內的匯流排去和磁碟、和所有外部裝置去做互動，並且有很好的網路。所以現實使用的叢集不能簡單看作是 shared-nothing，就是單機內有非常強的計算和儲存的處理能力，為什麼不利用這樣的能力呢？這也是單機資料庫或集中資料庫所有的 scale-up 的方向。分散式資料庫不應該只考慮水平的擴充套件，而不去考慮垂直擴充套件的問題。

如果想利用硬體垂直擴充套件能力的話，資料庫應該怎麼做？可以設想一下有這樣一種分散式資料庫，以下方左圖為例，這是現在很多分散式資料庫的實際架構圖，有點像 OceanBase 0.5 的結構，有專門的計算節點和儲存節點。計算節點是一層，儲存節點是另外一層，這兩層做了單獨抽象，它們中間會透過 GTM/TSO 處理全域性事務的模組，做多機互動時也需要和這個模組做互動。

![Image](https://img.alicdn.com/imgextra/i4/O1CN01JfnQC41atIHK3OpCP_!!6000000003387-2-tps-769-385.png)

如果把這一分散式資料庫以非常簡單的方式塞到了一個節點上，讓它以單機的方式去執行，這裡最大的問題是什麼？就是這些元件之間的互動在單機內工作時開銷非常大，這種開銷本質上對於 MySQL 這樣的單機資料庫是額外的非必要開銷，所以顯然這樣一種簡單的方式是很難以和單機資料庫相比的。

### ▋ 單機分散式一體化：兼顧單機和分散式場景

如果在單機內來看，單機內要有完全獨立的單機 SQL、事務和儲存三層，相對另外一種方式是所謂的分散式資料庫會把分散式 SQL 引擎、分散式事務引擎和分散式儲存引擎也看作是獨立的三層。我們希望同時去糅合單機這三種引擎和分散式這三種引擎，使用同一套程式碼，甚至可以動態地去做變換和互動。

![Image](https://img.alicdn.com/imgextra/i1/O1CN01hgtMrl1bCWut6gbDF_!!6000000003429-0-tps-771-387.jpg)

OceanBase所認為單機分散式一體化DB架構

除此之外，所謂單機資料庫，要在單機內充分發揮擴充套件效能力，需要在 SQL 層提供並行執行的能力，需要在事務層去提供類似 MVCC 的擴充套件性核心技術，並且使用類似組提交的技術，使得單機內多個事務也可以併發去執行。在儲存層，需要能夠支撐單機並行的 IO，當單機內增加更多磁碟和儲存頻寬時，可以能夠充分利用。

分散式內的單機資料庫，不能簡單把分散式的擴充套件性做好就行了，即使是以分散式方式去部署時，單機效率也必須是非常高的，需要能夠高效去支援序列的執行，高效的執行在分散式事務的情況下，使得單機事務能夠有自適應的最佳化。

對 OceanBase 來說，還獨創引入了一個創新技術——單機 LSM-Tree 儲存引擎。如果以單機設計的視角去看的話，確實只能做前後臺可能會互相影響的合併操作，但我們不是一個單機資料庫，如果真正是分散式部署的話，又可以引入一種分散式策略，使得多個副本之間可以做錯峰輪轉的合併。所以在整體設計上，在 SQL 層、事務層和儲存層裡，我們每一層的設計都是兼顧了單機和分散式的場景，使得它在單機和分散式場景下都沒有多餘額外的開銷，這是我們的設計目標。

這樣我們就要求有 2 個基本特性：

- 第一，在單機情況下工作時，OceanBase 沒有額外其他的元件，就是一個單程式就可以工作，沒有多餘程式之間複雜的互動。在單程式、多執行緒模型下，各個元件實際上都是使用簡單的函式呼叫就可以完成互動，這是非常關鍵的一點。

- 第二，所有的元件之間既在圖裡有縱向的互動，也就是 SQL 層、事務層、儲存層。如果在單機內就用函式呼叫的方式去做互動；如果在節點之間，在必要時必須要有節點之間的互動時，才透過 RPC 去互動。

相應於前面所講的 shared-nothing 和 shared-everything 結合的架構，實際上在每個 OBserver 節點內部，SQL 和事務儲存之間都使用函式呼叫直接去互動的，這和單機資料庫是一樣的，當我們要在多節點之間互動時，也會打破所謂嚴格的去做分層的，選擇最優的、最合適的、效率最高的方案。

例如，一個節點的 SQL 向另外一個節點上的 SQL 層發一個訊息，讓這個 SQL 層再去訪問它的儲存節點，這裡最優的取決於你要做什麼，不同的負載下面可能有不同的選擇，OceanBase 可以直接訪問一個遠端儲存。在事務處理層也是如此，如果單機事務下不需要和別人去做互動，就不需要和其他的事務元件進行互動。

![Image](https://img.alicdn.com/imgextra/i2/O1CN01XTAZrs1ajfxn8zOJ4_!!6000000003366-2-tps-776-383.png)

OceanBase 執行引擎，要處理很多情況，為什麼要做這麼多細分呢？是因為希望在每種情況下都能自適應做到最優。大的層面上來說，每一條 SQL 的執行都有兩種模式：序列執行或並行執行。

![Image](https://img.alicdn.com/imgextra/i2/O1CN01iqUar01HVV0KRbZy6_!!6000000000763-2-tps-768-372.png)

### ▋ 序列執行-單機內並行-分散式並行

在序列執行時，如果這個表或者這個分割槽是位於本機的，這條路線和本機 SQL 的處理、單機 SQL 的處理是沒有任何區別的。如果所訪問的是另外一臺節點上的資料，有兩種做法：把資料遠端拉取到本機來，叫做遠端資料獲取服務。遠端執行，如果單個事務內所訪問的資料都位於另外一個節點上，會把整個事務處理和儲存訪問過程全部傳送到另外一個節點上，將整個事務提交全部代理給它，然後再返回來；如果單條 SQL 訪問的資料位於很多個節點上，可以把計算壓到每個節點上，並且為了能夠達到序列執行（在單機情況下開銷最小）的效果，還會提供分散式執行能力，即把計算壓給每個節點，讓它在本機做處理，最後做彙總，並行度只有1，不會因為這個而增加資源額外的消耗。如果是並行執行，支援並行查詢，對並行查詢分本機的並行和分散式並行，同時支援 DML 寫入操作的並行。

對於序列的執行，一般開銷最小。這種執行計劃，在單機做序列的掃描，既沒有上下文切換，也沒有遠端資料的訪問，是非常高效的。對於當前很多小規模業務來說，序列執行的處理方式足夠。但如果需要訪問大量資料時，可以在 OceanBase 單機內引入並行能力，目前，這個能力很多開源的單機資料庫還不支援，但只要有足夠多的 CPU，是可以透過並行的方式使得單條 SQL 處理能力線性地縮短時間。只要有一個高效能多核伺服器增加並行就可以了。

![Image](https://img.alicdn.com/imgextra/i1/O1CN01AjxM7e1GlhOfDXpgx_!!6000000000663-2-tps-764-384.png)

針對同樣形式的分散式執行計劃，可以讓它在多機上分散式去做並行，這樣可以支撐更大的規模，突破單機 CPU 的數目，去做更大規模的並行，比如從幾百核到幾千核的能力。

### ▋ 序列執行：DAS 執行和分散式執行

針對序列執行有兩種執行方式：DAS 執行和分散式執行。

DAS 執行，方式之一是拉資料，如果資料位於遠端，並且是簡單的點查詢或索引訪問回表查詢，這種方式資源消耗是最小的，我們會把這個資料拉取到本地，它的執行計劃和本地的執行計劃從形式上、形狀上是沒有區別的，在執行器裡會自動去做這個動作。但有時候把資料拉過來，不如把計算壓下去，所以我們同時支援了分散式執行，需要強調的是這種分散式執行並沒有額外增加資源的消耗，我們會保證它的並行度和前面 DAS 執行是一樣的。

對於某些特定的查詢或大規模掃描，我們會動態自適應選擇這兩者，基於代價去評估哪種執行效果最好。

![Image](https://img.alicdn.com/imgextra/i1/O1CN01C00jpA1SLO2BAPEHw_!!6000000002230-2-tps-768-382.png)

並行執行框架可以自適應處理單機內並行和分散式並行，它們是同一套框架。這裡所有並行處理的 Worker 既可以是本機上多個執行緒，也可以是位於很多個節點上的執行緒，我們在分散式執行框架裡有一層自適應資料的傳輸層，對於單機內的並行，傳輸層會自動把執行緒之間的資料互動轉換成記憶體複製。這樣把不同的兩種場景完全由資料傳輸層抽象掉了，實際上並行執行引擎對於單機內的並行和分散式並行，在排程層的實現上是沒有區別的。

## OceanBase 事務處理的單機分散式一體化

既然做擴充套件性更難的是事務處理，那麼事務處理過程中為什麼要兼顧單機和分散式？我們從下圖開始解釋：

![Image](https://img.alicdn.com/imgextra/i3/O1CN01eYAS1t1jVK5mlv1mJ_!!6000000004553-2-tps-768-389.png)

左圖是傳統的分散式事務處理過程，分成事務的開啟階段和事務的提交階段，右圖是 OceanBase 的事務處理過程。

OceanBase 事務提交協議提出一個新思路，叫做參與者既協調者的兩階段提交協議。OceanBase 兩階段提交比起左圖，從提交事務到提交成功這個時間之內，我們所處理的訊息量和寫入的日誌量比左邊這幅圖少很多，這使得整個兩階段提交的時延有很大的優勢，這個優勢也會支撐我們後面要講的即使是在 OceanBase 分散式場景下，事務的處理能力也不會像很多其他的分散式資料庫一樣開銷非常大。

如果單個事務只涉及到單個日誌流，一般來說如果業務資料量在負載均衡能夠容忍的粒度之內，日誌流不需要特別多，很大機率上，完全以單機方式去部署時，只有一個日誌流，而一個日誌流內任何的事務是不需要走兩階段提交的。

事務不能獨立地去看，在一個分散式系統裡可能既有涉及到多日誌流的事務，也有涉及到單日誌流的事務。兩者之間是有關係的，對於單日誌流事務來說，OceanBase 引入了獨創的最佳化，使得 OceanBase 單日誌流事務的處理過程中，不需要去訪問全域性的時間服務，只需要訪問本地特有的時間服務，同時保證全域性的一致性。

如果拋開分散式事務提交的協議來看，所有的事務以及整個工作負載都沒有分散式事務的話，整個事務處理過程和單機資料庫是相當的。

## OceanBase單機的效能擴充套件性實驗

下面的實驗以三個節點的方式，也就是說節點和節點之間是副本的關係，實際上事務處理是單機完成的，就把它看作是單機，OceanBase 隨著硬體效能的增強擴充套件性實驗，從 4 核到 64 核，可以做到基本線性擴充套件的。從 90000、180000、370000、690000、1200000。在 64 核規模範圍之內，OceanBase 可以提供線性的擴充套件。

![Image](https://img.alicdn.com/imgextra/i1/O1CN01KHUIa423xzCKRELn1_!!6000000007323-2-tps-766-378.png)

大家對分散式資料庫有一個誤解，或者很多分散式資料庫可能給大家形成一個固有的印象：原來某單機資料庫或集中式資料庫，可以用一臺機器支撐一個業務，引入分散式資料庫以後，擴充套件性好了，但如果想支援同樣的併發量，可能不得不使用三個節點共同來提供服務，才能達到單機同樣的效能和效率。

![Image](https://img.alicdn.com/imgextra/i2/O1CN01Rhr2Yg1L7v4kYa5FP_!!6000000001253-2-tps-768-380.png)

這顯然不是使用者所希望的分散式資料庫。關鍵問題在於看效能時，不光要看吞吐量的增加，還要看單個 SQL 或單個事務從應用視角來看多快能處理完，因為事務處理從單個部分來看，我們希望實現的是隨著分散式事務比例的增加，時延是在增加的，但是關鍵有兩點：即使是由完全的分散式事務組成，時延也需要足夠低；以及當單機事務沒那麼多的時候，請不要買一贈一，給我贈送額外時延。

第一，SQL 層、儲存層、事務層，即使在分散式場景下，也需要為單機粒度的事務和 SQL 做最佳化。

第二，如果三個元件之間完全做了獨立的分層，實際上使用者是缺乏控制手段的，能不能不要發一個 RPC 去訪問一個資料，如何能放到一個節點上省掉這些 RPC。所以我們希望能夠讓使用者和 DBA 在非常極致效能要求下有這樣一個控制的能力。好比 OceanBase 為什麼要用 C++ 去實現，就希望能充分控制記憶體，控制所有時延的消耗。可以把一個事情能夠做精確的控制，可控性非常重要。同樣我們分割槽的能力也需要能夠控制的，比如透過提供 Table-group，能夠使得表之間沒有分散式事務開銷的。

### ▋ OceanBase 4.0 VS MySQL 8.0

如圖，如果沒有分散式事務場景下，以分散式情況下部署，單機效果到底怎麼樣？OceanBase 4.0 和 MySQL 8.0 企業版在同樣硬體情況下做了對比，在硬體 32 核規格下，黃色是 OceanBase，從資料上可以看到，OceanBase 4.0 在相同硬體環境下效能優於 MySQL，即使是小規模場景下，也可以放心地使用 OceanBase 分散式資料庫。

![Image](https://img.alicdn.com/imgextra/i1/O1CN01FVewE71nwa7zMCSGZ_!!6000000005154-2-tps-762-382.png)

使用以後有什麼好處？

傳統使用 MySQL 主備庫的方式有一個很明顯的問題，就是容災時會丟資料，這個問題無法解決，而 OceanBase 首先肯定可以做三機高可用，從 4.0 以後正式會推薦大家一種部署方式——每個 ZONE 裡就有一個 OceanBase 的節點，叫做單機三副本，沒有太多額外的開銷。OBProxy 層提供了業務連線不斷的能力，如果不需要這樣的能力，可以像使用 MySQL 一樣不需要部署 OBProxy，就可以達到比 MySQL 更好的高可用的能力。

比如最開始是完全單機部署，業務做一些原型實驗就夠了。隨著業務規模擴大，對於計算和儲存的要求越來越高過程中，可以把這一節點做垂直的擴充套件，原來是 4 核，現在變成 16 核，如果在雲上買，可以在 ECS 上直接申請提升規格，OceanBase 是可以充分利用所有增加的 CPU，提供一個更好的效能。

另外一個維度是，如果現在不需要高可用能力，不想付出三個節點的成本，那麼主備庫就夠了，OceanBase 同樣可以提供主備庫能力，這種高可用能力也是和傳統的資料庫相當的，主備庫也是我們的一個選項。

### ▋ OceanBase 多形態、動態可變

如果高可用能力要求越來越高，可以使用三節點。後面可能隨著業務的發展或企業規模的擴大，可以進化成一個完整形態的 OceanBase 分散式資料庫。更關鍵的是，這樣一個形態的變換或擴充套件，裡面每一個箭頭都可以反方向去做，每一個箭頭的變換都是動態生效的，不需要去替換 OceanBase 二進位制，都可以全功能地在三種形態下使用，去做動態的變換。

![Image]()

### ▋ OceanBase 內仍儲存原生多租戶

我們在設計 OceanBase 單機分散式一體化架構時，思考了一個問題。大家從使用 MySQL 到使用 OceanBase 有一個不適應的地方：OceanBase 有多租戶的能力，大家進來需要建立一個租戶，後來我們和使用者、客戶做了很多討論，最後確定多租戶的特性即使是在單機情況下也是要保留的，特別是私有化部署和公有云部署時。

![Image](https://img.alicdn.com/imgextra/i3/O1CN01z4jBUn21SGX3VlgsD_!!6000000006983-2-tps-768-383.png)

如果在私有化情況下去部署，很多小企業可能不想去部署複雜伺服器的環節，但現在買不到一核機器，有最小規格的硬體也有很多核，這種情況下如果不需要其他額外基礎設施的話，OceanBase 的原生多租戶能力，可以把一個機器切成很多個資料庫來使用，無須額外的容器管理的系統。

對於大規格來說，OceanBase 部署後可以做非常靈活的垂直伸縮。對於分散式不言而喻，如果在分散式場景下，更是可以有垂直擴充套件和水平擴充套件兩個方向的能力，並且這種能力是以租戶為單位的。一個租戶是 4 核×3 個容器，另外一個機器希望以單機方式執行，可以直接給它 16 核，或者不希望做分散式，都是可以的，此時，多租戶提供了一個可管理的粒度。

對於公有云的部署，或者希望在你的企業裡一個OceanBase 大叢集，就更有價值了。即使是小規格，比如一個 OceanBase 的 server 透過 16 核方式啟動起來，但希望有一個更小力度的租戶，比如 0.5 核的租戶。在資料庫內部，OceanBase 是可以支援 0.5 核租戶的，幫助使用者更加精細的控制成本，可以在雲上做租戶內垂直擴充套件，也可以租戶間負載均衡，這兩個維度都可以去做彈性、自由伸縮。

在不同的形態下，我們都保留了 OceanBase 所有的功能以及多租戶的能力。

## 寫在最後

對使用者來說，OceanBase 單機分散式一體化能力，有兩個維度的價值和意義：

第一，OceanBase 既可以單機方式部署，提供單機資料庫相當的能力，並且可以在任何時刻，管理員可以去做形態的變換，由一個單機的形態變成分散式形態，從分散式形態變回單機形態，都可以做動態變換的。

第二，即使是在分散式部署場景下，相較於其他分層的分散式資料庫，OceanBase 的效能有很大的優勢，如果使用者做精細控制的話，單機事務比例增加以後，效率和單機資料庫也是相當的。

我的分享就到這裡，感謝大家對 OceanBase 的關注。謝謝大家！

從0.5到4.0，OceanBase單機分散式一體化的技術演進｜DTCC 2022

相關文章