導(dǎo)讀開源數(shù)據(jù)庫OceanBase（https://github.com/oceanbase）作為單機(jī)分

導(dǎo)讀 開源數(shù)據(jù)庫OceanBase（/oceanbase）作為單機(jī)分布式一體化架構(gòu)的數(shù)據(jù)庫，其OLTP的能力已經(jīng)廣為人知。實(shí)際上，由于原生分布式的特性，OceanBase早期版本就具備了較好的HTAP能力，并在版本有了長足進(jìn)步，在近期發(fā)布的版本中又得到強(qiáng)化。本文將圍繞OceanBase HTAP能力，從以下七部分解析其核心技術(shù)和功能特性，并披露相關(guān)性能數(shù)據(jù)。

【資料圖】

全文目錄：

1. OceanBase核心特性及技術(shù)架構(gòu)

2. 執(zhí)行引擎：OceanBase性能優(yōu)化實(shí)現(xiàn)

3. 高級(jí)查詢優(yōu)化器：影響執(zhí)行引擎效果

4. 存儲(chǔ)引擎：決定行列混合存儲(chǔ)效果

5. 資源隔離：防止TP業(yè)務(wù)與AP業(yè)務(wù)互相影響

6. 快速導(dǎo)入：Direct Path特性

7. 總結(jié)

8. Q&A

分享嘉賓｜張鑫 奧星貝斯 OceanBase開源架構(gòu)師

編輯整理｜阿東同學(xué) 中國科學(xué)院大學(xué)

內(nèi)容審核｜李瑤

出品社區(qū)｜DataFun

01

OceanBase核心特性及技術(shù)架構(gòu)

1. OceanBase的發(fā)展歷程

首先，介紹一下OceanBase的發(fā)展歷程。OceanBase始于2010年，起初是淘寶內(nèi)部的一個(gè)項(xiàng)目，旨在解決淘寶收藏夾功能的需求。直至今日，當(dāng)大家使用淘寶的收藏夾時(shí)，存儲(chǔ)后臺(tái)仍然是OceanBase。OceanBase經(jīng)歷了十多年的發(fā)展，歷經(jīng)幾個(gè)階段。其中，第一個(gè)階段是OceanBase的版本，著重磨練OceanBase的分布式能力。

在第一個(gè)階段之后， OceanBase迎來了架構(gòu)層面大的升級(jí)，也就是 版本，成為全分布式的多點(diǎn)寫入的分布式型關(guān)系型數(shù)據(jù)庫。從這一時(shí)間點(diǎn)開始， OceanBase進(jìn)入螞蟻集團(tuán)。截止到 2016 年，螞蟻集團(tuán)和網(wǎng)商銀行的全部核心系統(tǒng)，包括交易、支付賬務(wù)都已經(jīng)使用 OceanBase作為后臺(tái)的業(yè)務(wù)處理數(shù)據(jù)庫。到 2017 年， OceanBase走出螞蟻集團(tuán)，對外做一些商業(yè)化 。近兩年，在互聯(lián)網(wǎng)金融，特別是銀行、保險(xiǎn)、通信、能源等行業(yè)大范圍推廣，如攜程等公司的核心系統(tǒng)已經(jīng)采用OceanBase。

的核心特性

下面簡單介紹一下 OceanBase的核心特性。

高性能。 在 2019 年和 2020 年分別做了 TPC-C 的打榜，無論在學(xué)術(shù)界還是在工業(yè)界，TPC-C 都是 OLTP 領(lǐng)域比較權(quán)威的評測標(biāo)準(zhǔn)。2020 年，以 億 tpmC 的記錄打破世界紀(jì)錄，并在 2019 年的基礎(chǔ)上提升了 10 倍的性能。

高可用性。 當(dāng)少數(shù)機(jī)器出現(xiàn)故障的時(shí)候，OceanBase可以做到在 8 秒之內(nèi)就快速恢復(fù)整個(gè)業(yè)務(wù)系統(tǒng)，保持整個(gè)業(yè)務(wù)系統(tǒng)的連續(xù)性。

高擴(kuò)展性。 OceanBase不僅可以做水平擴(kuò)展的分布式數(shù)據(jù)庫，還可以做很好的垂直擴(kuò)展，后面會(huì)有數(shù)據(jù)跟大家分享。在彈性方面，螞蟻集團(tuán)歷年的雙十一都非常依賴于 OceanBase來做彈性的擴(kuò)縮容，在雙十一的前一周，會(huì)把集群的規(guī)模擴(kuò)到可以滿足雙十一當(dāng)天高峰大促的并發(fā)的要求，然后在雙十一過后，又可以快速地把資源釋放出來，這是極致彈性的能力。

MySQL 和 Oracle兼容。 在用戶接口方面，企業(yè)版 OceanBase同時(shí)支持 MySQL 和 Oracle 的兩種兼容模式，用戶可以在同集群里面創(chuàng)建，兩種不同的租戶可以同時(shí)工作。社區(qū)版 OceanBase目前只兼容MySQL模式，實(shí)際上底層是同一套存儲(chǔ)引擎，由于是完全自研的，因此所有功能都是一體化的設(shè)計(jì)。

HTAP： 很多用戶都知道OceanBase本身在 OLTP 這塊的能力做得不錯(cuò)，并打破了 TPC-C 記錄，印象中會(huì)覺得OceanBase是一款 OLTP 型的數(shù)據(jù)庫。但其實(shí)，OceanBase是具備 TP、AP 混合負(fù)載的HTAP關(guān)系型數(shù)據(jù)庫，OLAP能力在TPC國際事務(wù)處理性能委員會(huì)的TPC-H基準(zhǔn)測試中刷新過世界紀(jì)錄，并在 到演進(jìn)過程中不斷增強(qiáng)。

低成本。 OceanBase不同于傳統(tǒng)的 B+樹的存儲(chǔ)引擎，自研的存儲(chǔ)引擎采用 LSM-Tree，并且結(jié)合業(yè)務(wù)特點(diǎn)做了非常多的針對性優(yōu)化。最具特色的一點(diǎn)就是數(shù)據(jù)壓縮，同樣的數(shù)據(jù)在 MySQL 和Oracle數(shù)據(jù)庫上，OceanBase的數(shù)據(jù)庫磁盤占用空間大概是傳統(tǒng)的1/3 到 1/4，甚至有些場景可以做到 1/ 10。

原生多租戶的能力。 在集群里面可以創(chuàng)建多個(gè)租戶，服務(wù)多個(gè)不同的業(yè)務(wù)，這一層是在數(shù)據(jù)庫的集群內(nèi)部做的，不需要依賴于外部的虛擬化的一些機(jī)制，租戶之間的資源完全隔離，并且后續(xù)可以隨意擴(kuò)展。

安全性。 支持透明加密、傳輸加密、安全審計(jì)等。

其它。 OceanBase在 2017 年開始商業(yè)化之后，大力發(fā)展周邊生態(tài)工具。從企業(yè)的視角來看， OceanBase具備完整的從數(shù)據(jù)庫開發(fā)到遷移，再到評估、運(yùn)維及診斷的全生命周期的配套工具。

的整體架構(gòu)

下圖是OceanBase數(shù)據(jù)庫的整體架構(gòu)，它由若干個(gè)ZONE組成。每個(gè)ZONE有多個(gè)OB服務(wù)器，這些節(jié)點(diǎn)共同組成了一個(gè)完整的數(shù)據(jù)庫集群系統(tǒng)。

在OceanBase數(shù)據(jù)庫中，數(shù)據(jù)的表進(jìn)行了分片，如圖所示，P1、P2、P3等。每一個(gè)分片稱為一個(gè)分區(qū)。同一份數(shù)據(jù)在不同的ZONE里會(huì)有多個(gè)副本。例如P1，它在第2個(gè)ZONE和第3個(gè)ZONE都有相同的數(shù)據(jù)備份。相同分片的數(shù)據(jù)同步是通過Paxos一致性協(xié)議進(jìn)行的。

OceanBase在2020 年參加 TPC-C 評測時(shí)，整個(gè)集群由 1500 多個(gè)節(jié)點(diǎn)組成，是一個(gè)非常大的集群規(guī)模，如果業(yè)務(wù)不需要大集群， OceanBase也可以做到單機(jī)部署。

上圖展示的是實(shí)際的生產(chǎn)數(shù)據(jù)，來自螞蟻內(nèi)部真實(shí)的業(yè)務(wù)系統(tǒng)。峰值的數(shù)據(jù)處理能力達(dá)到了 6100 萬次每秒，單個(gè)集群規(guī)模超過 1000 臺(tái)，單庫有 6PB 的數(shù)據(jù)，最大一張表超過了 3200 億行。RPO=0指的是在機(jī)器發(fā)生故障之后，保證數(shù)據(jù)不丟失。RTO < 8 秒，就是在少數(shù)機(jī)器出現(xiàn)故障之后，能夠在 8 秒之內(nèi)快速恢復(fù)業(yè)務(wù)。

這張圖是OceanBase分別在2019年和2020參加TPC-C測評的結(jié)果。這里壓測的億tpmC數(shù)據(jù)，即每秒可以處理2000多萬次事務(wù)。需要說明的是，這里的事務(wù)并非僅指數(shù)據(jù)庫請求。

在TPC-C的模型中，有許多由復(fù)雜SQL語句組成的部分，因此綜合吞吐量非常高。在這里，高并發(fā)處理能力體現(xiàn)在曲線上。在TPC-C評測中，要求程序以最高峰值平穩(wěn)地運(yùn)行兩個(gè)小時(shí)，并進(jìn)行兩個(gè)小時(shí)的采樣。在這兩個(gè)小時(shí)的采樣期間，整體性能的波動(dòng)不得超過3％。OceanBase為自己提供了最高的標(biāo)準(zhǔn)，并進(jìn)行了實(shí)際測評。從圖表中可以看出，實(shí)際運(yùn)行時(shí)間為8個(gè)小時(shí)，整體波動(dòng)小于1％。在數(shù)據(jù)庫或LSM-Tree架構(gòu)中，抖動(dòng)是個(gè)相當(dāng)重要的問題。實(shí)際上，LSM-Tree存儲(chǔ)引擎每次需要進(jìn)行轉(zhuǎn)儲(chǔ)和合并，這通常會(huì)引起一定程度的抖動(dòng)。然而，經(jīng)過多年的內(nèi)部打磨和外部用戶實(shí)踐的應(yīng)用，OceanBase進(jìn)行了大量的優(yōu)化和改進(jìn)，使得其整體平穩(wěn)性能達(dá)到了極高水平。

此外， OceanBase是當(dāng)時(shí)唯一通過TPC-C官方審核的分布式數(shù)據(jù)庫，也是中國唯一通過官方審核的數(shù)據(jù)庫。

在2020 年又參加了 OLAP 方面的打榜，即 TPC-H 的評測，以30000 GB 的數(shù)據(jù)拿了當(dāng)時(shí)世界第一的結(jié)果。

大家可以看右邊這張圖，是OceanBase自己和自己的比較，從的版本和的版本相對于在聯(lián)機(jī)分析處理(OLAP)這塊的性能的對比，可以看到它的提升非常顯著，整體以TPC-H為代表的OLAP能力也有了極大的提升。

現(xiàn)在對于許多復(fù)雜查詢，人們普遍認(rèn)為TPC-H相對簡單，尤其是對于跨數(shù)據(jù)庫的優(yōu)化器來說，TPC-H對優(yōu)化器的能力考驗(yàn)也許被視為次要的。因此，OceanBase在去年推出了版本，今年又推出了版本，下半年還將推出版本，進(jìn)一步提高復(fù)雜查詢和優(yōu)化執(zhí)行能力。

版本相比于之前的版本，在大小為100G的倉庫上進(jìn)行對比，整體性能提升了300秒，有了三倍的提升?，F(xiàn)在版與版又有了更多的提升。

OceanBase整體性能提升的技術(shù)實(shí)現(xiàn)方式是什么？以下將簡要介紹OceanBase執(zhí)行引擎的能力。

首先，OceanBase的執(zhí)行引擎在最初的設(shè)計(jì)中就考慮到了處理TP和AP的需求。因?yàn)閺臉I(yè)務(wù)場景來看，很難區(qū)分查詢是TP還是AP，也很難區(qū)分它是小規(guī)模查詢還是大規(guī)模查詢。因此，初始設(shè)計(jì)就要兼顧這兩種情況。

大家對于MySQL可能比較熟悉，MySQL對于簡單高頻的查詢處理非常出色，但在處理大規(guī)模數(shù)據(jù)方面仍有不足。然而，OceanBase從最開始就定位為分布式數(shù)據(jù)庫，用戶期望其具備大規(guī)模數(shù)據(jù)處理的能力。在執(zhí)行引擎方面，OceanBase做了一些優(yōu)化，既可以支持串行執(zhí)行，也可以支持并行執(zhí)行。串行執(zhí)行主要面向TP業(yè)務(wù)場景，而并行執(zhí)行則可以在多個(gè)節(jié)點(diǎn)之間進(jìn)行并行查詢，并且查詢能力可以垂直和水平擴(kuò)展。在TP領(lǐng)域中，時(shí)延是一個(gè)重要的指標(biāo)，而不僅僅是吞吐量。因此，串行執(zhí)行更多地針對TP進(jìn)行優(yōu)化。在串行執(zhí)行時(shí)，數(shù)據(jù)有時(shí)需要跨機(jī)訪問。因此OceanBase的執(zhí)行引擎也有兩種策略，一種是通過拉取跨機(jī)數(shù)據(jù)并使用數(shù)據(jù)拉取策略進(jìn)行計(jì)算，另一種是將計(jì)算下推到下面的節(jié)點(diǎn)中，然后再將計(jì)算結(jié)果取回。這兩種策略都是執(zhí)行引擎支持的，具體如何執(zhí)行取決于優(yōu)化器的決策。

1. 并行執(zhí)行調(diào)度

并行執(zhí)行引擎將SQL查詢計(jì)劃拆分成多個(gè)分片，每個(gè)分片可能涉及多個(gè)數(shù)據(jù)。也可以拆分成若干子片，每個(gè)子片稱為DFO，DFO組成整個(gè)查詢的數(shù)據(jù)流。在并行調(diào)度時(shí)，可以將整個(gè)數(shù)據(jù)流劃分為多個(gè)片段，相鄰片段可以并行調(diào)度，逐步上傳數(shù)據(jù)。當(dāng)然，并行度可以根據(jù)用戶自定義進(jìn)行指定。

OceanBase是一個(gè)具有豐富并行查詢策略的分布式數(shù)據(jù)庫。舉個(gè)例子，在AP場景中，數(shù)據(jù)會(huì)根據(jù)主鍵或分區(qū)鍵拆分成若干個(gè)分片，也稱為分區(qū)。例如，R1和R2兩張表，其中有a和b兩個(gè)列。以b列作為分區(qū)鍵，表中數(shù)據(jù)會(huì)根據(jù)b列的哈希值不同分散在多臺(tái)機(jī)器上。與單機(jī)數(shù)據(jù)庫不同的是，OceanBase可以靈活地處理并行處理數(shù)據(jù)。

表的連接有4種最基本的方式。由于列b是分區(qū)列而a是普通列，因此如果對R1表的b列和R2表的b列做連接查詢，可以將每個(gè)分片對應(yīng)起來。因?yàn)榉謪^(qū)策略是相同的，就可以分別對每個(gè)分區(qū)進(jìn)行連接。這種方式被稱為分區(qū)連接（partition with join）。在這種情況下，同一張表的分區(qū)之間不需要進(jìn)行數(shù)據(jù)交叉。

如果是分區(qū)列 b 列和另外一張表的普通列a列做 join ，可以把不分區(qū)的 R2 這一列求哈希值以后根據(jù)它對應(yīng)的在 a 表上的分區(qū)方式，把它 shuffle 到 R1 表的分區(qū)上面，這種方式叫部分 partition with join。

第三種情況是當(dāng)完全使用a列進(jìn)行連接時(shí)，由于沒有分區(qū)，因此所有數(shù)據(jù)都存在于不同的分片中。此時(shí)，可以直接對所有a列進(jìn)行哈希，然后在不同的機(jī)器上進(jìn)行連接。

最后一種情況是當(dāng)R2表是一張小表時(shí)，可以將該表廣播到R1表的每個(gè)分區(qū)中，無論條件如何。這四種策略實(shí)際上都需要在優(yōu)化時(shí)進(jìn)行自動(dòng)選擇。

2. 自適應(yīng)執(zhí)行

自適應(yīng)執(zhí)行以 group by分組算法為例，比如要把上面的查詢按照 b 列做分組，然后按照 c 列做求和，每個(gè)分組做求和的簡單的查詢。在分布式場景里面，可以在每個(gè)分區(qū)上先做求和的動(dòng)作，然后再把所有的分區(qū)的計(jì)算結(jié)果聚合起來。

每個(gè)分區(qū)上做分組是否值得，主要取決于每個(gè)分區(qū)有多少個(gè)不同的 b 值。做聚合的時(shí)候，先要為表建哈希表，建哈希表其實(shí)是有代價(jià)的。比如 100 行數(shù)據(jù)，建了哈希表之后它還是有 100 個(gè)不同的值，那么建哈希表其實(shí)是浪費(fèi)的，對數(shù)據(jù)的消減作用非常小。這在優(yōu)化器來看是沒辦法決定的，因?yàn)榫酆弦院笥卸嗌俨煌闹担瑑?yōu)化器預(yù)先是不知道，所以就需要做自適應(yīng)的執(zhí)行。優(yōu)化器遇到這種場景會(huì)判斷第一個(gè)分片上的消減作用是大還是小。如果消減作用是非常小的，那么在后面的分區(qū)上做的時(shí)候，就不需要再創(chuàng)建哈希表，而是直接把數(shù)據(jù)推到上一層，去做計(jì)算。這就是自適應(yīng)引擎的策略。

在 OLAP 領(lǐng)域中，優(yōu)化器的能力非常重要，執(zhí)行引擎的能力有很多，用的好不好依賴于優(yōu)化器是否能產(chǎn)生一個(gè)好的執(zhí)行計(jì)劃。經(jīng)過多年的深入研究和實(shí)踐，OceanBase 的優(yōu)化器已經(jīng)達(dá)到了非常高的水平，并在螞蟻集團(tuán)內(nèi)部以及一些大型銀行和保險(xiǎn)公司的核心業(yè)務(wù)場景中得到了驗(yàn)證。對優(yōu)化器的核心算法進(jìn)行了精心優(yōu)化，增加了許多專門針對特定場景的規(guī)則和策略。在 OceanBase 中采用了兩階段的方式生成執(zhí)行計(jì)劃，首先生成串行執(zhí)行計(jì)劃，然后在需要時(shí)對最優(yōu)的執(zhí)行計(jì)劃進(jìn)行并行化。

1. 一階段分布式查詢優(yōu)化

這種兩階段執(zhí)行計(jì)劃生成方式存在一些問題。例如在下圖中，從串行計(jì)算的角度來看，根據(jù)算法復(fù)雜度，AB執(zhí)行計(jì)劃的時(shí)間只需要100毫秒，因此執(zhí)行計(jì)劃被認(rèn)為是更優(yōu)的。然而，這并不意味著生成兩個(gè)階段的執(zhí)行計(jì)劃再并行化會(huì)得到最優(yōu)的執(zhí)行方案。

實(shí)際上還是需要考慮數(shù)據(jù)分布的情況，在例子中的R1、R2、 R3 這三張表，數(shù)據(jù)到底位于哪些機(jī)器上？即使在第一個(gè)階段分析，看到耗時(shí)是更高的 150 毫秒的執(zhí)行計(jì)劃，但是因?yàn)樗鼘τ诤筮叺呐判?，或者說數(shù)據(jù)的分布是有用的，因此需要把這個(gè)執(zhí)行計(jì)劃也保留下來，等執(zhí)行編譯之后再看最終的執(zhí)行計(jì)劃哪個(gè)更好。

所以這部分的優(yōu)化，就是把之前的兩階段的執(zhí)行計(jì)劃變成一階段，可以帶來很大的好處，整體上在秒級(jí)別可以完成 50 張表的連接。

2. 并行下壓

前文講到的 group by 的例子是有下壓的策略， OceanBase 的版本對于有一類的執(zhí)行計(jì)劃是不能夠做并行下壓的，在 之后可以完全支持，因?yàn)橐肓巳A段下壓的策略。

舉個(gè)例子，就是一種帶有distinct的聚合函數(shù)使用group by的情況。核心部分需要把數(shù)據(jù)查出來后，對不同的c值進(jìn)行sum求和，并進(jìn)行消重。但是因?yàn)樾枰獙列進(jìn)行消重后再求和，所以無論有多少個(gè)分區(qū)，分區(qū)間并行都無法充分利用。因此，在版本中OceanBase采用引入了三階段的下壓策略實(shí)現(xiàn)并行。首先在每個(gè)分區(qū)上進(jìn)行消重，然后再進(jìn)行哈希，把每個(gè)分片上先在c列上消重，再將每片的1、2和3值聚合起來進(jìn)行消重，這就是3號(hào)算子。接著在第二層上進(jìn)行最后的求和操作，最后再進(jìn)行整體的求和。這種策略對于一些復(fù)雜查詢有著非常明顯的提升。

前面講的都是 SQL 引擎，下面來介紹一下 OceanBase的存儲(chǔ)引擎，存儲(chǔ)引擎對于這種 HTAP 場景影響非常大。這是 OceanBase整個(gè)存儲(chǔ)引擎的結(jié)構(gòu)，可以看到是比較簡單的LSM-Tree 的結(jié)構(gòu)。

1. 行列混合存儲(chǔ)及編碼壓縮

數(shù)據(jù)存儲(chǔ)可以被看作是有序的鍵值對，所有更新操作都以增量方式記錄到內(nèi)存中。在讀取時(shí)，將磁盤上的數(shù)據(jù)、內(nèi)存的數(shù)據(jù)和內(nèi)存中更新的數(shù)據(jù)合并，提供讀取服務(wù)。此外，還有塊緩存和行緩存等各種緩存。定期整理增量數(shù)據(jù)和基線SSTable數(shù)據(jù)，進(jìn)行合并，這是LSM-Tree的基本邏輯。

相對于使用"B+樹"的存儲(chǔ)引擎，LSM-Tree的最大優(yōu)點(diǎn)就是它的整個(gè)更新過程沒有隨機(jī)寫入。所有的插入和更新都先直接寫入內(nèi)存，相當(dāng)于聚合大量的數(shù)據(jù)并按順序?qū)懭氪疟P。

為什么之前沒有提出這個(gè)策略？這實(shí)際上與硬件的發(fā)展有很大關(guān)系?，F(xiàn)在LSM-Tree這種存儲(chǔ)引擎不僅適用于OLTP，對于OLAP方面也有很大的優(yōu)勢。其優(yōu)點(diǎn)在于，它的基線數(shù)據(jù)只有在下一次合并時(shí)才會(huì)修改，因此，這部分?jǐn)?shù)據(jù)在磁盤上可以高度壓縮。

除了通用壓縮，由于行列混合的模式，OceanBase的行列混合模式可以通過按列的方式進(jìn)行壓縮。數(shù)據(jù)表按數(shù)據(jù)分成多個(gè)Row Group，并按列的方式存儲(chǔ)在磁盤上。因此，在磁盤上，每個(gè)數(shù)據(jù)塊都是以列為緊湊的存儲(chǔ)方式存儲(chǔ)，這對于壓縮非常有利。剛才為什么說“同一塊數(shù)據(jù)從MySQL遷移到OceanBase可能有三倍的壓縮率”？主要是由于LSM-Tree，在編碼后，又進(jìn)行了通用壓縮，因此具有非常高的壓縮比率。并且，它能夠在線進(jìn)行這種壓縮算法，而B+樹無法實(shí)現(xiàn)。OceanBase的好處主要在于LSM-Tree的后臺(tái)整理數(shù)據(jù)的特性，因?yàn)镾STable的基線數(shù)據(jù)在下一次合并和整理時(shí)是后臺(tái)處理的，而不是在用戶執(zhí)行插入操作時(shí)直接進(jìn)行壓縮。

可以想象一下，如果是 B+樹，實(shí)時(shí)地做在線的壓縮動(dòng)作，其實(shí)對于壓縮算法的要求是非常高的。如果把它變成后臺(tái)動(dòng)作，可以非常高效地做壓縮，并且可以選擇更好的壓縮算法。

2. 查詢過濾下壓

又因?yàn)榇疟P上是列式的存儲(chǔ)，所以對于 OLAP 來說，這種大規(guī)模的數(shù)據(jù)掃描以及數(shù)據(jù)分析，可以把整個(gè)查詢的filter過濾算子做下壓，并且在不解壓的情況下就做過濾。

比如，一個(gè)數(shù)據(jù)表有性別一列，通常只有男女兩種類別。實(shí)際上，經(jīng)過壓縮后，男性和女性屬性值只占用一個(gè)比特，從而可以實(shí)現(xiàn)高度壓縮。在數(shù)據(jù)處理時(shí)，可以在數(shù)據(jù)字典上進(jìn)行過濾，然后通過已壓縮值進(jìn)行高效處理，實(shí)現(xiàn)高效性。

此外，OLAP引擎經(jīng)常采用的策略在OceanBase的存儲(chǔ)引擎中得到了充分的體現(xiàn)。這也是因?yàn)镺ceanBase的存儲(chǔ)引擎既滿足了TP高并發(fā)低延遲的要求，又能夠在大規(guī)模數(shù)據(jù)處理時(shí)充分利用列存的優(yōu)勢。因此， OceanBase是TP和AP存儲(chǔ)引擎的完美結(jié)合。

前面都是講存儲(chǔ)引擎和執(zhí)行引擎的邏輯，但在實(shí)際業(yè)務(wù)中，很多時(shí)候很難區(qū)分它是 TP 還是AP，在混合的場景下，大家會(huì)傾向于保護(hù)TP 的這些查詢的資源，防止一些大的 AP 的查詢爭用資源，影響TP 的時(shí)延。因此引出了資源隔離的概念。

OceanBase本身是原生的多租戶的數(shù)據(jù)庫，前面介紹的架構(gòu)其實(shí)比較簡單，在其架構(gòu)上層還有租戶的概念。在OceanBase的集群中，可以有若干個(gè)租戶，相當(dāng)于虛擬的容器，每個(gè)容器可以看作是數(shù)據(jù)庫的實(shí)例。這些容器主要限制CPU、內(nèi)存和IOPS的使用。有了這項(xiàng)技術(shù)，就可以實(shí)現(xiàn)多租戶，就做到了剛才所說的CPU和內(nèi)存的隔離。同樣的技術(shù)也可以用于HTAP，即TP和AP負(fù)混合負(fù)載的場景。因此，另外一項(xiàng)技術(shù)——資源組得以發(fā)展。

資源組的工作方式是什么？如果業(yè)務(wù)中既有在線交易作業(yè)，又有批處理作業(yè)，就需要以某種方式告訴數(shù)據(jù)庫哪些是批處理作業(yè)，哪些是在線交易作業(yè)。簡而言之，可以通過區(qū)分用戶，并告知數(shù)據(jù)庫哪些是批處理作業(yè)，哪些是TP類的業(yè)務(wù)。然后，根據(jù)這些用戶綁定的資源組，可以控制總使用的CPU或內(nèi)存不超過某個(gè)限制。

如果資源組隔離不足，也可以采取一些物理隔離的方法。由于數(shù)據(jù)采用多副本的方式存儲(chǔ)，可以采用讀寫分離的方法，TP的請求訪問主副本，分析查詢則訪問從副本。此外，還可以增加只讀副本，專門用于AP分析。這些都是資源隔離的方法。

最后介紹一個(gè)小特性，即快速導(dǎo)入，主要針對一些 AP 的場景， AP型的系統(tǒng)經(jīng)常需要和外部做一些數(shù)據(jù)的交互，所以在 的時(shí)候，專門做了快速導(dǎo)入 Direct Path特性。

數(shù)據(jù)庫的導(dǎo)入有幾種方式，第一種是“l(fā)oad data”，幾乎所有數(shù)據(jù)庫都支持它。另外就是通過 SQL 語句，直接從一張表中查詢數(shù)據(jù)，然后將其寫入到另一個(gè)表中。還有一種方式是通過 tableAPI 接口，可以使用外部客戶端等工具將 CSV 等文件導(dǎo)入，在導(dǎo)入后，數(shù)據(jù)首先會(huì)記錄到某個(gè)節(jié)點(diǎn)上，并在節(jié)點(diǎn)上進(jìn)行分析。根據(jù)分區(qū)規(guī)則，將相應(yīng)數(shù)據(jù)分發(fā)到相應(yīng)的機(jī)器上。

在主節(jié)點(diǎn)內(nèi)，如果在導(dǎo)入過程中表本身還有在線更新，可能會(huì)產(chǎn)生沖突。但在此類快速導(dǎo)入場景下，大多數(shù)被導(dǎo)入的表在寫入時(shí)不會(huì)非常頻繁。因此，基于這一特點(diǎn)，實(shí)際上會(huì)先鎖定表的修改，并生成影子表。整個(gè)大規(guī)模導(dǎo)入期間表被鎖定，讀取仍然可以繼續(xù)進(jìn)行，但寫操作被鎖定。然后，在數(shù)據(jù)導(dǎo)入時(shí)繞過 SQL 層和 LSM-Tree 的內(nèi)存層，直接生成最終的存儲(chǔ)層，即列存儲(chǔ)。前面也提到過它被稱為 SSTable。同時(shí)，生成的數(shù)據(jù)還要與原始增量數(shù)據(jù)合并一次，以生成最終影子表，然后再進(jìn)行切換。

旁路導(dǎo)入技術(shù)也在內(nèi)部進(jìn)行了實(shí)際評測。參見下圖，第一個(gè)維度就是這張表是不是有主鍵，是不是按順序排列；第二個(gè)維度就是機(jī)器的大小。從兩個(gè)維度整體來看，首先因?yàn)橛兄麈I，會(huì)多一次排序，所以時(shí)間會(huì)長一些。整體來看利用了旁路導(dǎo)入的特性，導(dǎo)入的性能是有 4 到 5 倍的提升。

OceanBase作為原生分布式數(shù)據(jù)庫，無論做 TP 還是AP，都有一些基礎(chǔ)的高可用能力以及高性能的能力。OceanBase做了非常多的OLAP相關(guān)工作，包括大查詢、復(fù)雜的分析查詢，幾十張表的join，以及支持各種窗口函數(shù)層次查詢，還支持表函數(shù)，甚至可以支持自定義窗口函數(shù)等。從數(shù)據(jù)集成的角度來說，OceanBase支持DB link，可以把其它數(shù)據(jù)庫的一張表的數(shù)據(jù)通過這種方式做查詢。數(shù)據(jù)導(dǎo)入導(dǎo)出方面，在文中介紹了快速導(dǎo)入以及一些導(dǎo)出工具。

最后當(dāng)前正在做外表的功能，將在下一版本中發(fā)布，歡迎關(guān)注，歡迎參與共建/oceanbase

以上就是本次分享的全部內(nèi)容。大家如果感興趣可以掃碼加入以下社區(qū)答疑群。

08

問答環(huán)節(jié)

Q1:相同計(jì)算資源情況下， OceanBase和 Snowflake Doris Clickhouse 的查詢性能對比如何？有沒有發(fā)表過類似的測試的技術(shù)白皮書之類的資料，可以給到用戶社區(qū)用戶網(wǎng)上可以查看？

A：這塊其實(shí)之前也有一些做過一些測試對比，但是如果從我們角度來說，肯定會(huì)說比其他產(chǎn)品測試下來的效果好，其實(shí)相比這些列存數(shù)據(jù)庫整體性能是差不多的，但是具體的性能，還是用戶自己測出來的效果會(huì)更有說服力。有一些用戶有做過測試，相比 clickhouse 這些在 AP 能力其實(shí)是差別不大了。

測試白皮書這塊目前還暫時(shí)還沒有，用戶可以根據(jù)自己的實(shí)際場景，做一些性能的對比測試。

Q2: OceanBase的安全性和高可用性穩(wěn)定性如何？

A：這塊其實(shí)大家可以放心一些，因?yàn)槭紫仍趧偛乓灿薪榻B到，在螞蟻集團(tuán)內(nèi)部核心交易、賬戶系統(tǒng)等，這些支付寶的這些后臺(tái)的數(shù)據(jù)庫，都是 OceanBase，從很早開始就不斷地用 OceanBase替換掉Oracle， MySQL，它的安全性、穩(wěn)定性已經(jīng)是經(jīng)過很多年的驗(yàn)證。

高可用性目前因?yàn)楸旧硭沁@種分布式的數(shù)據(jù)庫，原生的就是具備高可用能力，因?yàn)閿?shù)據(jù)是通過 Paxos 一致性協(xié)議做復(fù)制，所有的數(shù)據(jù)提交都要保證多數(shù)派。如果少數(shù)節(jié)點(diǎn)出現(xiàn)故障的情況下，整個(gè)集群基本不會(huì)受到什么影響。

今天的分享就到這里，謝謝大家。