> **作者：阿福（苑澤福）**，OceanBase 社群版深度使用者、社群文件貢獻者，Greenplum中文社群資深成員，曾供職於鼎興達、瀚高，擁有豐富的資料庫開發運維經驗，近年來一直專注於分散式資料庫研究與推廣。本文為阿福對OceanBase 社群版 4.0 的測評體驗，歡迎大家評論區與作者探討交流！

近些年國產化資料庫如雨後春筍般冒出並遍地開花。據某技術平臺不完全統計，國產化資料庫（見圖 1 ）已達 200 餘個，對於這些資料庫的名字，即使作為多年資料庫從業者的我，也有很多是第一次聽說。在這競爭激烈的資料庫行業裡，要想長久佔據一席之地，順應市場發展並打磨好自己的產品才是硬道理。

![Image](https://img.alicdn.com/imgextra/i1/O1CN012Qixb721Ez2elACD7_!!6000000006954-2-tps-1080-276.png)

圖1 國產化資料庫部分截圖

## 資料庫發展需適應市場變化

業界有一句老話叫作 “市場永遠是對的”，大概意思是當前市場表現了所有影響因素，任何事物都應該遵循當前市場的發展規律。縱觀國際市場資料庫發展狀況，曾經的資料庫老大 Oracle 因為佈局雲端計算太晚已經被亞馬遜、微軟甩開很長一段距離，老牌資料庫 Db2 幾乎沒落；雲資料倉儲 Snowflake、雲資料庫 CoackRoachDB 等產品因為順應雲端計算發展而一騎絕塵。在國內資料庫市場，從早期集中式資料庫需求旺盛的四朵金花時代，大步跨入當前集中式、分散式資料庫勢均力敵的百花齊放時代。在分散式資料庫領域，為順應市場發展不斷改變自身的當屬 OceanBase ，從早期只服務淘寶收藏夾的簡單業務，到 SQL 和 ACID 的支援，再到後來的多租戶細粒度資源管控，現在又推出單機分散式一體化版本，在追求極致服務市場的路上，OceanBase 從未停歇。從整個市場上看，有能力有魄力頻頻做大版本變動的資料庫，可謂是少之又少。

眾所周知，**OceanBase 社群版於 2021 年 6 月 1 日宣佈開源，開放 300 多萬行核心程式碼構建開源生態。開源開放不止意味著把自研資料庫拿出來給大家用，還意味著 OceanBase 不能像以往一樣只專注於金融類業務場景了，迎面而來的是各種各樣的場景和需求。** 在開源後的短短一年多時間裡，OceanBase 不斷“挑戰自我”，打磨核心能力，修復周邊 bug。從資料庫排行榜（見圖 2）中能看出市場也給予了 OceanBase 正向反饋。

![Image](https://img.alicdn.com/imgextra/i3/O1CN01Ds9qkX1paiRZ93Ll1_!!6000000005377-2-tps-1080-509.png)

圖2 墨天輪資料庫排行榜

今年雲棲大會上，OceanBase 社群版 4.0 釋出，不僅有許多亮眼的功能，還重新整理了資料庫的架構，在業界引發熱烈討論。**本文我們就來一起聊聊，OceanBase 從分散式到單機，再從單機到分散式，在遵循市場發展規律的同時到底發生了哪些變化。**

## 分散式到單機的自我能力突破

OceanBase 自誕生以來，走的一直是分散式 NewSQL 的路，像其他類似產品一樣，比如 CockRoachDB、YugaByteDB 等。分散式 NewSQL 從場景上來講，是為了解決單機資料庫在資料達到一定體量後效能急劇下降的痛點，當然在國產資料庫發展如火如荼的今天，很多時候也被用來當作替換 Oracle 的首選。從實際的應用效果來看，分散式資料庫在金融、運營商等核心業務的替換上，也扮演了重要角色。相比集中式資料庫無論從效能、資料承載量、核心業務 RTO 和 RPO 保證上，達到的效果都比較令人滿意。

### ▋分散式與資源的天然博弈

任何事物都具有兩面性，分散式資料庫在極力保證高可用、高效能的同時，也引入了一些問題：

- 分散式架構會增加事務處理成本，跨節點事務處理可能涉及多節點 JOIN、兩階段事務提交等。

- 代理層的引入，多一層網路轉發，網路成本增加。

- Paxos 協議使資料至少三副本，儲存空間成本增加。

為了儘量緩解這些缺陷帶來的“疼痛”，實際生產過程中通常會透過提高硬體配置來解決，比如引入 I/O 效能更高的 SSD 硬碟、節點伺服器之間採用頻寬更高的萬兆網路、伺服器配置更多的記憶體以快取更多的資料。過高硬體的投入，對很多正在業務發展初期的中小企業來說，無疑是一個巨大的負擔。很多時候，在客戶選型過程中，這些都會影響到最終的決策，尤其是在成本上。筆者曾經不止一次給朋友和客戶推薦過分散式資料庫，均由於公司對資料庫所能提供的資源有限而放棄。

筆者曾經針對小資料量簡單對比過 PostgreSQL 11 和 YugaByteDB 的 sysbench 效能。從下面的壓測結果指標也能看得出來，引入了分散式元件的 YugaByteDB ，能力僅達到 PostgreSQL 的四分之一。在資料體量不夠大時，引入一些分散式特性反而會增加資源整體的消耗，降低效能。

**YugaByteDB 簡單壓測：**

```
[ 300s ] thds: 16 tps: 24594.17 qps: 24594.17 (r/w/o: 24594.17/0.00/0.00) lat (ms,95%): 0.78 err/s: 0.00 reconn/s: 0.00

Throughput:
    events/s (eps):                      24240.1303
    time elapsed:                        300.0030s
    total number of events:              7272111

Threads fairness:
    events (avg/stddev):           454506.9375/16158.17
    execution time (avg/stddev):   299.6535/0.01
```

**PostgreSQL 11 簡單壓測：**

```
[ 300s ] thds: 16 tps: 92068.28 qps: 92068.38 (r/w/o: 92068.38/0.00/0.00) lat (ms,95%): 0.21 err/s: 0.00 reconn/s: 0.00

Throughput:
    events/s (eps):                      92761.8210
    time elapsed:                        300.0019s
    total number of events:              27828723

Threads fairness:
    events (avg/stddev):           1739295.1875/941.82
    execution time (avg/stddev):   299.0144/0.01
```

### ▋ OceanBase 的自我突破

筆者個人認為，OceanBase 在架構設計之初針對以上提到的中小企業資源有限的場景也是做了考慮的，從圖3的常用部署框架中我們可以看到，應用之下的資料庫層由兩部分構成：無狀態的 OB Proxy 和有狀態的 OB Server。做過 OceanBase 3.x 版本手動部署的朋友應該印象比較深刻，每一個 OB Server 都是一個單獨的服務，可以直接接受應用程式的增刪改查。在不考慮分散式特性的前提下，一臺 OB Server 伺服器也能支撐簡單的單機業務。但是在實際生產使用過程中，OceanBase 3.x 不建議大家採用單機部署，因為 3.x 版本暫未正式支援單機部署，效能上單機版本也不如 MySQL 有優勢。

![Image](https://img.alicdn.com/imgextra/i3/O1CN01hee7Dh1WNSHKgPZdL_!!6000000002776-2-tps-1080-632.png)

圖3 OceanBase 常用部署架構

從使用者實際場景來看，單體式資料庫市場是長期存在的。那麼讓 OceanBase 單機可用甚至好用，從 OceanBase 3.x 到 OceanBase 4.x 的進階調整，我看到了兩個變化。

**第一，降低單機部署成本。** 解決使用者普遍反映的資源消耗之痛，讓更多人可以輕鬆入手。

**第二，提升單機執行效能。** 為更多有單機 MySQL 生產需求的使用者，提供更好的替換方案。

首先，為了降低單機部署成本，**OceanBase 4.0 對 OB Server 做了很多深度最佳化，包括降低 CPU、記憶體、磁碟空間對伺服器的要求，支援 4C8GB 的最小規格部署配置；提供了單機 all-in-one 版本部署包，支援 2 分鐘快速拉起單機服務。** 這些最佳化帶來的直觀體驗是，很多之前無法親自上手的小夥伴也可以在自己的膝上型電腦上進行 OceanBase 開發和測試了。在 11 月初拿到了 4.0 版本的釋出包後，我也迅速進行了體驗測試，all-in-one 部署包使用起來確實很方便，並且對資源的消耗降低，不必再擔心分配了 4C8GB 資源但是服務卻無法啟動的問題。

其次，為了提升單機執行效能，進而也能完善分散式執行效能，OceanBase 做了很多改進，**包括：向量化引擎開源，** 可以提升複雜查詢效能，降低複雜查詢響應時間；**資料編碼開源，** 可以進一步提升壓縮比例，為客戶節約儲存空間，同時也降低分散式部署時三副本對儲存空間的損耗；**支援租戶級備份，** 提供更靈活的備份恢復策略；**MySQL 相容性完善，** 逐步為替換單機 MySQL 做準備。

簡單總結一下，從分散式可用到單機可用，對於 OceanBase 來說，是一個自我突破的過程，架構的大調整也意味著官方承認 3.x 版本存在一些架構不足，不能支撐單機能力的提升。還是那句話，在追求極致服務市場的路上，OceanBase 從未停歇。當前的 OceanBase 4.0 單機版本的效能指標已經部分超越 MySQL，隨著版本迭代更新，我相信 OceanBase 的效能優勢會越來越明顯，在滿足中小企業市場對單機資料庫的需求也會越來越有優勢。

## 從單機到分散式，殊途同歸

縱觀當前資料庫行業，任何一款單機資料庫，隨著客戶業務量增長、資料量增大，都會面臨效能瓶頸，或者伴隨著客戶資料重要性的提升，必然會提出高可用的要求，任何一種負責任的資料庫解決方案，都不會讓客戶的資料在單機上裸奔。

我們一起來看看行業內一些經典的解決方案是如何處理這些問題的。

**注：任何一款資料庫都存在多種高可用/效能解決方案，本文受限於筆者經歷，只部分引用，並不能以偏概全，所有引用僅用於本文特定論述場景。*

### ▋ Oracle 共享儲存架構

Oracle 在這麼多年的單體式關係型資料庫行業裡，一直扮演龍頭老大的角色，一直被模仿從未被超越。當 Oracle 遇到單機效能瓶頸，或客戶有高可用需求時，通常會採用 Oracle RAC 架構，如圖 4 是一張 Oracle 19C 的 RAC 叢集架構圖，其底層採用共享儲存，存放資料檔案；上層採用多臺伺服器，擴充套件計算效能。據 Oracle 官方文件，RAC 叢集最多支援 168 個節點，根據實際生產使用經驗，叢集節點數超過 10 個，基本沒什麼意義，網上能找到的公開資料顯示，4-6 個 RAC 節點的效能最好。

![Image](https://img.alicdn.com/imgextra/i3/O1CN01RStPui1xbeB2LKmMB_!!6000000006462-2-tps-500-317.png)
圖4  Oracle 19C 的 RAC 叢集架構

### ▋ MySQL 分庫分表架構

受益於網際網路的發展，MySQL 一直穩居開源資料庫頭把交椅。MySQL 在處理效能瓶頸及高可用問題時，通常採用分庫分表結合 binlog 日誌複製的方式，比如 MyCAT、ShardingSphere。如圖 5 是一張 ShardingSphere 架構圖，底層的資料庫，透過 Sharding-Proxy 指定的規則，將資料進行分片，分佈到不同的資料庫節點（橙色）上。這種輕量級解決方案，曾經是解決 MySQL 效能瓶頸的不二之選。但是像其他技術解讀文章提到的一樣，中介軟體解決方案，並不能完全發揮資料庫自身優勢，覆蓋的場景往往是有限的。並且把資料庫使用的複雜性帶給了使用者，體驗比較差。

![Image](https://img.alicdn.com/imgextra/i4/O1CN01mhKcOm1I8QezNDr1c_!!6000000000848-0-tps-1080-459.jpg)

圖5 ShardingSphere 架構

### ▋PostgreSQL Citus 雙層架構

Citus 的架構就比較有意思了，Citus 是以 extension 外掛的方式對外提供分散式能力（不瞭解的朋友可以查詢一下 PostgreSQL extension 架構），它採用了雙層架構：Coordinator + Worker。體量較小的資料，可以直接放到 Coordinator 節點上，一旦資料體量增加，可以將表一鍵轉化為分散式表，將資料儲存分片儲存到 Worker 節點。這種架構使用較為靈活，特別是在微軟收購 Citus 後，將 Citus 所有核心能力均開源。但是這種架構欠缺一整套解決方案，例如：高可用仍然需要自行配置流複製、叢集組建沒有一體化監控運維工具等。

![Image](https://img.alicdn.com/imgextra/i1/O1CN01efVWAy1obLN8IulEj_!!6000000005243-0-tps-998-520.jpg)

圖6 PostgreSQL Citus架構

### ▋ OceaBase 4.0 單機分散式一體化架構

上面各家單機關係型資料庫，針對效能和高可用的解決方案，要麼像 Oracle 聚焦叢集效能損失擴充套件性，要麼聚焦擴充套件性損失單機綜合能力。在 OceanBase 3.x 階段，其作為一款高效能 HTAP 分散式資料庫，提供了高效能、靈活的擴充套件性、高可用性和可管理性等能力。在升級到 OceaBase 4.0 的單機分散式一體化架構後，不僅提供了分散式能力的進一步提升，還提供了單機生產可用的能力，相比 3.x 版本，OceanBase 4.0 做了以下改進。這些能力的提升和完善，讓 OceanBase 4.0 兼具上面幾種解決方案各自的優勢。

- **自適應日誌流：** 從以表分割槽為單位提升為以 Unit 為單位，減少分散式操作的代價，尤其是日誌。
- **支援超大事務：** 重新設計事務引擎，提升分散式多場景應對能力。
- **RTO < 8s ：** 全新的自動選主協議以及全面的探活機制，將故障場景下系統恢復時間從 30s 降低到 8s。
- **NTP 服務最佳化：** 取消 NTP 依賴，將時鐘偏差從 100ms 提升到 2s，提升叢集穩定性。
- **支援全鏈路追蹤：** OceanBase v4.0 版本設計了一套全鏈路追蹤的機制，能夠提升全鏈路問題定位的效率，貫穿從業務 APP > 客戶端驅動(JDBC, OCI) > 代理（OBProxy）> 資料庫節點（OBServer）到全部流程。

在這些能力的加持下，OceaBase 4.0 的單機分散式一體化架構，給大家帶來了一種新的選擇。當大家的資料庫需求比較小，只需要單體資料庫時，可以從 OceanBase 單機版本入手，隨著業務發展、資料量增加，對資料庫的要求越來越高，此時可以無縫進階為 OceanBase 叢集，自帶多副本高可用，統一訪問入口對應用透明，讀寫分離提升整體效能，分散式架構支援靈活擴充套件。

![Image](https://img.alicdn.com/imgextra/i2/O1CN01bObXOj1VzBHuOaWmb_!!6000000002723-2-tps-1080-260.png)

圖7 OceaBase 單機分散式一體化架構

經過多年市場驗證，分散式資料庫已經成為當前資料庫發展的主要趨勢，包括前面提到的以 OLTP 業務見長的 CockRoachDB、YugaByteDB 及以 OLAP 業務見長的 Greenplum、ClickHouse 等。在國產資料庫領域，也有很多優秀的分散式資料庫產品已經在金融、網際網路等場景替換並超越 Oracle 等傳統產品。隨著 OceanBase 社群版 4.0 的正式上線，充分發揮架構在單機能力基礎之上的分散式能力，其分散式叢集一定會帶來不一樣的體驗。

## 架構升級取決於需求推動

我們傳統使用資料庫的邏輯通常是從單體式資料庫入手，此時如果遇到高可用需求，會採用日誌複製的方式增加熱備副本（也稱為主備架構），隨著資料量的增加，單體式資料庫不能滿足資料儲存和查詢的要求時，會採用分庫分表的資料分片架構，或者直接從單體資料庫遷移到分散式資料庫（見圖 8 ），這樣的架構進階其實是比較複雜且代價高昂的。

![Image](https://img.alicdn.com/imgextra/i4/O1CN01MEwNTc1dqx5yBy8SS_!!6000000003788-2-tps-1080-668.png)
圖8 架構需求演進

顯然這種方式已經成為過去十幾年解決單體資料庫問題的主流方式，一旦業務量達到一個數量級，領導關心的是儘快解決問題，而不是如何優雅而低成本的完成架構升級，即使在這個過程中有一些波折也是能容忍的。但這也表明，市場需要的恰恰是簡單且低成本的架構升級方式。

透過本文對傳統分散式資料庫架構解決方案及單機分散式一體化架構方案的梳理，能夠感知到，我們在業務上如果採用單機分散式一體化架構方案，邏輯就可以簡化為業務初期採用單機版本支撐，隨著資料量的增加，可以適時轉換為分散式叢集（見圖 9）。該方案不僅可以節約資料遷移的成本，降低架構複雜度，還能在保障業務連續性的同時起到提升資料庫效能的作用。相比而言，留給使用者的只有簡單。

![Image](https://img.alicdn.com/imgextra/i4/O1CN01MEwNTc1dqx5yBy8SS_!!6000000003788-2-tps-1080-668.png)
圖9  單機分散式一體化架構方案

借用 OceanBase 對單機分散式一體化版本的定位：**“兼顧分散式架構的擴充套件性與集中式架構的效能優勢，用一套架構同時支援交易處理和分析處理的混合負載。在單機和分散式兩種部署場景下具備相同的事務 ACID 能力。”** 不得不說，這種全新的架構方式，給大家帶來了新的資料庫使用思路，這樣的架構演進也是符合市場需求與發展規律的。

4.0體驗站｜OceanBase 4.0，從分散式到單機，從單機到分散式

相關文章