> **在 2022 雲棲大會上，OceanBase 社群版 4.0（代號：小魚） 正式亮相釋出，其與企業版擁有同等效能，更相容、更易用，2 分鐘內即可完成快速部署，這也意味著，業內首個相容 MySQL 的單機分散式一體化資料庫正式上線。**
>
> **這次釋出的 4.0 版本於 OceanBase 和使用者而言具有重大意義，在釋出的當晚，我們就在社群收到幾位老朋友的測評分享，也在多個社群內看到大家積極諮詢，這讓我們倍感欣慰。也正因此，經考量之後，決定在本月將選取部分新老使用者朋友“4.0測評體驗”陸續釋出在我們的微信公眾號，歡迎大家參與到OceanBase的「4.0體驗站」欄目中來。**
>
> **Ps：您的測評體驗分享還可以同步參與我們的有獎徵文哦~詳情戳《[更易用的OceanBase｜生態工具徵文大賽正式開啟！](https://www.modb.pro/db/534592)》**

**今天的第一篇「4.0體驗站」由行業知名的白鱔（徐戟）老師前來分享，歡迎大家評論區探討交流！**

------

*以下為測評正文：*

幾個月前 OceanBase 4.0 釋出的時候，一個做資料庫研發的朋友和我聊起這個，說現在國產資料庫太捲了，OceanBase 4.0 單機版對於我們來說有點降維打擊的意思啊。我當時說，還得等 11 月份 OceanBase 4.0 正式釋出了，看看單機版能達到普通集中式資料庫的水平的幾成，如果能達到八成以上，那麼這一招確實有降維打擊的意思了。

轉眼來到 11 月份，我們可以使用 OceanBase 4.0 社群版的正式版本來測試一下了。11 月 1 號我就收到了該版本的下載連結。也用了幾天時間，對我一直十分感興趣的 OceanBase 4.0 單機版做一個全面的測試，並把自己測試的感受寫出來，與大家分享。

## 文件

說實在的，國產資料庫大多數文件寫得都不太行，但是文件是使用者使用資料庫產品時十分重要的參考資料，缺乏高質量的文件是國產資料庫的一個十分重要的缺陷。因此我們體驗 OceanBase 4.0 社群版，還是從文件開始。

![](https://img.alicdn.com/imgextra/i4/O1CN01LnmGb91yxSePmZFWV_!!6000000006645-2-tps-554-452.png)

雖然 OceanBase 的文件種類豐富度相對於國外部分資料庫還有差距，但相對來說，也算是國產資料庫中進展的比較好的。在 OceanBase 的文件中，產品說明、部署手冊、參考手冊、管理員手冊、開發手冊等一應俱全，特別是在系統架構和參考資訊等方面也比較齊全。

OceanBase 在手冊中還提供了一個《文件概覽》手冊，讓使用者可以全面瞭解 OceanBase 的文件體系，還是挺有用的。

## 學習安裝手冊

作為一個第一次使用 OceanBase 4.0的使用者，我們從學習 OceanBase 的安裝手冊開始。在這個版本中，OceanBase 提供了一個 50 多頁的安裝部署手冊--《OceanBase 4.0—部署資料庫》。

![](https://img.alicdn.com/imgextra/i4/O1CN01i9wwZO278vUTfhans_!!6000000007753-2-tps-554-646.png)

從手冊的部署環境要求看，OceanBase 4.0 支援 RHEL 7/8 的作業系統，以及龍蜥、德班、烏邦圖和 SUSE 等 LINUX 發行版的系統。不過並沒有直接列出針對麒麟、統信、中科方德等信創環境的支援，不知道在這些信創環境中支援程度如何。openEuler 和 CENTER OS 7 核心相容性極高，估計支援起來問題不大。

OceanBase 4.0 的安裝手冊總體來說還是不錯的，因為要針對不同種類的部署模式，部署不同種類的叢集（單機，帶 PROXY 的分散式叢集，不帶 PROXY 的分散式叢集等），因此其複雜度還是挺高的，目前 50 多頁的部署手冊還略顯簡單。

如果針對以前玩過 OceanBase 的人來說，安裝部署並不複雜，一些概念也沒有太大變化。但是對於第一次玩 OceanBase 的人來說，OceanBase 4.0 的安裝部署文件寫的還是略顯簡單了一點，對於一些常見的部署模式，並沒有針對性的描述，需要從字裡行間去挑出自己所需要的內容。希望後續能夠繼續最佳化文件，最好把每種部署模式都單獨來寫。讓想用某種部署模式的人能夠在一個地方看到完整的步驟，而不是要在不同的地方挑著看。

![Image](https://img.alicdn.com/imgextra/i4/O1CN01ziA2V41fsu0iWvMc2_!!6000000004063-2-tps-554-237.png)

在部署方式上，OceanBase 4.0 支援 docker 映象的快速體驗，也支援使用 OBD 進行離線部署，還支援透過 ob-operator 部署 K8S 環境。在部署方面還是考慮得比較周到的。作為一款分散式資料庫產品，部署簡便是十分關鍵的。

## 安裝部署的體驗

OceanBase 4.0 的安裝部署手冊上建議離線方式使用OBD工具來部署。說實在的雖然以前用過 OceanBase，也在為 OceanBase 開發智慧運維工具，不過以前部署 OceanBase 都是同事做的，我自己也是第一次用 OBD 部署 OceanBase 資料庫。總體來說，只要你規劃好了部署方式，按照提前準備要求準備好了安裝目錄與 admin 使用者。然後找一個 yaml 檔案配置一下，就十分順利的完成了部署。

```sql
oceanbase-ce:
  servers:
    # Please don't use hostname, only IP can be supported
    - 60.60.60.123
  global:
    home_path: /u01/admin/observer
    data_dir: /u01/admin/data
    redo_dir: /u01/admin/redo
    devname: enp26s0f1
    mysql_port: 2881
    rpc_port: 2882
    zone: zone1
    memory_limit: 40G
    memory_limit_percentage: 80
    system_memory: 12G
    datafile_size: 10G
    log_disk_size: 11G
    syslog_level: INFO
    enable_syslog_wf: false
    enable_syslog_recycle: true
    max_syslog_file_count: 4
    appname: obcluster
    root_password: admin123
    proxyro_password: proxy123
```

我選擇了一個最簡單的單機部署模式，實際上 data_dir 和 redo_dir 我都是放在 /u01/admin 下的，因為這臺伺服器上只掛了一塊資料盤，我試了一下使用軟連線，是可以完成部署的。實際上在這裡也可以直接設定為 `/u01/admin/data`。

在這裡我遇到了一個小問題，剛開始的時候，引數檔案裡的一些引數我沒有設定，因此一部署就報錯了。而在部署手冊裡也沒有明確哪些引數必須設定，哪些可以忽略。

![Image](https://img.alicdn.com/imgextra/i1/O1CN01Evb4jX20dsx9R1LEt_!!6000000006873-2-tps-554-106.png)

這時候執行 deploy 會報錯。而如果只留下 home_path 引數，其他引數全部註釋掉是能夠執行 deploy 的，但是在 deploy 過程中會報錯。在這裡，OBD 的報錯資訊顯得不夠準確。

![Image](https://img.alicdn.com/imgextra/i3/O1CN01qzLMo91GKg1E141vS_!!6000000000604-2-tps-554-53.png)

看到上面的錯誤資訊，一般使用者還是會有點蒙圈的。OBD 工具的報錯資訊還可以再做些最佳化。解決掉這些小問題後，部署就十分順利了。整個部署過程也很快。

![Image](https://img.alicdn.com/imgextra/i2/O1CN01NqL6sM20LZ6xQhtWn_!!6000000006833-2-tps-554-239.png)

安裝好後，就可以試試用 obclient 連線一下資料庫了。

![Image](https://img.alicdn.com/imgextra/i3/O1CN01esSHca1k52yQLI7Jj_!!6000000004631-2-tps-554-81.png)

在這裡要注意的是，OBD 在部署叢集的時候，對記憶體的限制是十分嚴格的，不管系統中的實體記憶體可用是多少，必須有足夠的 free 才能完成部署。

![Image](https://img.alicdn.com/imgextra/i1/O1CN01Qvyf3R1bmFna9lg9K_!!6000000003507-2-tps-554-239.png)

當系統的實體記憶體被 CACHE 佔用而不足時，部署會失敗。而實際上，在 LINUX 上，經常會出現有些 BUFFER/CACHE 無法清除的問題，這也會限制我們完成部署工作。不知道 OceanBase 4.0 在部署時嚴格檢查空閒記憶體的目的是什麼，按照一般情況來說，只要可用記憶體達到引數要求就不會有啥問題了。

## 配置TPCC租戶

十分令人高興的是單機版的 OceanBase 與分散式環境一樣，支援租戶。這樣就可以把 OceanBase 拆分為多個小租戶，分別給一些微服務使用。因為我的伺服器上有好幾個資料庫，因此記憶體比較緊張。而 OceanBase 4.0 在建立資源池時好像把記憶體減半了（具體原因後面再慢慢研究，是不是我的配置存在一些問題）。因此配置租戶的時候，設定的記憶體只有 12GB。

![Image](https://img.alicdn.com/imgextra/i2/O1CN01wTB23R25utkMqf5NR_!!6000000007587-2-tps-554-106.png)

## BENCHMARK測試

目前，我建立了一個 12G 記憶體的資源池，並在上面建立了一個 MySQL 租戶“test”。接下來就可以用 benchmark 5.0 做一次 TPCC 測試了。因為測試環境是一個裝了一些其他資料庫的混合環境，因此我只是做了一個十分簡單的測試。測試前完全使用 autodeploy 的預設引數，沒有做任何的 OceanBase 引數調整。配置一個OceanBase 4.0 的壓測 props 檔案。因為租戶的 CPU MAX 設定為 60，因此我只開啟 70 客戶端進行。

![Image](https://img.alicdn.com/imgextra/i4/O1CN01WIl9Qs1jPMvyia3Tw_!!6000000004540-2-tps-554-338.png)

從 CPU 使用率上看，基本上把伺服器的 CPU 資源都用上了。整個壓測過程中，CPU 始終有 25% 左右的空閒，這是因為我對資源做了限制，並沒有 100% 給 OceanBase 使用。

![Image](https://img.alicdn.com/imgextra/i3/O1CN01HNaeBK1PDC5f14gl5_!!6000000001806-2-tps-554-118.png)

IO 上看，讀寫 IO 都達到了 200M+，總的 IO 吞吐量超過 500M /秒，IOPS 達到 1.7 萬左右。因為伺服器使用的是 ruler ssd，IO 延時還是比較好的，低於 1 毫秒。

![Image](https://img.alicdn.com/imgextra/i2/O1CN01cf51Gh1cx4ltHsNVv_!!6000000003666-2-tps-554-337.png)

整個測試過程還比較平穩，最終總的 TPMC 二十萬出頭，NewOrder 接近 10 萬。對於一般的管理和業務類系統而言，二十萬總 TPM 基本上能夠承擔了。測試環境是一臺 2017 年出廠的 INTEL E8 6150 系列的 2 路白牌機，配置了 64GB 記憶體，而用於 TPCC 測試的租戶記憶體僅僅配置了 12GB。基於 LSM-TREE 的資料庫產品十分吃記憶體，如果記憶體配置大一點，達到 256GB 以上，硬碟也配置大一點，WH 數量達到 100 個，併發數提高一些，估計 TPMC 再翻幾番是問題不大的。透過對 OceanBase 引數的最佳化，還可以繼續提升 TPMC 的指標。不過對於一般性的應用來說，已經足夠了。從這也可以看出，單機版的 OceanBase 在效能上來看，還是令人滿意的。

## 特殊情況下的HASH JOIN測試

最佳化器是資料庫的靈魂，也是最難做的一個核心元件。最佳化器的設計與研發需要十分優秀的資料庫專業研發隊伍，並且需要長時間的積累和打磨，在各種應用場景中不斷發現問題，解決問題才能有所成。

在一些常見的 SQL 的執行計劃生成上，大部分資料庫的能力都差不多，因此要考察一個資料庫產品的最佳化器是否能夠應對各種複雜的應用場景，必須使用一些特殊的測試用例。在這些年的應用中，我們也積累了一些應用場景。在這裡我們找個和 HASH JOIN 相關的 SQL 來測試一下。

分散式資料庫在解決複雜 SQL 的問題上，往往都是採用多打一的戰略，單機效能往往不夠好。因為分散式執行計劃最佳化的難度是很大的。正是因為這個原因，分散式資料庫單機部署中有一個令人感到懷疑的地方，就是複雜 SQL 的效能如何。

實際上覆雜 SQL 的效能不僅僅取決於並行執行計劃的好壞，更多的是最佳化器處理 HASH JOIN 等大表關聯的能力。Oracle 作為單機資料庫，在很多複雜表關聯業務上效能並不落下風。對於一個資料庫產品，我經常會用一個很多資料庫不支援的 HASH JOIN 場景來測試。比如下面的一條 SQL。在 PG 12 上，兩張表做關聯，關聯條件帶有 OR，那麼這條SQL就無法使用 HASH JOIN 的執行計劃，而改走NESTED LOOP。

![Image](https://img.alicdn.com/imgextra/i3/O1CN01Zkt06f24hKOUtJNiE_!!6000000007422-2-tps-554-158.png)

這種執行計劃是十分糟糕的，如果表中有數十萬條資料或者更多，那麼這個執行計劃可能跑上幾個小時也無法執行完。在這兩年資料庫從 Oracle 遷移到 PG 相容的資料庫或者其他國產資料庫的時候，經常遇到這樣的問題。此時只能對 SQL 進行改寫，將 OR 拆分成多條 SQL 的 UNION 形式。如果條件中存在多個 OR，那麼麻煩就大了。我曾經見到過一條只有數行的 SQL 被拆成上千行的案例。

![Image](https://img.alicdn.com/imgextra/i2/O1CN01VvnzpX1R5z5Q3gElu_!!6000000002061-2-tps-554-183.png)

我們在一套 OpenGauss v3.0 的資料庫上，也看到了類似的執行計劃，這個執行計劃返回三十萬行資料，消耗了 13 秒，而如果去掉 OR 條件，執行計劃就可以走 HASH JOIN，200 多毫秒就出結果了。

![Image](https://img.alicdn.com/imgextra/i1/O1CN01mqiyQu1XOCXEt1UXW_!!6000000002913-2-tps-554-199.png)

這個場景在 OceanBase 4.0 上試了一下，OceanBase 生成了一個自動 UNION 的執行計劃，將 SQL 分解為 2 個走 HASH JOIN 的分支。這正好實現了自動改寫 SQL 的功能。

![Image](https://img.alicdn.com/imgextra/i2/O1CN01SkjIqh1c0uTGjAMUI_!!6000000003539-2-tps-554-73.png)

上面的這個查詢只用了 87 毫秒，執行效率還是令人滿意的。

## 總結

這幾天簡單體驗了一把單機版的 OceanBase 4.0，總體還是讓人滿意的，支撐單一業務系統與普通單機資料庫相比，也不太落下風。

隨著 OceanBase 4.0 的不斷完善，在單機版 OceanBase 的主從複製，基於 OceanBase Proxy 的高可用自動切換等功能的日益完善，我想 OceanBase 4.0 的競爭力是相當可觀的。因為目前我的實驗環境限制，這個測試還比較簡單，後續我們的 D-SMART 在為 OceanBase 4.0 做適配的時候，我們將會進行更多的測試。

唯一覺得有點不爽的是，好像 OceanBase 4.0 的很多監控檢視都做了調整，並且放棄了和 OceanBase 3.X 版本的相容，支援 OceanBase 3.1 的 D-SMART 目前還無法直接納管監控 OceanBase 4.0，因此我們無法透過 D-SMART 來觀察壓測期間 OceanBase 單機版的健康狀態。

![Image](https://img.alicdn.com/imgextra/i1/O1CN01uAuzUx1TOQGN5DVaN_!!6000000002372-2-tps-639-137.png)

一個資料庫產品升級後，核心監控檢視最好能夠與老版本保持一定的相容性，否則對於第三方工具來說就不夠友好了。也給現有使用者升級資料庫帶來一些不必要的工作量。不過從初步體驗上來看，OceanBase 4.0 的各種系統檢視更加規範了，比 OceanBase 3.1 版本提升不小。這應該也是一個資料庫產品在成熟過程中都會遇到的問題吧！

4.0體驗站｜我對OceanBase 4.0社群版的體驗與看法

相關文章