什麼是OceanBase?
OceanBase
資料庫是阿裡巴巴和螞蟻集團不基于任何開源産品，完全自研的原生分布式關系資料庫軟體，在普通硬體上實作金融級高可用，首創“三地五中心”城市級故障自動無損容災新标準，具備卓越的水準擴充能力，全球首家通過
TPC-C 标準測試的分布式資料庫，單叢集規模超過 1500 節點。 産品具有雲原生、強一緻性、高度相容 Oracle/MySQL 等特性，
承擔支付寶 100% 核心鍊路，在國内幾十家銀行、保險公司等金融客戶的核心系統中穩定運作。
- TTPC（transaction processing performance council）被稱為事務處理性能委員會，負責定義諸如 TPC-C、TPC-H&TPC-R 和 TPC-W 基準測試之類的事務處理與資料庫性能基準測試，并依據這些基準測試項目釋出客觀性能資料。TPC- C主要針對線上事務處理，模拟了以下五種食事物
OceanBase官方文檔閱讀筆記（一） - 在普通硬體上實作金融級高可用。
- 雲原生特性在我看來非常有用，可進行容器化部署，便于運維。
産品優勢
業務連續性
高可用
OceanBase
資料庫的每個節點都可以作為全功能節點，将資料以多副本的方式分布在叢集的各個節點，可以輕松實作多庫多活，少數派節點出現故障對業務無感覺。OceanBase
資料庫的多副本技術能夠滿足從節點、機架、機房到城市級别的高可用、容災要求，克服傳統資料庫的主備模式在主節點出現異常時 RPO>0
的問題。確定客戶的業務系統能夠穩定、安全運作。
OceanBase 資料庫支撐了支付寶 100% 的核心鍊路，并且在多家商業銀行的核心業務中穩定運作，久經考驗。
可擴充
傳統資料庫受限于單機的處理能力極限，高昂的擴充成本，使得很多系統在面臨高并發，或者資料量達到一定程度後顯得力不從心。OceanBase
資料庫獨創的總控服務和分區級負載均衡能力使系統具有極強的可擴充性，可以線上進行平滑擴容或縮容，并且在擴容後自動實作系統負載均衡，對應用透明，完成對海量資料的處理。對于銀行、保險、營運商等行業的高并發場景，OceanBase
資料庫能夠提供高性能、低成本、高彈性的資料庫服務，并且能夠充分利用客戶的 IT 資源。此外，OceanBase
資料庫還經曆過多次雙十一的流量洪峰考驗。
從這裡可以看出oceanbase的穩定性，一般資料庫優先維持強一緻性，通過叢集部署的方式達到高可用，希望在後續的文檔中能看出其高可用的獨特具體實作形式。
平滑擴縮容兼具的kubernetes的一些特性，估計是使用到了其上文提到的總控服務。分區級負載均衡這個概念在eureka和nacos等注冊發現中心中都有所提及。若是沒有将資料庫作為單獨叢集部署出來，會對其擴縮容能力和負載均衡能力影響有多大呢。
應用易用性
HTAP
OceanBase 資料庫獨創的分布式計算引擎，能夠讓系統中多個計算節點同時運作 OLTP 類型的應用和複雜的 OLAP
類型的應用，真正實作了用一套計算引擎同時支援混合負載的能力，讓使用者通過一套系統解決 80%
的問題，充分利用客戶的計算資源，節省客戶因購買額外硬體資源或軟體授權所帶來的成本。
相容性
OceanBase 資料庫針對 MySQL 和 Oracle 資料庫生态都給予了很好的支援。對于 MySQL，OceanBase 資料庫支援
MySQL 5.6 版本全部文法，可以做到 MySQL 業務無縫切換。 對于 Oracle，OceanBase 資料庫能夠支援絕大多數的
Oracle 文法和幾乎全量的過程性語言功能，可以做到大部分的 Oracle 業務進行少量修改後自動遷移。幫助客戶降低系統的開發、遷移成本。
低成本
OceanBase 資料庫可以在通用伺服器上運作，不依賴于特定的高端硬體，能夠有效降低使用者的硬體成本。
OceanBase 資料庫使用的基于 LSM-Tree 的存儲引擎，能夠有效地對資料進行壓縮，并且不影響性能，可以降低使用者的存儲成本。
低風險
OceanBase
資料庫不基于任何開源資料庫技術，完全自主研發，對于産品有完全的掌控力，能夠避免客戶使用開源技術所帶來的潛在合規、知識産權、SLA 等風險。
OceanBase 資料庫目前完成了與國産硬體平台、作業系統的适配，降低客戶對國外硬體、作業系統的依賴。
為什麼是 HTAP？
在網際網路浪潮出現之前，企業的資料量普遍不大，特别是核心的業務資料，通常一個單機的資料庫就可以儲存。那時候的存儲并不需要複雜的架構，所有的線上請求 (OLTP, Online Transactional Processing) 和背景分析 (OLAP, Online Analytical Processing) 都跑在同一個資料庫執行個體上。
随着網際網路的發展，企業的業務資料量不斷增多，單機資料庫的容量限制制約了其在海量資料場景下的使用。是以在實際應用中，為了面對各種需求，OLTP、OLAP 在技術上分道揚镳，在很多企業架構中，這兩類任務處理由不同團隊完成。當物聯網大資料應用不斷深入，具有海量的傳感器資料要求實時更新和查詢，對資料庫的性能要求也越來越高，此時，新的問題随之出現：
OLAP 和 OLTP 系統間通常會有幾分鐘甚至幾小時的時延，OLAP 資料庫和 OLTP 資料庫之間的一緻性無法保證，難以滿足對分析的實時性要求很高的業務場景。
企業需要維護不同的資料庫以便支援兩類不同的任務，管理和維護成本高。
是以，能夠統一支援事務處理和工作負載分析的資料庫成為衆多企業的需求。在此背景下，由 Gartner 提出的 HTAP（混合事務 / 分析處理，Hybrid Transactional/Analytical Processing）成為希望。基于創新的計算存儲架構，HTAP 資料庫能夠在一份資料上同時支撐業務系統運作和 OLAP 場景，避免在傳統架構中，線上與離線資料庫之間大量的資料互動。此外，HTAP 基于分布式架構，支援彈性擴容，可按需擴充吞吐或存儲，輕松應對高并發、海量資料場景。
目前，實作 HTAP 的資料庫不多，主要有 PingCAP 的 TiDB、阿裡雲的 HybridDB for MySQL、百度的 BaikalDB 等。其中，TiDB 是國内首家開源的 HTAP 分布式資料庫，接下來，本文将以此例進行深入分析。
叢集架構
OceanBase 資料庫采用 Shared-Nothing 架構，各個節點之間完全對等，每個節點都有自己的 SQL
引擎、存儲引擎，運作在普通 PC 伺服器組成的叢集之上，具備可擴充、高可用、高性能、低成本、雲原生等核心特性。
OceanBase 資料庫的整體架構如下圖所示。
OceanBase官方文檔閱讀筆記（一）
總的來說，shared nothing降低了競争資源的等待時間，進而提高了性能。反過來，如果一個資料庫應用系統要獲得良好的可擴充的性能，它從設計和優化上就要考慮 shared nothing體系結構。Share nothing means few contention.它在oracle資料庫設計和優化上有很多相同之處。
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 語句。
有k8s那味了，說明OB叢集得單獨部署，友善讓OB更大限度的控制伺服器，進行資源排程。
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
資料庫設計了多種緩存結構。除了常見的資料塊緩存之外，也會對行進行緩存，行緩存會極大加速對單行的查詢性能。為了避免對不存在行的空查，OceanBase
資料庫對行緩存建構了布隆過濾器，并對布隆過濾器進行緩存。OLTP 業務大部分操作為小查詢，通過小查詢優化，OceanBase
資料庫避免了傳統資料庫解析整個資料塊的開銷，達到了接近記憶體資料庫的性能。當記憶體的增量資料達到一定規模的時候，會觸發增量資料和基線資料的合并，把增量資料落盤。同時每天晚上的空閑時刻，系統也會啟動每日合并。另外，由于基線是隻讀資料，而且内部采用連續存儲的方式，OceanBase
資料庫可以根據不同特點的資料采用不同的壓縮算法，既能做到高壓縮比，又不影響查詢性能，大大降低了成本。
有eureka的感覺，在第一次下載下傳系統資料庫的時候全量下載下傳，其次增量下載下傳，保證疊代穩定性，和docker的overlay存儲技術很相似，底層鏡像相同，修改時修改上層，最後合并成修改後，節省了一定的空間。
SQL 引擎
OceanBase 資料庫的 SQL 引擎是整個資料庫的資料計算中樞，和傳統資料庫類似，整個引擎分為解析器、優化器、執行器三部分。當 SQL
引擎接受到了 SQL
請求後，經過文法解析、語義分析、查詢重寫、查詢優化等一系列過程後，再由執行器來負責執行。所不同的是，在分布式資料庫裡，查詢優化器會依據資料的分布資訊生成分布式的執行計劃。如果查詢涉及的資料在多台伺服器，需要走分布式計劃，這是分布式資料庫
SQL 引擎的一個重要特點，也是十分考驗查詢優化器能力的場景。OceanBase
資料庫查詢優化器做了很多優化，諸如算子下推、智能連接配接、分區裁剪等。如果 SQL 語句涉及的資料量很大，OceanBase
資料庫的查詢執行引擎也做了并行處理、任務拆分、動态分區、流水排程、任務裁剪、子任務結果合并、并發限制等優化技術。
下圖描述了一條 SQL 語句的執行過程，并列出了 SQL 引擎中各個子產品之間的關系。
請求流程
OceanBase官方文檔閱讀筆記（一）
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 第一次生成的執行計劃緩存在記憶體中，後續的執行可以反複執行這個計劃，避免了重複查詢優化的過程。