OceanBase 4.0社區(qū)版真的好用嗎？

時(shí)間：2023-04-21 01:12:02 | 來源：網(wǎng)站運(yùn)營(yíng)

時(shí)間：2023-04-21 01:12:02 來源：網(wǎng)站運(yùn)營(yíng)

OceanBase 4.0社區(qū)版真的好用嗎？：

本文由行業(yè)KOL白鱔（徐戟）老師分享，歡迎大家評(píng)論區(qū)探討交流！

幾個(gè)月前OceanBase 4.0 發(fā)布的時(shí)候，一個(gè)做數(shù)據(jù)庫(kù)研發(fā)的朋友和我聊起這個(gè)，說現(xiàn)在國(guó)產(chǎn)數(shù)據(jù)庫(kù)太卷了，OceanBase4.0單機(jī)版對(duì)于我們來說有點(diǎn)降維打擊的意思啊。

我當(dāng)時(shí)說，還得等 11 月份OceanBase4.0正式發(fā)布了，看看單機(jī)版能達(dá)到普通集中式數(shù)據(jù)庫(kù)的水平的幾成，如果能達(dá)到八成以上，那么這一招確實(shí)有降維打擊的意思了。

轉(zhuǎn)眼來到 11 月份，我們可以使用 OceanBase 4.0 社區(qū)版的正式版本來測(cè)試一下了。11 月 1 號(hào)我就收到了該版本的下載鏈接。也用了幾天時(shí)間，對(duì)我一直十分感興趣的 OceanBase 4.0 單機(jī)版做一個(gè)全面的測(cè)試，并把自己測(cè)試的感受寫出來，與大家分享。

說實(shí)在的，國(guó)產(chǎn)數(shù)據(jù)庫(kù)大多數(shù)文檔寫得都不太行，但是文檔是用戶使用數(shù)據(jù)庫(kù)產(chǎn)品時(shí)十分重要的參考資料，缺乏高質(zhì)量的文檔是國(guó)產(chǎn)數(shù)據(jù)庫(kù)的一個(gè)十分重要的缺陷。因此我們體驗(yàn) OceanBase 4.0 社區(qū)版，還是從文檔開始。

雖然 OceanBase 的文檔種類豐富度相對(duì)于國(guó)外部分?jǐn)?shù)據(jù)庫(kù)還有差距，但相對(duì)來說，也算是國(guó)產(chǎn)數(shù)據(jù)庫(kù)中進(jìn)展的比較好的。在 OceanBase 的文檔中，產(chǎn)品說明、部署手冊(cè)、參考手冊(cè)、管理員手冊(cè)、開發(fā)手冊(cè)等一應(yīng)俱全，特別是在系統(tǒng)架構(gòu)和參考信息等方面也比較齊全。

OceanBase 在手冊(cè)中還提供了一個(gè)《文檔概覽》手冊(cè)，讓用戶可以全面了解 OceanBase 的文檔體系，還是挺有用的。

作為一個(gè)第一次使用 OceanBase 4.0的用戶，我們從學(xué)習(xí) OceanBase 的安裝手冊(cè)開始。在這個(gè)版本中，OceanBase 提供了一個(gè) 50 多頁的安裝部署手冊(cè)--《OceanBase 4.0—部署數(shù)據(jù)庫(kù)》。

從手冊(cè)的部署環(huán)境要求看，OceanBase 4.0 支持 RHEL 7/8 的操作系統(tǒng)，以及龍蜥、德班、烏邦圖和 SUSE 等 LINUX 發(fā)行版的系統(tǒng)。不過并沒有直接列出針對(duì)麒麟、統(tǒng)信、中科方德等信創(chuàng)環(huán)境的支持，不知道在這些信創(chuàng)環(huán)境中支持程度如何。openEuler 和 CENTER OS 7 內(nèi)核兼容性極高，估計(jì)支持起來問題不大。

OceanBase 4.0 的安裝手冊(cè)總體來說還是不錯(cuò)的，因?yàn)橐槍?duì)不同種類的部署模式，部署不同種類的集群（單機(jī)，帶 PROXY 的分布式集群，不帶 PROXY 的分布式集群等），因此其復(fù)雜度還是挺高的，目前 50 多頁的部署手冊(cè)還略顯簡(jiǎn)單。

如果針對(duì)以前玩過 OceanBase 的人來說，安裝部署并不復(fù)雜，一些概念也沒有太大變化。但是對(duì)于第一次玩 OceanBase 的人來說，OceanBase 4.0 的安裝部署文檔寫的還是略顯簡(jiǎn)單了一點(diǎn)，對(duì)于一些常見的部署模式，并沒有針對(duì)性的描述，需要從字里行間去挑出自己所需要的內(nèi)容。希望后續(xù)能夠繼續(xù)優(yōu)化文檔，最好把每種部署模式都單獨(dú)來寫。讓想用某種部署模式的人能夠在一個(gè)地方看到完整的步驟，而不是要在不同的地方挑著看。

在部署方式上，OceanBase 4.0 支持 docker 鏡像的快速體驗(yàn)，也支持使用 OBD 進(jìn)行離線部署，還支持通過 ob-operator 部署 K8S 環(huán)境。在部署方面還是考慮得比較周到的。作為一款分布式數(shù)據(jù)庫(kù)產(chǎn)品，部署簡(jiǎn)便是十分關(guān)鍵的。

OceanBase 4.0 的安裝部署手冊(cè)上建議離線方式使用OBD工具來部署。說實(shí)在的雖然以前用過 OceanBase，也在為 OceanBase 開發(fā)智能運(yùn)維工具，不過以前部署 OceanBase 都是同事做的，我自己也是第一次用 OBD 部署 OceanBase 數(shù)據(jù)庫(kù)。總體來說，只要你規(guī)劃好了部署方式，按照提前準(zhǔn)備要求準(zhǔn)備好了安裝目錄與 admin 用戶。然后找一個(gè) yaml 文件配置一下，就十分順利的完成了部署。

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我選擇了一個(gè)最簡(jiǎn)單的單機(jī)部署模式，實(shí)際上 data_dir 和 redo_dir 我都是放在 /u01/admin 下的，因?yàn)檫@臺(tái)服務(wù)器上只掛了一塊數(shù)據(jù)盤，我試了一下使用軟連接，是可以完成部署的。實(shí)際上在這里也可以直接設(shè)置為 /u01/admin/data。

在這里我遇到了一個(gè)小問題，剛開始的時(shí)候，參數(shù)文件里的一些參數(shù)我沒有設(shè)置，因此一部署就報(bào)錯(cuò)了。而在部署手冊(cè)里也沒有明確哪些參數(shù)必須設(shè)置，哪些可以忽略。

這時(shí)候執(zhí)行 deploy 會(huì)報(bào)錯(cuò)。而如果只留下 home_path 參數(shù)，其他參數(shù)全部注釋掉是能夠執(zhí)行 deploy 的，但是在 deploy 過程中會(huì)報(bào)錯(cuò)。在這里，OBD 的報(bào)錯(cuò)信息顯得不夠準(zhǔn)確。

看到上面的錯(cuò)誤信息，一般用戶還是會(huì)有點(diǎn)蒙圈的。OBD 工具的報(bào)錯(cuò)信息還可以再做些優(yōu)化。解決掉這些小問題后，部署就十分順利了。整個(gè)部署過程也很快。

安裝好后，就可以試試用 obclient 連接一下數(shù)據(jù)庫(kù)了。

在這里要注意的是，OBD 在部署集群的時(shí)候，對(duì)內(nèi)存的限制是十分嚴(yán)格的，不管系統(tǒng)中的物理內(nèi)存可用是多少，必須有足夠的 free 才能完成部署。

當(dāng)系統(tǒng)的物理內(nèi)存被 CACHE 占用而不足時(shí)，部署會(huì)失敗。而實(shí)際上，在 LINUX 上，經(jīng)常會(huì)出現(xiàn)有些 BUFFER/CACHE 無法清除的問題，這也會(huì)限制我們完成部署工作。不知道 OceanBase 4.0 在部署時(shí)嚴(yán)格檢查空閑內(nèi)存的目的是什么，按照一般情況來說，只要可用內(nèi)存達(dá)到參數(shù)要求就不會(huì)有啥問題了。

十分令人高興的是單機(jī)版的 OceanBase 與分布式環(huán)境一樣，支持租戶。這樣就可以把 OceanBase 拆分為多個(gè)小租戶，分別給一些微服務(wù)使用。因?yàn)槲业姆?wù)器上有好幾個(gè)數(shù)據(jù)庫(kù)，因此內(nèi)存比較緊張。而 OceanBase 4.0 在創(chuàng)建資源池時(shí)好像把內(nèi)存減半了（具體原因后面再慢慢研究，是不是我的配置存在一些問題）。因此配置租戶的時(shí)候，設(shè)置的內(nèi)存只有 12GB。

目前，我創(chuàng)建了一個(gè) 12G 內(nèi)存的資源池，并在上面創(chuàng)建了一個(gè) MySQL 租戶“test”。接下來就可以用 benchmark 5.0 做一次 TPCC 測(cè)試了。因?yàn)闇y(cè)試環(huán)境是一個(gè)裝了一些其他數(shù)據(jù)庫(kù)的混合環(huán)境，因此我只是做了一個(gè)十分簡(jiǎn)單的測(cè)試。測(cè)試前完全使用 autodeploy 的默認(rèn)參數(shù)，沒有做任何的 OceanBase 參數(shù)調(diào)整。配置一個(gè)OceanBase 4.0 的壓測(cè) props 文件。因?yàn)樽鈶舻?CPU MAX 設(shè)置為 60，因此我只開啟 70 客戶端進(jìn)行。

從 CPU 使用率上看，基本上把服務(wù)器的 CPU 資源都用上了。整個(gè)壓測(cè)過程中，CPU 始終有 25% 左右的空閑，這是因?yàn)槲覍?duì)資源做了限制，并沒有 100% 給 OceanBase 使用。

IO 上看，讀寫 IO 都達(dá)到了 200M+，總的 IO 吞吐量超過 500M /秒，IOPS 達(dá)到 1.7 萬左右。因?yàn)榉?wù)器使用的是 ruler ssd，IO 延時(shí)還是比較好的，低于 1 毫秒。

整個(gè)測(cè)試過程還比較平穩(wěn)，最終總的 TPMC 二十萬出頭，NewOrder 接近 10 萬。對(duì)于一般的管理和業(yè)務(wù)類系統(tǒng)而言，二十萬總 TPM 基本上能夠承擔(dān)了。測(cè)試環(huán)境是一臺(tái) 2017 年出廠的 INTEL E8 6150 系列的 2 路白牌機(jī)，配置了 64GB 內(nèi)存，而用于 TPCC 測(cè)試的租戶內(nèi)存僅僅配置了 12GB?；?LSM-TREE 的數(shù)據(jù)庫(kù)產(chǎn)品十分吃內(nèi)存，如果內(nèi)存配置大一點(diǎn)，達(dá)到 256GB 以上，硬盤也配置大一點(diǎn)，WH 數(shù)量達(dá)到 100 個(gè)，并發(fā)數(shù)提高一些，估計(jì) TPMC 再翻幾番是問題不大的。通過對(duì) OceanBase 參數(shù)的優(yōu)化，還可以繼續(xù)提升 TPMC 的指標(biāo)。不過對(duì)于一般性的應(yīng)用來說，已經(jīng)足夠了。從這也可以看出，單機(jī)版的 OceanBase 在性能上來看，還是令人滿意的。

優(yōu)化器是數(shù)據(jù)庫(kù)的靈魂，也是最難做的一個(gè)核心組件。優(yōu)化器的設(shè)計(jì)與研發(fā)需要十分優(yōu)秀的數(shù)據(jù)庫(kù)專業(yè)研發(fā)隊(duì)伍，并且需要長(zhǎng)時(shí)間的積累和打磨，在各種應(yīng)用場(chǎng)景中不斷發(fā)現(xiàn)問題，解決問題才能有所成。

在一些常見的 SQL 的執(zhí)行計(jì)劃生成上，大部分?jǐn)?shù)據(jù)庫(kù)的能力都差不多，因此要考察一個(gè)數(shù)據(jù)庫(kù)產(chǎn)品的優(yōu)化器是否能夠應(yīng)對(duì)各種復(fù)雜的應(yīng)用場(chǎng)景，必須使用一些特殊的測(cè)試用例。在這些年的應(yīng)用中，我們也積累了一些應(yīng)用場(chǎng)景。在這里我們找個(gè)和 HASH JOIN 相關(guān)的 SQL 來測(cè)試一下。

分布式數(shù)據(jù)庫(kù)在解決復(fù)雜 SQL 的問題上，往往都是采用多打一的戰(zhàn)略，單機(jī)性能往往不夠好。因?yàn)榉植际綀?zhí)行計(jì)劃優(yōu)化的難度是很大的。正是因?yàn)檫@個(gè)原因，分布式數(shù)據(jù)庫(kù)單機(jī)部署中有一個(gè)令人感到懷疑的地方，就是復(fù)雜 SQL 的性能如何。

實(shí)際上復(fù)雜 SQL 的性能不僅僅取決于并行執(zhí)行計(jì)劃的好壞，更多的是優(yōu)化器處理 HASH JOIN 等大表關(guān)聯(lián)的能力。Oracle 作為單機(jī)數(shù)據(jù)庫(kù)，在很多復(fù)雜表關(guān)聯(lián)業(yè)務(wù)上性能并不落下風(fēng)。對(duì)于一個(gè)數(shù)據(jù)庫(kù)產(chǎn)品，我經(jīng)常會(huì)用一個(gè)很多數(shù)據(jù)庫(kù)不支持的 HASH JOIN 場(chǎng)景來測(cè)試。比如下面的一條 SQL。在 PG 12 上，兩張表做關(guān)聯(lián)，關(guān)聯(lián)條件帶有 OR，那么這條SQL就無法使用 HASH JOIN 的執(zhí)行計(jì)劃，而改走NESTED LOOP。

這種執(zhí)行計(jì)劃是十分糟糕的，如果表中有數(shù)十萬條數(shù)據(jù)或者更多，那么這個(gè)執(zhí)行計(jì)劃可能跑上幾個(gè)小時(shí)也無法執(zhí)行完。在這兩年數(shù)據(jù)庫(kù)從 Oracle 遷移到 PG 兼容的數(shù)據(jù)庫(kù)或者其他國(guó)產(chǎn)數(shù)據(jù)庫(kù)的時(shí)候，經(jīng)常遇到這樣的問題。此時(shí)只能對(duì) SQL 進(jìn)行改寫，將 OR 拆分成多條 SQL 的 UNION 形式。如果條件中存在多個(gè) OR，那么麻煩就大了。我曾經(jīng)見到過一條只有數(shù)行的 SQL 被拆成上千行的案例。

我們?cè)谝惶?OpenGauss v3.0 的數(shù)據(jù)庫(kù)上，也看到了類似的執(zhí)行計(jì)劃，這個(gè)執(zhí)行計(jì)劃返回三十萬行數(shù)據(jù)，消耗了 13 秒，而如果去掉 OR 條件，執(zhí)行計(jì)劃就可以走 HASH JOIN，200 多毫秒就出結(jié)果了。

這個(gè)場(chǎng)景在 OceanBase 4.0 上試了一下，OceanBase 生成了一個(gè)自動(dòng) UNION 的執(zhí)行計(jì)劃，將 SQL 分解為 2 個(gè)走 HASH JOIN 的分支。這正好實(shí)現(xiàn)了自動(dòng)改寫 SQL 的功能。

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

這幾天簡(jiǎn)單體驗(yàn)了一把單機(jī)版的 OceanBase 4.0，總體還是讓人滿意的，支撐單一業(yè)務(wù)系統(tǒng)與普通單機(jī)數(shù)據(jù)庫(kù)相比，也不太落下風(fēng)。

隨著 OceanBase 4.0 的不斷完善，在單機(jī)版 OceanBase 的主從復(fù)制，基于 OceanBase Proxy 的高可用自動(dòng)切換等功能的日益完善，我想OceanBase 4.0 的競(jìng)爭(zhēng)力是相當(dāng)可觀的。因?yàn)槟壳拔业膶?shí)驗(yàn)環(huán)境限制，這個(gè)測(cè)試還比較簡(jiǎn)單，后續(xù)我們的 D-SMART 在為 OceanBase 4.0 做適配的時(shí)候，我們將會(huì)進(jìn)行更多的測(cè)試。

唯一覺得有點(diǎn)不爽的是，好像OceanBase 4.0 的很多監(jiān)控視圖都做了調(diào)整，并且放棄了和 OceanBase 3.X 版本的兼容，支持 OceanBase 3.1 的 D-SMART 目前還無法直接納管監(jiān)控OceanBase 4.0，因此我們無法通過 D-SMART 來觀察壓測(cè)期間 OceanBase 單機(jī)版的健康狀態(tài)。

一個(gè)數(shù)據(jù)庫(kù)產(chǎn)品升級(jí)后，核心監(jiān)控視圖最好能夠與老版本保持一定的兼容性，否則對(duì)于第三方工具來說就不夠友好了。也給現(xiàn)有用戶升級(jí)數(shù)據(jù)庫(kù)帶來一些不必要的工作量。不過從初步體驗(yàn)上來看，OceanBase 4.0 的各種系統(tǒng)視圖更加規(guī)范了，比 OceanBase 3.1 版本提升不小。這應(yīng)該也是一個(gè)數(shù)據(jù)庫(kù)產(chǎn)品在成熟過程中都會(huì)遇到的問題吧！

大家有體驗(yàn)OceanBase社區(qū)版4.0的感受，也歡迎在評(píng)論區(qū)多多互動(dòng)哦。