OB君

：本文來自6月27日慶濤在雲和恩墨主辦的DTC線上資料庫技術實戰峰會中的直播分享內容，主題為《從Oracle、MySQL到OceanBase：入門介紹》

概述

OceanBase是阿里巴巴和螞蟻金服

完全自主研發的通用的分散式關係型資料庫

，定位為商用企業級資料庫。OceanBase能提供

金融級別的可靠性

，目前主要應用用於金融行業，同時也適用於非金融行業場景。

OceanBase目前主要有1。x和2。x兩個版本序列。1。x版本相容MySQL常用語法，2。x版本以相容Oracle常用語法為目標。OceanBae支援多租戶，即在一個OceanBase集群裡會劃分出多個租戶（即例項），而租戶的型別是相容MySQL或者Oracle。業務方使用的只是租戶（例項），是叢集能力的一個子集。在使用體驗上會感覺租戶像MySQL或Oracle，但又不完全一樣。OceanBase並不是在重造一個MySQL或Oracle，而只是在功能介面上相容它們，在底層架構上，不管哪種租戶都有分散式能力。

所以，當業務開發和運維從Oracle/MySQL轉到OceanBase後，需要了解一些OceanBase的原理和不同之處，

本文主要就是對OceanBase跟Oracle/MySQL的相同之處和不同之處為讀者做一個概要說明。

OceanBase是什麼？

Oracle軟體是多程序程式

，啟動後會開闢一塊共享記憶體。Oracle部署形態有單例項、叢集RAC、主備Dataguard。MySQL軟體是單程序，程序名叫mysqld，有的還會有守護程序mysql_safe。MySQL的部署形態有單例項、主從單向同步或主主雙向同步和MySQL Cluster（用的比較少）。

OceanBase的軟體是單程序

，名字叫OBServer。OceanBase是分散式資料庫，叢集部署，通常每個機器（後面統一稱為節點）上會啟動一個OBServer程序，各個節點的OBServer程序組成一個叢集執行。雖然應用可以直接訪問任意一個節點的例項，但不推薦。

通常是在OceanBase叢集前面啟動一個或多個反向代理OBProxy。

OBProxy只負責資料路由和傳輸

，不涉及到資料運算（如連線、統計、合併或排序等）。OBProxy的作用類似Oracle的監聽程式，不同的是資料返回的時候也是從OBProxy回去。這個以後再專門詳細介紹。對於業務而言，OBProxy就是資料庫的代表，可用性也很重要。所以一般會部署多個OBProxy掛載負載均衡裝置或軟體下面以VIP形式對外提供服務。

OBServer架構

每個OBServer程序包含兩個基本模組，一是SQL引擎，負責SQL解析、執行計劃生成、SQL運算等；二是儲存引擎，負責存取資料、合併凍結等

。這兩項功能實際上Oracle和MySQL都有，只是很少這麼提。在OceanBase集群裡，還需要一個總控服務rootservice，負責叢集級別的一些任務排程。總控服務只需要存在某個節點上，所以是可選的。

OBServer程序啟動後發生什麼？

OBServer程序啟動時，預設會將所在節點（即機器）的絕大部分資源據為己有

。比如說記憶體，會佔有80%左右，資料目錄的空間，會佔有90%左右，CPU，會保留2個給OS，其他全部宣告為OB的。當然我們都知道，除了OS自身，誰也不能獨佔CPU。OBServer程序本質上也只是OS裡的一個程序。所以對CPU的佔有是宣告式的。當然這裡的比例都是引數指定的，儲存在引數檔案裡，可以在啟動命令列裡修改引數。

OBServer資料目錄會有一個數據檔案，預設大小是資料目錄的90%。這個檔案承載了這個節點所有的OB資料。所以OB裡沒有表空間檔案、或者每個表一個檔案這種提法。不過OB有事務日誌檔案，叫Commit Log，簡稱clog。還有Index log， Storage Log等。OBServer還有執行日誌檔案，方便排查問題。目前日誌資訊量非常大，主要是面向核心開發的。

OceanBase叢集

要搭建一個OceanBase叢集，至少需要3臺機器。實際生產多是3的倍數。這些都是三副本架構的要求。機器會被等分為3份，每份劃歸一個Zone。Zone是邏輯劃分，實際可以對應為機房、單個機房的包間或者單個包間裡的機櫃。OceanBase叢集是無共享架構的，不依賴共享儲存，不需要直連線。搭建方法請參考《從0到1手把手教你搭建高可用的OceanBase資料庫叢集》。

當每個機器上都啟動OBServer程序後，叢集初始化成功後架構圖就如下：

每個OBServer節點都有一定的資源能力，組成集群后，所有資源就聚集為叢集的能力，總共有270C 1800G 36T。

OceanBase資料組織形式

當業務資料很多時，並不一定會放在一個數據庫下。會根據業務模組劃分多個集合。

在

Oracle

裡，每個例項下會分多個schemas，通常schema就是使用者。不同使用者的資料邏輯上彼此隔離，除非明確授權，否則不能跨使用者訪問。

在

MySQL

裡，每個例項下會分多個databases，也有多個使用者，不同使用者可以訪問不同的database，除非明確授權、否則不能訪問其他使用者的database。

在

OceanBase

裡，首先會有多個租戶（例項））。租戶與租戶之間的資料是邏輯隔離的，彼此無法互通。租戶的相容模式有Oracle和MySQL兩種（2選一）。相容Oracle時，租戶下面會分多個schemas，跟Oracle行為一致；相容MySQL時，租戶下面會分多個databases，跟MySQL行為一致。

所以，有的人使用OceanBase會問支援多個數據庫嗎？當理解上面這個設計後，答案不言自明。

OceanBase的原理

OceanBase如何利用機器資源？

資料庫的效能好不好取決於內外兩方面，內部因素就是核心產品自身能力，外部因素就是機器資源。傳統Oracle/MySQL以單例項形態部署的時候，最大隻能發揮一臺機器的能力，使用主備架構或者叢集部署的時候，倒是可以發揮多臺主機能力。但是這種機器資源管理的粒度還是很粗。

雲資料庫在機器資源管理上就好一些，能夠根據客戶需求定製特別規格的例項。雲資料庫本質上就是在賣機器資源，按資源規格付費。其中一種實現方案就是單機多例項部署。單機多例項部署的時候，記憶體資源各自是獨佔的，可以分。但是磁碟的IOPS能力和CPU能力通常是共享的。雲資料庫廠商的一種做法就是利用linux的cgroup對cpu和iops做資源隔離。現在流行的docker虛擬化技術更好一些，可以單機起多個docker，每個docker裡一個mysql例項。當然這只是雲廠商其中一個解決方案，更好的解決方案還有計算與儲存分離，大量使用分散式儲存產品。這是另外一個話題。

在OceanBase裡，前面我們看到了叢集把所有機器資源聚合在一起，然後又按需求分配給多個租戶。這個本身就是一種雲資料庫思想。所以

OceanBase天然就適合雲資料庫，不過跟雲資料庫業務沒有必然聯絡

。OceanBase目前主要都是私有化部署，在物理機上部署。不建議部署在虛擬機器上（規模小的時候虛擬化沒有意義，只會帶來效能損耗）。

每個租戶的資源是一個小的資源池（Resource Pool），是叢集資源池的子集。租戶的資源池由至少三個資源單元（Unit）組成。Unit存在於節點內部，不能跨節點存在。Unit在節點內的位置並不固定。同一個Zone內節點數如果大於等於2的話，

Unit是可以在同一個Zone內部多個節點之間自由遷移。這是OceanBase負載均衡的第一個方法

。

OceanBase如何分配資料儲存？

跟Oracle一樣，OceanBase使用表儲存業務資料。OceanBase的表是索引組織表，有非分割槽表和分割槽表兩種。非分割槽表只有一個分割槽，分割槽表有多個分割槽。分割槽就是表的子集。

每個分割槽只能在租戶的Unit內部建立，分割槽不能跨越Unit存在

。當租戶的資源池在每個Zone裡有多個Unit時，分割槽建立時就有多個選擇。並且分割槽也不會固定在某個Unit內部。

每個分割槽會有三個副本，其中角色是1個Leader副本，2個Follower副本。預設只有Leader副本提供讀寫服務，哪個節點內部有Leader分割槽副本，哪個節點就可能會有訪問。

分割槽可以在同一個Zone的多個Unit之間自由遷移，這就是OceanBase負載均衡的第二個方法

。

上圖中 t3 和 t4 業務上關聯非常密切（有表連線邏輯），二者分割槽策略完全一樣，可以放到一個表分組（tablegroup）裡，這樣兩個表的同號分割槽以及Leader就被約束在同一個Unit內部。當 t3 和 t4 做表連線時，可以規避跨節點請求。

OceanBase的多副本原理

多副本是一種資料冗餘技術，在Oracle/MySQL裡也有，只是不常這麼提。

Oracle的主備架構Dataguard可以說是兩副本。Oracle多副本之間內容同步是靠主庫傳輸Redo給多個備庫，然後備庫應用該Redo。在同步Redo的方式上Oracle就有多種策略。

最大保護、最大可用、最大效能

。其中最大保護最安全，主庫事務提交會等一個備庫Redo落盤成功，所以Redo有保障了，可以保證主備強一致。缺點是效能不是最好，並且如果備庫都不可用的時候，主庫也拒絕服務了。所以通常建議一主兩備。這時候也是三副本形態。還有個問題是主庫不可用的時候，需要DBA做主備切換，DBA必須能正確選擇出擁有全部Redo的那個備庫。

MySQL的主從複製架構也可以說是兩副本，副本之間內容同步靠從庫拉取主庫的Binlog以及應用Binlog

。Binlog裡面是SQL，是邏輯同步，這個跟Redo比不了。不過MySQL還是盡力的保證Binlog可靠性，所以就推出半同步（Semi-Sync）技術，主庫的事務提交也會等待備庫的Binlog接收確認（不一定是落盤確認），如果等待超時主庫就降級為非同步同步（完全不等待備庫確認了）。所以通常也建議使用半同步時配置一主兩從。同樣主故障時，也需要DBA手動啟用從庫，需要選擇擁有全部Binlog的從庫。

OceanBase至少三副本，副本之間使用Paxos協議同步Leader副本的Redo到Follower副本

。

策略是三個成員裡只要有超過半數以上成員接收Redo並落盤成功確認後，Leader副本上的事務即可提交

。在Leader出現故障時，只要還有多數成員存活，OceanBase就會從中選出新的Leader，並且確保這個新Leader擁有全部的Redo。所以OB的三副本是保證絕對不丟資料，自動故障切換兩個能力。這點跟Oracle/MySQL的三副本有很大區別。

在上面描述多副本原理過程中也提到了高可用。這裡就多說一點。

Oracle/MySQL的主備切換的粒度是例項維度，而OceanBase裡的故障切換的粒度是分割槽

。每個分割槽的三副本是一個獨立的Paxos Group，可以自行獨立選主。一個節點故障時，也只有節點內部為Leader的副本服務會中斷，並自動選出新的Leader。

這是OceanBase跟Oracle/MySQL相比最大的區別。

OceanBase的開發

鎖、事務和超時機制

OceanBase的租戶相容MySQL或Oracle，常用的資料型別和語法都還支援。這點使用沒什麼問題。需要注意的是在鎖和事務方面。

OceanBase的鎖是行鎖，也有表鎖，但是沒有鎖升級策略。OceanBase的事務都有版本號，類似於Oracle的SCN，讀預設是快照讀，不阻塞寫。OceanBase的事務隔離級別目前只支援讀已提交（RC）。如果要規避不可重複讀問題，則需要在讀上加鎖（支援SELECT 。。。 FOR UPDATE）。

在租戶內，如果事務修改的分割槽跨越節點了，就是

分散式事務

，OceanBase目前也是支援的，原理是兩階段提交，強一致。業務感知不到也不需要知道這個是分散式事務。如果業務事務跨越了租戶邊界，則這種分散式事務需要藉助於分散式事務中介軟體產品解決。

OceanBase針對慢SQL有個超時機制，以防止慢SQL佔用資料庫資源，預設時間是10秒。慢SQL不僅包括查詢慢的SQL，還包括SQL自身效能沒問題但是被阻塞的DML SQL。在MySQL裡對於鎖等待也有超時機制，對於慢SQL也有強制中斷機制（預設沒有啟用）。

OceanBase對於長事務（長時間不提交）採取的是強制超時機制，預設時間是100秒。由於OceanBase沒有UNDO，並且事務未提交之前，Redo都在記憶體裡，所以大事務會佔用一定記憶體資源。

這兩個超時引數都可以調整。調整為很大時效果就等同於不干預，跟Oracle/MySQL就一致了。我們並不建議簡單調大。慢SQL和長事務是業務設計問題，需要業務層面儘可能的解決。

SQL調優

OceanBase的SQL執行設計參照了Oracle的設計，有硬解析、軟解析，有執行計劃快取

。執行計劃目前也很豐富，連線演算法有巢狀迴圈、雜湊、歸併連線、半連線（semi-join）、anti-jon。支援左連線或右連線，子查詢等，支援SQL改寫等等。這塊以後再詳細總結。

檢視執行計劃的命令是explain，這點跟MySQL保持一致（簡潔）。

OceanBase提供一序列內部檢視（gv$檢視或v$檢視）用於診斷效能。這點跟Oracle的效能檢視比較類似。

同時OceanBase還有一個檢視gv$sql_audit擁有叢集執行過的全部SQL，無論SQL是否成功還是失敗。從中可以檢視SQL的執行時間、節點、執行計劃型別、報錯程式碼、執行時間、等待時間、讀取塊數、返回行數、影響行數等等。

更值得一提的是OceanBase也實現了Oracle的Outline功能，能線上干預執行計劃。如調整連線演算法、順序或者索引等。對於那些不可調整的慢SQL，為了消除它的影響，Outline支援對該慢SQL做限流處理。如強制序列執行等。

使用者問題解答

以下是直播過程中對使用者問題的精選和解答：

Q1：分割槽的leader承擔讀寫，follow只是用來容災嗎？

A：預設是這樣的，至少要三副本才可以提供自動故障切換並且不丟資料的能力。如果業務可以接受延時，也可以讀取follower副本以實現讀寫分離效果。

Q2：咱們有OceanBase的培訓教材和推薦書籍嗎？

A：以下是OceanBase的官方學習資料：

1）官方文件：

https：//

tech。antfin。com/product

s/OCEANBASE

；2）官方微信公眾號：OceanBase；3）官方微博：

https：//www。

weibo。com/u/2356115944

。如果是對OceanBase分佈資料庫的原理感興趣的，可以看OceanBase初始團隊成員之一的楊傳輝（花名：日照）的著作

《大規模分散式儲存系統：原理解析與架構實戰》

。本書介紹了OceanBase早期設計的很多原理，關於資料讀寫架構、複製的強一致相關的原理在後續新版本里還是適用的。

Q3：分割槽的標準是什麼？

A：是的。分割槽是水平拆分其中的一種方法，要基於業務場景考慮。詳細分析請檢視《如何挑選最適合業務的資料水平拆分方案？看螞蟻金服分散式資料庫的最佳實踐！》。

Q4：增加節點實現硬體擴容，需要重啟整個叢集嗎？如何把新加入的硬體資源新增到整個叢集？

A：不需要。OceanBase的擴容有叢集擴容和租戶擴容兩種，都是線上進行，對業務無影響。詳情請檢視《揭秘OceanBase的彈性伸縮和負載均衡原理》。

Q5：節點數改變，資料是如何進行資料重分佈？

A：節點數改變後，資源單元Unit會在節點間發生遷移，節點內的資料自然也就重新分佈了。這個是線上自動負載均衡機制。詳情請檢視《揭秘OceanBase的彈性伸縮和負載均衡原理》。

Q6：和mycat相比，應用需要單獨開發的地方多嗎？

A：和mycat相比，相同的地方都是應用需要選擇拆分維度，核心高併發SQL儘可能帶上拆分鍵。不同的是應用不需要關注資料重分佈、分散式事務、擴容縮容等。

Q7：SQL超時後，所說的應用回滾是指應用要捕獲這個超時，然後做補償是嗎？

A：應用需要捕獲資料庫異常，然後自行決定處理邏輯（提交還是回滾）。

● 從0到1手把手教你搭建高可用的OceanBase資料庫叢集

● 如何挑選最適合業務的資料水平拆分方案？看螞蟻金服分散式資料庫的最佳實踐！

● 一文詳解 OceanBase 並行執行引擎實現

● 十年磨一劍！OceanBase查詢最佳化器的設計之道和工程實踐哲學

● 100%自主智慧財產權！螞蟻金服自研資料庫OceanBase的設計與實踐哲學

Tips：想要檢視本次直播回放，你可以關注OceanBase公眾號回覆關鍵詞“0702”獲取回放連結。