OceanBase 數據庫概覽-數據庫介紹
集群節點全對等，每個節點都具備計算和存儲能力，無單點瓶頸。支持線性擴展，在線擴展，單一數據庫集群最大超過 1500 台服務器。
數據采用多副本存儲，少數副本故障不影響數據可用性，RPO = 0（Recovery Point Objective，零數據丟失），RTO < 30秒（Recovery Time Objective，故障恢復時間小於 30 秒）。
數據多副本通過 Paxos 協議同步事務日志，多數派成功才能提交。缺省情況下讀、寫操作在主副本進行保證強一致。
- 支持 MySQL 5.6 版本全部語法，可以實現 MySQL 業務無縫切換。
- 支持絕大部分的 Oracle 數據類型和對象、SQL 語法、函數、過程性語言等功能
面向海量事務處理的分布式數據庫系統 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 上各個分區的管理和操作功能的模塊，這個模塊與事務引擎、存儲引擎存在很多調用關系。
OceanBase 數據庫基於 Paxos 的分布式選舉算法來實現系統的高可用，最小的粒度可以做到分區級別。集群中數據的一個分區（或者稱為副本）會被保存到所有的 Zone 上，整個系統中該副本的多個分區之間通過 Paxos 協議進行日志同步。每個分區和它的副本構成一個獨立的 Paxos 復制組，其中一個分區為主分區（Leader），其它分區為備分區（Follower）。所有針對這個副本的寫請求，都會自動路由到對應的主分區上進行。主分區可以分布在不同的 OBServer 上，這樣對於不同副本的寫操作也會分布到不同的數據節點上，從而實現數據多點寫入，提高系統性能。
在內存中針對不同的數據訪問行為，OceanBase 數據庫設計了多種緩存結構。
除了常見的數據塊緩存之外，也會對行進行緩存，行緩存會極大加速對單行的查詢性能。
為了避免對不存在行的“空查”，OceanBase 數據庫對行緩存構建了布隆過濾器，並對布隆過濾器進行緩存。
當內存的增量數據達到一定規模的時候，會觸發增量數據和基線數據的合並，把增量數據落盤。
同時每天晚上的空閑時刻，系統也會啟動每日合並。
另外，由於基線是只讀數據，而且內部采用連續存儲的方式，OceanBase 數據庫可以根據不同特點的數據采用不同的壓縮算法，既能做到高壓縮比，又不影響查詢性能，大大降低了成本。
OceanBase 數據庫的 SQL 引擎是整個數據庫的數據計算中樞，和傳統數據庫類似，整個引擎分為解析器、優化器、執行器三部分。
Region 指一個地域或者城市（例如杭州、上海、深圳等），一個 Region 包含一個或者多個 Zone，不同 Region 通常距離較遠。OceanBase 支持一份數據的多個副本跨 Region 部署。
Zone 是 Availability Zone 的簡稱。一個 OceanBase 集群，由若干個可用區（Zone）組成。通常由一個機房內的若干服務器組成一個 Zone。為了數據安全性和高可用性，一般會把數據的多個副本分布在不同的 Zone 上，可以實現單個 Zone 故障不影響數據庫服務。
運行 OBServer 進程的物理機。一台物理機上可以部署一個或者多個 OBServer。在 OceanBase 內部，server 由其 IP 地址和服務端口唯一標識。
一個租戶擁有若干個資源池，這些資源池的集合描述了這個租戶所能使用的所有資源。一個資源池由具有相同資源規格（Unit Config）的若干個 UNIT（資源單元）組成。一個資源池只能屬於一個租戶。每個 UNIT 描述了位於一個 Server 上的一組計算和存儲資源，可以視為一個輕量級虛擬機，包括若干 CPU 資源，內存資源，磁盤資源等。
一個租戶在同一個 Server 上最多有一個 UNIT。實際上，從概念上講，副本是存儲在 UNIT 之中，UNIT 是副本的容器。
OceanBase 數據庫集群由一個或多個 Region 組成，
Region 由一個或多個 Zone 組成，
Zone 由一台或多台服務器組成。
Region 對應物理上的一個城市或地域，
當 OceanBase 數據庫集群由多個 Region 組成時，數據庫的數據和服務能力就擁有地域級容災能力，當集群只有一個 Region 時，如果出現整個城市級別的故障，則會影響數據庫的數據和服務能力。
Zone 對應一個有獨立網絡和供電容災能力的數據中心，
在一個 Region 內的多個 Zone 間 OceanBase 數據庫集群擁有 Zone 故障時的容災能力。通常情況下，OceanBase 數據庫集群的一個 Zone 內只會有數據的一份拷貝，如果整個集群只有一個 Zone，則集群沒有容災能力。
如果實際的運行環境只有一個數據中心的若干台機器，則可以將若干台機器划分成虛擬的 Zone，OceanBase 數據庫會在這些虛擬的 Zone 之間具備容災能力。
OceanBase 數據庫的無損容災能力還可以方便集群的運維操作.
數據中心或者服務器需要替換和維修時，可以直接下線對應的數據中心或服務器進行替換和維修，並補充進新的數據中心或服務器，OceanBase 數據庫系統會自動進行數據的復制和均衡，整個過程可以保證數據庫服務的使用不受影響。
OceanBase 數據庫集群的每台服務器上會運行 observer 進程，observer 進程負責整個數據庫服務的各項功能，包括資源管理與租戶創建，數據分布的管理，數據副本之間的 Paxos 協議，單機或分布式的數據查詢與修改等。
OceanBase 數據庫是多租戶的分布式數據庫，用戶可以在一個集群內部創建多個相互獨立的租戶，每個租戶是一個獨立的數據庫服務，用戶可以指定需要的硬件資源，創建數據庫服務的賬號、表格、存儲過程等對象。
租戶的硬件資源以資源池（Resource Pool）的形式進行描述，資源池是由資源單元（Resource Unit）組成，資源單元是數據庫服務內部分配的 CPU、內存、硬盤等硬件資源。
資源單元對應 CPU、內存、存儲空間、IOPS 這幾個物理資源，是 OceanBase 數據庫服務內部的資源容器。
資源單元會在集群內自動負載均衡，任何一個資源單元一定會放置在一個資源足夠容納它的服務器上。
當集群內的服務器下線前，其上的資源單元必須遷移到其他服務器上，如果集群內其他服務器的資源不足以容納將要下線的服務器上的資源單元，會導致服務器下線無法成功。
資源單元配置是描述資源單元的配置信息，每一個資源單元配置會描述一種規格的 CPU、內存、存儲空間、IOPS。修改資源配置可以動態調整資源單元的計算資源，進而調整對應租戶的資源。
資源池由具有相同資源單元配置的若干個資源單元組成。
一個資源池只能屬於一個租戶。
一個租戶可以擁有一個或多個資源池，這些資源池的集合描述了這個租戶所能使用的所有物理機器資源。
一個租戶在同一個服務器 上最多有一個資源單元。
傳統數據庫支持分區表.
常見的分區方式包括 Hash 分區、Range 分區、List 分區，且支持二級組合分區。
OceanBase 數據庫沿用了分區表的使用方式，但是分區可以均勻分布在數據庫任意節點上。
OceanBase 數據庫以分布式分區表數據模型為基礎，一方面，數據存儲和處理能力能夠水平擴展，享受分布式技術的紅利，另一方面，使用者不感知后端的分布式架構，可以像使用單機數據庫一樣使用分布式數據庫，具有完整的全局索引和全局約束。
OceanBase 數據庫通過引入表格組（table group）來盡可能地減少分布式事務。
表格組用於聚集經常一起訪問的多張表格。例如，有用戶基本信息表（user）和用戶商品表（user_item），這兩張表格都按照用戶編號哈希分布，只需要將二者設置為相同的表格組，系統后台就會自動將同一個用戶所在的 user 表分區和 user_item 表分區調度到同一台服務器。這樣，即使操作某個用戶的多張表格，也不會產生跨機事務。這種設計兼具分布式系統的擴展性和關系數據庫的易用性和靈活性，符合 DBA 的使用習慣。
主均衡策略解決的整體思路為：在某個均衡組中，根據副本的分布情況，實時挑選主，挑選主的結果為：primary_zone 上資源單元上分布的主的數量均衡。
租戶是一個邏輯概念，在 OceanBase 數據庫里是資源分配的單位，是數據庫對象管理和資源管理的基礎。
對於系統運維，尤其是對於雲數據庫的運維有着重要的影響。租戶在一定程度上相當於傳統數據庫的“實例”概念。
租戶之間是完全隔離的。
在數據安全方面，不允許跨租戶的數據訪問，確保用戶的數據資產沒有泄露的風險。
在資源使用方面表現為租戶“獨占”其資源配額。
總體上來說，租戶（tenant）既是各類數據庫對象的容器，又是資源（CPU、Memory、IO 等）的容器。
OceanBase 系統中包含兩大類的租戶：系統租戶和普通租戶。
(這不就是實例instance的概念嗎?按照此理解)
普通租戶具備一個實例所應該具有的所有特性：
- 可以創建自己的用戶
- 可以創建數據庫（database）、表（table）等所有客體對象
- 有自己獨立的 information_schema 等系統數據庫
- 有自己獨立的系統變量
- 數據庫實例所具備的其他特性
多租戶隔離有不同的實現方式，這些實現方式的效果是類似的。
OceanBase 數據庫采用的是在數據庫內部實現一個 SQL 虛擬機，
這種方案的好處是 DB 內把很多業務統一管理，把整個管理機制做得對用戶特別透明。
另外隔離的開銷比較低，單台服務器可以服務更多的租戶，降低雲服務的整體成本。
租戶隔離分為三個部分：CPU、IO 還有內存，網絡目前還不是瓶頸，不做隔離。
OceanBase 數據庫是分布式系統.
多租戶除了單機層面怎么做隔離，還涉及到在多機層面如何做調度。
OceanBase 數據庫的負載均衡分為兩個層面：
第一個層面是租戶負載均衡，即把每個租戶的資源容器分布到很多台 OBServer 上面去。
第二個層面是分區負載均衡.
如果租戶只在一台服務器，第二個層面是沒有必要的。如果租戶在多台服務器上，需要把這個租戶的分區均勻地分布到它的資源容器中。OceanBase 數據庫內部會盡量使得小租戶只在一台服務器上，避免分布式事務。當租戶需要的資源逐步增加時，OceanBase 數據庫也能做到自動擴展，對用戶是透明的
OceanBase 數據庫概覽
事務管理
分布式事務
關於OceanBase的2PC的理論,需要進一步要求.
分布式查詢
在分布式數據庫里，查詢優化器會依據數據的分布信息生成分布式的執行計划。
存儲架構
LSM Tree
B-tree
Hash table
轉儲和合並
當 MemTable 的內存使用達到一定閾值時，就需要將 MemTable 中的數據存儲到磁盤上以釋放內存空間，這個過程稱之為“轉儲”。
在轉儲之前首先需要保證被轉儲的 MemTable 不再進行新的數據寫入，這個過程稱之為“凍結”（Minor Freeze）.
凍結會阻止當前活躍的 MemTable 再有新的寫入，並同時生成新的活躍 MemTable。
合並操作（Major Compaction）是將動靜態數據做歸並，會比較費時。當轉儲產生的增量數據積累到一定程度時，通過 Major Freeze 實現大版本的合並。
轉儲和合並的最大區別在於，合並是集群上所有的分區在一個統一的快照點和全局靜態數據進行合並的行為，是一個全局的操作，最終形成一個全局快照。
讀寫流程
與傳統數據庫的刷臟頁機制不同，OceanBase 數據庫的存儲引擎基於 LSM Tree 架構，對於數據塊的寫主要是在轉儲和合並階段。
在 MemTable 轉儲為 SSTable 時，也會在靜態數據中記錄當前的 clog 日志回放點，在轉儲完成之后，對應 clog 日志回放點之前的日志在理論上就可以被回收了，但通常這些日志文件並不會被立即刪除，而是等到日志空間不足時再進行日志文件的重用。