面向海量事務處理的分布式數據庫系統 OceanBase 數據庫采用了 Zone(可用區)的概念，每個 Zone 是一個機房內的一組服務器，包含多臺 OceanBase 數據庫服務器(OBServer)。每臺 OBServer 包含 SQL 引擎、事務引擎和存儲引擎，并服務多個數據分區，其中，每個 Zone 有一臺 OBServer 會同時使能總控服務(RootService)，用于執行集群管理、服務器管理、自動負載均衡等操作。OBServer 上會運行 SQL 引擎、事務引擎和存儲引擎，用戶的 SQL 查詢經過 SQL 引擎解析優化后轉化為事務引擎和存儲引擎的內部調用。對于跨服務器操作，OceanBase 數據庫還會執行強一致的分布式事務，從而在分布式集群上實現數據庫事務 ACID。

OceanBase 數據庫采用 Shared-Nothing 架構，各個節點之間完全對等，每個節點都有自己的 SQL 引擎、事務引擎、存儲引擎，運行在普通 PC 服務器組成的集群之上，具備可擴展、高可用、高性能、低成本等核心特性。

集群架構

OceanBase 數據庫支持數據跨地域(Region)部署，每個地域可能位于不同的城市，距離通常比較遠，所以 OceanBase 數據庫可以支持多城市部署，也支持多城市級別的容災。一個 Region 可以包含一個或者多個 Zone，Zone 是一個邏輯的概念，它包含了 1 臺或者多臺運行了 OBServer 進程的服務器(以下簡稱 OBServer)。每一個 Zone 上包含一個副本(全功能副本或者日志副本)，由于 OceanBase 數據庫的數據副本是以分區為單位的，所以同一個分區的數據會分布在多個 Zone 上。每個分區的主副本所在服務器被稱為 Leader，所在的 Zone 被稱為 Primary Zone。如果不設定 Primary Zone，系統會根據負載均衡的策略，在多個全功能副本里自動選擇一個作為 Leader。

每個 Zone 會提供兩種服務：總控服務(RootService)和分區服務(PartitionService)。其中每個 Zone 上都會存在一個總控服務，運行在某一個 OBServer上，整個集群中只存在一個主總控服務，其他的總控服務作為主總控服務的備用服務運行。總控服務負責整個集群的資源調度、資源分配、數據分布信息管理以及 Schema 管理等功能。 其中：資源調度主要包含了向集群中添加、刪除 OBServer，在 OBServer 中創建資源規格、Tenant 等供用戶使用的資源；

資源均衡主要是指各種資源(例如：Unit)在各個 Zone 或者 OBServer 之間的遷移。

數據分布管理是指總控服務會決定數據分布的位置信息，例如：某一個分區的數據分布到哪些 OBServer 上。

Schema 管理是指總控服務會負責調度和管理各種 DDL 語句。

分區服務用于負責每個 OBServer 上各個分區的管理和操作功能的模塊，這個模塊與事務引擎、存儲引擎存在很多調用關系。

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

存儲引擎

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

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

SQL 引擎

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

下圖描述了一條 SQL 語句的執行過程，并列出了 SQL 引擎中各個模塊之間的關系。Parser(詞法/語法解析模塊)

Parser 是整個 SQL 執行引擎的詞法/語法解析器，在收到用戶發送的 SQL 請求串后，Parser 會將字符串分成一個個的“單詞”，并根據預先設定好的語法規則解析整個請求，將 SQL 請求字符串轉換成帶有語法結構信息的內存數據結構，稱為“語法樹”(Syntax Tree)。

為了加速 SQL 請求的處理速度，OceanBase 數據庫對 SQL 請求采用了特有的“快速參數化”，以加速查找執行計劃的速度。

Resolver(語義解析模塊)

當生成“語法樹”之后，Resolver 會進一步將該語法樹轉換為帶有數據庫語義信息的內部數據結構。在這一過程中，Resolver 將根據數據庫元信息將 SQL 請求中的 token 翻譯成對應的對象(例如庫、表、列、索引等)，生成“語句樹”。

Transfomer(邏輯改寫模塊)

在查詢優化中，經常利用等價改寫的方式，將用戶 SQL 轉換為與之等價的另一條 SQL，以便于優化器生成最佳的執行計劃，我們稱這一過程為“查詢改寫”。Transformer 在 Resolver 之后，分析用戶 SQL 的語義，并根據內部的規則或代價模型，將用戶 SQL 改寫為與之等價的其他形式，并將其提供給后續的優化器做進一步的優化 Transformer 的工作方式是在原 Statement Tree 上做等價變換，變換的結果仍然是一棵“語句樹”。

Optimizer(優化器)

優化器是整個 SQL 優化的核心，其作用是為 SQL 請求生成最佳的執行計劃。在優化過程中，優化器需要綜合考慮 SQL 請求的語義、對象數據特征、對象物理分布等多方面因素，解決訪問路徑選擇、連接順序選擇、連接算法選擇、分布式計劃生成等多個核心問題，最終選擇一個對應該 SQL 的最佳執行計劃。SQL 的執行計劃是一棵由多個操作符構成的“執行樹”。

Code Generator(代碼生成器)

優化器負責生成最佳的執行計劃，但其輸出的結果并不能立即執行，還需要通過代碼生成器將其轉換為可執行的代碼，這個過程由 Code Generator 負責。

Executor(執行器)

當 SQL 的執行計劃生成后，Executor 會啟動該 SQL 的執行過程。對于不同類型的執行計劃，Executor 的邏輯有很大的不同：對于本地執行計劃，Executor 會簡單的從執行計劃的頂端的算子開始調用，由算子自身的邏輯完成整個執行的過程，并返回執行結果；對于遠程或分布式計劃，Executor 需要根據預選的劃分，將執行樹分成多個可以調度的線程，并通過 RPC 將其發送給相關的節點執行。

Plan Cache(執行計劃緩存模塊)

執行計劃的生成是一個比較復雜的過程，耗時比較長，尤其是在 OLTP 場景中，這個耗時往往不可忽略。為了加速 SQL 請求的處理過程，SQL 執行引擎會將該 SQL 第一次生成的執行計劃緩存在內存中，后續的執行可以反復執行這個計劃，避免了重復查詢優化的過程。

總結

以上是生活随笔為你收集整理的oceanbase基于mysql吗_OCEANBASE整体架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。