OceanBase 產(chǎn)品架構(gòu)

OceanBase 數(shù)據(jù)庫采用 Shared-Nothing 架構(gòu)，各個(gè)節(jié)點(diǎn)之間完全對等，每個(gè)節(jié)點(diǎn)都有自己的 SQL 引擎、存儲引擎，運(yùn)行在普通 PC 服務(wù)器組成的集群之上，具備可擴(kuò)展、高可用、高性能、低成本、云原生等核心特性。

OceanBase 數(shù)據(jù)庫的整體架構(gòu)如下圖所示。

集群架構(gòu)

OceanBase 數(shù)據(jù)庫支持?jǐn)?shù)據(jù)跨地域（Region）部署，每個(gè)地域可能位于不同的城市，距離通常比較遠(yuǎn)，所以 OceanBase 數(shù)據(jù)庫可以支持多城市部署，也支持多城市級別的容災(zāi)。一個(gè) Region 可以包含一個(gè)或者多個(gè) Zone，Zone 是一個(gè)邏輯的概念，它包含了 1 臺或者多臺運(yùn)行了 OBServer 進(jìn)程的服務(wù)器（以下簡稱 OBServer）。每一個(gè) Zone 上包含一個(gè)完整的數(shù)據(jù)副本，由于 OceanBase 數(shù)據(jù)庫的數(shù)據(jù)副本是以分區(qū)為單位的，所以同一個(gè)分區(qū)的數(shù)據(jù)會分布在多個(gè) Zone 上。每個(gè)分區(qū)的主副本所在服務(wù)器被稱為 Leader，所在的 Zone 被稱為 Primary Zone。如果不設(shè)定 Primary Zone，系統(tǒng)會根據(jù)負(fù)載均衡的策略，在多個(gè)全功能副本里自動選擇一個(gè)作為 Leader。

每個(gè) Zone 會提供兩種服務(wù)：總控服務(wù)（RootService）和分區(qū)服務(wù)（PartitionService）。其中每個(gè) Zone 上都會存在一個(gè)總控服務(wù)，運(yùn)行在某一個(gè) OBServer 上，整個(gè)集群中只存在一個(gè)主總控服務(wù)，其他的總控服務(wù)作為主總控服務(wù)的備用服務(wù)運(yùn)行?？偪胤?wù)負(fù)責(zé)整個(gè)集群的資源調(diào)度、資源分配、數(shù)據(jù)分布信息管理以及 Schema 管理等功能。 其中：

• 資源調(diào)度主要包含了向集群中添加、刪除 OBServer，在 OBServer 中創(chuàng)建資源規(guī)格、Tenant 等供用戶使用的資源；
• 資源均衡主要是指各種資源（例如：Unit）在各個(gè) Zone 或者 OBServer 之間的遷移。
• 數(shù)據(jù)分布管理是指總控服務(wù)會決定數(shù)據(jù)分布的位置信息，例如：某一個(gè)分區(qū)的數(shù)據(jù)分布到哪些 OBServer 上。
• Schema 管理是指總控服務(wù)會負(fù)責(zé)調(diào)度和管理各種 DDL 語句。

分區(qū)服務(wù)用于負(fù)責(zé)每個(gè) OBServer 上各個(gè)分區(qū)的管理和操作功能的模塊，這個(gè)模塊與事務(wù)引擎、存儲引擎存在很多調(diào)用關(guān)系。

OceanBase 數(shù)據(jù)庫基于 Paxos 的分布式選舉算法來實(shí)現(xiàn)系統(tǒng)的高可用，最小的粒度可以做到分區(qū)級別。集群中數(shù)據(jù)的一個(gè)分區(qū)（或者稱為副本）會被保存到所有的 Zone 上，整個(gè)系統(tǒng)中該副本的多個(gè)分區(qū)之間通過 Paxos 協(xié)議進(jìn)行日志同步。每個(gè)分區(qū)和它的副本構(gòu)成一個(gè)獨(dú)立的 Paxos 復(fù)制組，其中一個(gè)分區(qū)為主分區(qū)（Leader），其它分區(qū)為備分區(qū)（Follower）。所有針對這個(gè)副本的寫請求，都會自動路由到對應(yīng)的主分區(qū)上進(jìn)行。主分區(qū)可以分布在不同的 OBServer 上，這樣對于不同副本的寫操作也會分布到不同的數(shù)據(jù)節(jié)點(diǎn)上，從而實(shí)現(xiàn)數(shù)據(jù)多點(diǎn)寫入，提高系統(tǒng)性能。

存儲引擎

OceanBase 數(shù)據(jù)庫的存儲引擎采用了基于 LSM-Tree 的架構(gòu)，把基線數(shù)據(jù)和增量數(shù)據(jù)分別保存在磁盤（SSTable）和內(nèi)存（MemTable）中，具備讀寫分離的特點(diǎn)。對數(shù)據(jù)的修改都是增量數(shù)據(jù)，只寫內(nèi)存。所以 DML 是完全的內(nèi)存操作，性能非常高。讀的時(shí)候，數(shù)據(jù)可能會在內(nèi)存里有更新過的版本，在持久化存儲里有基線版本，需要把兩個(gè)版本進(jìn)行合并，獲得一個(gè)最新版本。

如上圖所示，在內(nèi)存中針對不同的數(shù)據(jù)訪問行為，OceanBase 數(shù)據(jù)庫設(shè)計(jì)了多種緩存結(jié)構(gòu)。除了常見的數(shù)據(jù)塊緩存之外，也會對行進(jìn)行緩存，行緩存會極大加速對單行的查詢性能。為了避免對不存在行的空查，OceanBase 數(shù)據(jù)庫對行緩存構(gòu)建了布隆過濾器，并對布隆過濾器進(jìn)行緩存。OLTP 業(yè)務(wù)大部分操作為小查詢，通過小查詢優(yōu)化，OceanBase 數(shù)據(jù)庫避免了傳統(tǒng)數(shù)據(jù)庫解析整個(gè)數(shù)據(jù)塊的開銷，達(dá)到了接近內(nèi)存數(shù)據(jù)庫的性能。當(dāng)內(nèi)存的增量數(shù)據(jù)達(dá)到一定規(guī)模的時(shí)候，會觸發(fā)增量數(shù)據(jù)和基線數(shù)據(jù)的合并，把增量數(shù)據(jù)落盤。同時(shí)每天晚上的空閑時(shí)刻，系統(tǒng)也會啟動每日合并。另外，由于基線是只讀數(shù)據(jù)，而且內(nèi)部采用連續(xù)存儲的方式，OceanBase 數(shù)據(jù)庫可以根據(jù)不同特點(diǎn)的數(shù)據(jù)采用不同的壓縮算法，既能做到高壓縮比，又不影響查詢性能，大大降低了成本。

SQL 引擎

OceanBase 數(shù)據(jù)庫的 SQL 引擎是整個(gè)數(shù)據(jù)庫的數(shù)據(jù)計(jì)算中樞，和傳統(tǒng)數(shù)據(jù)庫類似，整個(gè)引擎分為解析器、優(yōu)化器、執(zhí)行器三部分。當(dāng) SQL 引擎接受到了 SQL 請求后，經(jīng)過語法解析、語義分析、查詢重寫、查詢優(yōu)化等一系列過程后，再由執(zhí)行器來負(fù)責(zé)執(zhí)行。所不同的是，在分布式數(shù)據(jù)庫里，查詢優(yōu)化器會依據(jù)數(shù)據(jù)的分布信息生成分布式的執(zhí)行計(jì)劃。如果查詢涉及的數(shù)據(jù)在多臺服務(wù)器，需要走分布式計(jì)劃，這是分布式數(shù)據(jù)庫 SQL 引擎的一個(gè)重要特點(diǎn)，也是十分考驗(yàn)查詢優(yōu)化器能力的場景。OceanBase 數(shù)據(jù)庫查詢優(yōu)化器做了很多優(yōu)化，諸如算子下推、智能連接、分區(qū)裁剪等。如果 SQL 語句涉及的數(shù)據(jù)量很大，OceanBase 數(shù)據(jù)庫的查詢執(zhí)行引擎也做了并行處理、任務(wù)拆分、動態(tài)分區(qū)、流水調(diào)度、任務(wù)裁剪、子任務(wù)結(jié)果合并、并發(fā)限制等優(yōu)化技術(shù)。

下圖描述了一條 SQL 語句的執(zhí)行過程，并列出了 SQL 引擎中各個(gè)模塊之間的關(guān)系。

• Parser（詞法/語法解析模塊）
Parser 是整個(gè) SQL 執(zhí)行引擎的詞法或語法解析器，在收到用戶發(fā)送的 SQL 請求串后，Parser 會將字符串分成一個(gè)個(gè)的單詞，并根據(jù)預(yù)先設(shè)定好的語法規(guī)則解析整個(gè)請求，將 SQL 請求字符串轉(zhuǎn)換成帶有語法結(jié)構(gòu)信息的內(nèi)存數(shù)據(jù)結(jié)構(gòu)，稱為語法樹（Syntax Tree）。為了加速 SQL 請求的處理速度，OceanBase 數(shù)據(jù)庫對 SQL 請求采用了特有的快速參數(shù)化，以加速查找執(zhí)行計(jì)劃的速度。

• Resolver（語義解析模塊）
當(dāng)生成語法樹之后，Resolver 會進(jìn)一步將該語法樹轉(zhuǎn)換為帶有數(shù)據(jù)庫語義信息的內(nèi)部數(shù)據(jù)結(jié)構(gòu)。在這一過程中，Resolver 將根據(jù)數(shù)據(jù)庫元信息將 SQL 請求中的 token 翻譯成對應(yīng)的對象（例如庫、表、列、索引等），生成語句樹。

• Transfomer（邏輯改寫模塊）
在查詢優(yōu)化中，經(jīng)常利用等價(jià)改寫的方式，將用戶 SQL 轉(zhuǎn)換為與之等價(jià)的另一條 SQL，以便于優(yōu)化器生成最佳的執(zhí)行計(jì)劃，這一過程稱為查詢改寫。Transformer 在 Resolver 之后，分析用戶 SQL 的語義，并根據(jù)內(nèi)部的規(guī)則或代價(jià)模型，將用戶 SQL改寫為與之等價(jià)的其他形式，并將其提供給后續(xù)的優(yōu)化器做進(jìn)一步的優(yōu)化。Transformer 的工作方式是在原 Statement Tree 上做等價(jià)變換，變換的結(jié)果仍然是一棵語句樹。

• Optimizer（優(yōu)化器）
優(yōu)化器是整個(gè) SQL 優(yōu)化的核心，其作用是為 SQL 請求生成最佳的執(zhí)行計(jì)劃。在優(yōu)化過程中，優(yōu)化器需要綜合考慮 SQL 請求的語義、對象數(shù)據(jù)特征、對象物理分布等多方面因素，解決訪問路徑選擇、聯(lián)接順序選擇、聯(lián)接算法選擇、分布式計(jì)劃生成等多個(gè)核心問題，最終選擇一個(gè)對應(yīng)該 SQL 的最佳執(zhí)行計(jì)劃。SQL 的執(zhí)行計(jì)劃是一棵由多個(gè)操作符構(gòu)成的執(zhí)行樹。

• Code Generator（代碼生成器）
優(yōu)化器負(fù)責(zé)生成最佳的執(zhí)行計(jì)劃，但其輸出的結(jié)果并不能立即執(zhí)行，還需要通過代碼生成器將其轉(zhuǎn)換為可執(zhí)行的代碼，這個(gè)過程由 Code Generator 負(fù)責(zé)。

• Executor（執(zhí)行器）
當(dāng) SQL 的執(zhí)行計(jì)劃生成后，Executor 會啟動該 SQL 的執(zhí)行過程。對于不同類型的執(zhí)行計(jì)劃，Executor 的邏輯有很大的不同：對于本地執(zhí)行計(jì)劃，Executor 會簡單的從執(zhí)行計(jì)劃的頂端的算子開始調(diào)用，由算子自身的邏輯完成整個(gè)執(zhí)行的過程，并返回執(zhí)行結(jié)果；對于遠(yuǎn)程或分布式計(jì)劃，Executor 需要根據(jù)預(yù)選的劃分，將執(zhí)行樹分成多個(gè)可以調(diào)度的線程，并通過 RPC 將其發(fā)送給相關(guān)的節(jié)點(diǎn)執(zhí)行。

• Plan Cache（執(zhí)行計(jì)劃緩存模塊）
執(zhí)行計(jì)劃的生成是一個(gè)比較復(fù)雜的過程，耗時(shí)比較長，尤其是在 OLTP 場景中，這個(gè)耗時(shí)往往不可忽略。為了加速 SQL 請求的處理過程，SQL 執(zhí)行引擎會將該 SQL 第一次生成的執(zhí)行計(jì)劃緩存在內(nèi)存中，后續(xù)的執(zhí)行可以反復(fù)執(zhí)行這個(gè)計(jì)劃，避免了重復(fù)查詢優(yōu)化的過程。