OB-初窺

https://www.oceanbase.com/docs/oceanbase-database/oceanbase-database/V3.1.2/what-is-oceanbase

概述

OceanBase 數據庫是分布式關系數據庫軟件，具有雲原生、強一致性、高度兼容 Oracle/MySQL 等特性。

支持混合負載的能力，可以同時運行 OLTP 類型的應用和復雜的 OLAP 類型的應用。

兼容性

• 支持 MySQL 5.6 版本全部語法
• 支持絕大多數的 Oracle 語法和幾乎全量的過程性語言功能

業務連續性

高可用

數據以多副本的方式分布在集群的各個節點上

• RPO = 0（Recovery Point Objective，零數據丟失）
• RTO < 30秒（Recovery Time Objective，故障恢復時間小於 30 秒）

可擴展

支持在線擴縮容

概念

地域（Region）

Region 指一個地域或者城市（例如杭州、上海、深圳等），一個 Region 包含一個或者多個 Zone

可用區/區（Zone）

Zone 是 Availability Zone 的簡稱。一個 OceanBase 集群，由若干個可用區（Zone）組成。通常由一個機房內的若干服務器組成一個 Zone。

OBServer

運行 OBServer 進程的物理機。一台物理機上可以部署一個或者多個 OBServer。在 OceanBase 內部，server 由其 IP 地址和服務端口唯一標識。

資源池（Resource Pool）

一個資源池由具有相同資源規格（Unit Config）的若干個 UNIT（資源單元）組成。一個資源池只能屬於一個租戶。每個 UNIT 描述了位於一個 Server 上的一組計算和存儲資源，包括CPU 資源，內存資源，磁盤資源等。

OBProxy

OceanBase 數據庫代理 ODP（OceanBase Database Proxy，又稱 OBProxy）是 OceanBase 專用的代理服務器，OceanBase 用戶的數據會以多副本的形式存放在各個 OBServer 上，ODP 則負責接收用戶發過來的 SQL 請求，轉發用戶 SQL 請求到最佳目標 OBServer 上，並將執行結果返回給客戶。

RS（RootServer）

主控服務器。主要負責集群管理、數據分布和副本管理。

Multi-Paxos

一種執行多 Paxos 實例的優化協議，OceanBase 用 Multi-Paxos 協議實現 Commit Log 的多機持久化

ODC

OceanBase 開發者中心（OceanBase Developer Center，ODC）是為 OceanBase 數據庫量身打造的企業級數據庫開發平台。ODC 支持連接 OceanBase 中 MySQL 和 Oracle 模式下的數據庫，同時為數據庫開發者提供了數據庫日常開發操作、WebSQL、SQL 診斷、會話管理和數據導入導出等功能。

OCP

OceanBase 雲平台（OceanBase Cloud Platform，OCP）伴隨 OceanBase 數據庫而生，是一款以 OceanBase 為核心的企業級數據庫管理平台。不僅提供對 OceanBase 集群和租戶等組件的全生命周期管理服務，同時也對 OceanBase 相關的資源（主機、網絡和軟件包等）提供管理服務，讓您能夠更加高效地管理 OceanBase 集群，降低企業的 IT 運維成本。

OMS

OceanBase 遷移服務（OceanBase Migration Service，OMS）是 OceanBase 提供的一種支持同構或異構 RDBMS 與 OceanBase 之間進行數據交互的服務，它提供了數據的在線遷移和實時增量同步的數據復制能力。

系統架構

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

架構圖

集群架構

一個 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 第一次生成的執行計划緩存在內存中，后續的執行可以反復執行這個計划，避免了重復查詢優化的過程。

功能特性

分布式事務

嚴格支持事務的 ACID 屬性，OB通過 Paxos 協議將事務日志復制到多個數據副本來保證事務的可用性和持久性。

高可用

• 提供基於日志復制技術的主備庫特性，支持switchover和failover切換角色

• 提供基於數據塊拷貝和事務日志拷貝的物理備份恢復特性

HTAP能力

混合事務和分析處理（Hybrid Transaction and Analytical Process，HTAP）

OB使用同一套計算引擎同時支持混合負載的能力。

多租戶

OB通過租戶實現資源隔離，支持公有雲，私有雲和混合雲環境部署。

安全性

• 支持權限與角色體系
• 支持SSL
• 數據透明加密
• 審計
• Label Security
• IP 白名單

產品體系

OceanBase 產品體系中包含五款產品，即 OceanBase 數據庫、OceanBase 雲平台、OceanBase 開發者中心、OceanBase 遷移服務和 OceanBase 管理員工具，分別提供數據庫、運維管理、數據庫開發、數據庫遷移等服務