OB君：本文是 “OceanBase 2.0 技術解析系列” 的第九篇文章，今天我們來說說2.0版本最不得不提的——Oracle相容模式。本文整理自10月27日OceanBase TechTalk北京站活動中酒滿的演講《OceanBase2.0的Oracle相容模式》。更多精彩歡迎關注OceanBase公衆号持續訂閱本系列内容！
Tips：你可以關注"OceanBase"公衆号，回複“1027”一鍵下載下傳PPT
相信很多人對我們的了解是從OceanBase作為螞蟻金服核心系統的資料庫開始的，也逐漸了解到OceanBase的高可用、高性能等諸多特性。今天我們想通過傳統資料庫的視角來給大家分享OceanBase的另外一個特性——Oracle相容性，希望大家能夠換一個角度了解OceanBase為使用者提供的能力。
Oracle相容模式
今天，真正對資料庫要求比較高的一些行業，像銀行、基金、保險等企業其實到現在為止還沒有完全擺脫對Oracle的依賴。阿裡去IOE比較成功，但我們其實也是經曆一個很長的過程才擺脫了對Oracle的依賴。
一則有趣的新聞
讓我們從一則新聞開始我們今天的分享。這則新聞相信很多朋友前段時間已經注意到了，就是亞馬遜由于使用其自主研發的Aurora PostgreSQL資料庫來替換其内部的Oracle系統，造成了Prime Day促銷日的一個故障。具體的故障分析據說有25頁之多，但是并沒有對外公開。
這裡我們為大家截取了兩句有意思的話：
第一句話來自于亞馬遜工程師——“Oracle和Aurora PostgreSQL是兩種不同的[資料庫]技術，處理“儲存點”（savepoint）的方式不一樣”。僅憑這一句話，我們似乎無法明确肯定問題的根源，但可以肯定的是，故障是由新引入的Aurora PostgreSQL資料庫造成的。
而第二句話就更有意思了，在我個人看來甚至有點強詞奪理——“AWS Aurora是為前瞻性應用軟體設計的，而Oracle是為較傳統的應用軟體設計的”。我覺得這不能稱其為一個理由，更像是一個借口。不能說你的系統做了面向未來的設計就可以忽略當下對使用者的支援和保障，也不能簡單粗暴的把使用者區分為前瞻性的和傳統的，簡而言之，所有使用者的需求都應該被充分重視。
對照上一條新聞，再來看下面一條新聞，相信大家已經不陌生了，就是從去年（2017年）開始，螞蟻金服100%的核心系統都開始運作在OceanBase之上，而且OceanBase作為中國自研的資料庫創造了突破世界紀錄的性能名額。相信大家能夠感覺到我們的團隊做到這一點有多麼的不容易。但在這裡并不是想表達，我們做的就一定比亞馬遜好，其實亞馬遜踩過的坑我們在内部都經曆過。
這裡想說的其實是螞蟻金服之是以能夠成功去掉Oracle，背後是很多人、很多團隊的合作和付出。比如，除了OceanBase以外，我們的使用者也需要配合我們去做應用改造，大家知道我們的産品目前已經高度相容MySQL，但Oracle和MySQL畢竟是兩個資料庫，Oracle使用者需要根據我們的文法和功能（也就是MySQL）做大量的改造。
另外一方面，我們還有全世界最好的資料庫運維團隊，他們也花費了大量的努力去解決由兩種不同的資料庫所帶來的各種各樣的麻煩和問題。總而言之，不管我們性能、穩定性做得如何好，隻要使用者需要從一種資料庫遷移到另外一種資料庫，開發、運維、使用者就要付出大量的努力去解決資料庫差異引入的各種問題，付出很大的代價。這也就解釋了我們今天為什麼要做Oracle相容性——目的很簡單，就是為了最大程度降低使用者的遷移及使用成本，這與優化性能、降低運作成本本質上沒有差別，都是為了提供更大的客戶價值。
經過幾年的去O，我們了解的資料庫相容性從方法論上大緻可以包括以下這麼幾個層次：
- 第一是資料層，原生的資料類型是否100%相容是非常重要的，這裡面有個錯覺——是不是我們的資料類型範圍是Oracle的類型範圍的超集就夠了？其實不然，很多時候使用者依賴這個範圍，去檢查輸入資料的合理性，捕捉錯誤，是以我們必須做到與原生類型完全一緻。
- 第二個是功能，這個很好了解，所有的SQL功能、文法、包括錯誤碼等，都會直接影響到使用者程式的可用性，這裡面需要投入大量細緻的工作，比如，資料長度何時可以截斷、兩種不同的資料類型如何進行比較等等，僅僅通過文檔的描述來實作功能的相容很多時候是不夠的。
- 第三個層面是運維和管理，比如，Oracle有大量的原生字典視圖、包括很多運維指令，能否做到相容影響到DBA的學習成本，同時也會影響到外圍工具的相容性。
- 最後一個層面是核心能力，這一點往往是容易被大家忽略的，覺得我們把使用者遷過來了，業務切流了，就萬事大吉了，其實遠不是這樣，因為如果做不到Oracle産品的性能和穩定性，使用者從使用角度上還是無法做到一樣的體驗，比如一條SQL如果需要手動改寫才能在OceanBase中産生一個合理的執行計劃，那業務的改造還不能完全省去。
這是一張OceanBase支援Oracle相容性的示意圖，可以看到，OceanBase的Oracle相容性模式是租戶級的，也就是說，使用者可以在同一個叢集内同時運作Oracle/MySQL兩種不同類型的租戶，這樣做也是為了進一步降低使用者的部署成本。OceanBase從1.0開始就是雲資料庫架構，支援多租戶間的資源隔離和負載均衡，這些能力在引入Oracle相容模式後都會繼續保留。
那麼，我們是如何用一個資料庫核心來支援兩種不同類型的租戶的呢？上圖給出了示意：在底層（資料層），不同租戶的資料都是按照統一的方式進行存儲的，中繼資料是租戶間隔離的，中繼資料以上，我們定義了MySQL和Oracle兩套不同的展示視圖。
這裡面列舉了一些OceanBase 2.0會支援的部分Oracle相容功能：
- 資料類型：支援number、varchar2、timestamp、CLOB…
- SQL層功能：外連接配接(+)、視窗函數、層次查詢、臨時表、DB link、外鍵
- 事務層：隔離級别、flashback、XA
- 内部視圖：部分字典視圖
- 索引：全局索引、函數索引
- 分區：hash、range、list分區及二級分區組合
- 僞列：rownum、sequence、virtual column等
- 存儲過程：循環、複雜資料類型、cursor、異常
- 用戶端：JDBC、ObProxy、C用戶端
需要指明的是，這個清單還在随着我們收集到的需求而調整，但是幾個重要的功能（接下來我們為大家一一解析），包括全局索引、存儲過程、基礎資料類型等，OceanBase 2.0都一定會支援。
OceanBase 2.0 的新特性
全局索引
全局索引是OceanBase 2.0會釋出的一個重要功能，這個功能也是基于2.0的全局一緻性的特性而實作的。那麼，全局索引解決了哪幾個問題呢？
- 多元度擴充性 ：這個概念不是我們提出來的，簡單來說就是：如果今天你的一張資料表随着資料的快速增長，單機裝不下了，你就需要考慮分布式方案，在OceanBase内部是通過分區表這一功能來實作的。但是，如果沒有全局索引，分區表隻能解決主表的分區和擴充，而主表之外的二級索引就必須被拆分為分區内的局部索引，這樣一來從通路性能和維護上就和之前的索引（其實是全局索引）有很大的不同，而實作了全局索引後，之前的二級索引也可以按照任意的方式進行分區，擴充到多機上，整個擴充性就變成很多元的了。
- 跨分區全局唯一索引：唯一索引要求索引對插入的每條資料保持唯一性，如果沒有全局唯一索引，那麼為了保證唯一性，就會對使用者的分區方式增加很多限定條件。
- 強一緻：全局索引可以保證強一緻性的通路，和使用者自己建立一張全局的資料表作為索引相比，提供更好的一緻性保障。
- 支援更高效的查詢方式：全局索引可以實作真正的全局查找，而不是依賴基于分區鍵的裁剪定位到資料所在的分區，在少量資料通路時，執行的效率更高。
當然，全局索引也有很多難點，比如一緻性的保證，建索引中的異步化考慮等等，是一個實作難度很高的特性。
分區
分區功能是分布式資料庫的一個重要能力，我們在MySQL模式上支援了部分分區方式，這些方式都會以Oracle相容的方式繼續提供支援。另外，我們還新增了list分區，這個對于不同值個數比較小的分區場景有非常重要的意義。另外我們還将提供更多的分區管理功能。分區裁剪的能力也會進一步增強。
Sequence
在OceanBase 2.0中，我們将支援sequence對象的使用。作為分布式資料庫，我們為了避免全局sequence的熱點通路，實作了節點内部的sequence緩存，并通過提前預取sequence範圍等一系列優化手段，確定整個系統的可用性和容錯能力。
DB link
DB link也是Oracle的一項重要功能。基于DB link，使用者可以做跨庫的查詢和事務，OceanBase 2.0将支援OceanBase叢集之間的跨庫通路和跨庫事務。
存儲過程
存儲過程是OceanBase 2.0 Oracle相容性的重要功能。在遷移傳統Oracle使用者的時候，存儲過程一直是橫在所有資料庫廠商面前的攔路虎。當年我在Oracle參加新人教育訓練的時候，PL/SQL組的一位資深工程師就得意的說，“我們每寫一條PL/SQL語句，就在使用者的脖子上加了一根鎖鍊”。
事實也的确如此，存儲過程的代碼往往涉及到很多業務邏輯，幾乎沒有重構的可能。如果不支援，就隻能重寫業務邏輯。而且，存儲過程在很多場景依然有非常大的不可替代性。例如：
如上圖可以看到，互動式的事務處理的超過50%的時間往往消耗在用戶端與資料庫之間的通信或是用戶端的處理時間上，資料庫的性能在這種情況下隻能通過加大用戶端的并發來實作。但是有的場景，簡單的增加并發并不能真正提高性能。例如，如果使用者在事務開始的時候加了一把行鎖，那麼整個事務都将處于該鎖的“臨界區”之内，處理能力直接和事務的延遲有關，這就是典型的“熱點行”問題，而有了存儲過程，事務的邏輯可以完全在資料庫端完成，耗時更短，熱點行的處理能力也就更高。
同時，OceanBase 2.0的存儲過程是基于LLVM編譯執行的，是以在性能上能夠提供極緻的體驗。
用戶端驅動——JDBC driver
在用戶端驅動上，OceanBase的做法是基于MySQL的通訊協定，進行二次擴充，新的擴充協定在繼續支援MySQL協定以外，還将支援Oracle的原生資料類型。
核心全面更新
剛才我們說了，在相容Oracle資料庫上，功能和表現是一方面，性能和穩定性的要求也是重中之重。OceanBase 2.0對資料庫核心進行了全面的更新換代，增加了很多新的功能和特性。
直方圖
直方圖是優化器優化依賴的重要統計資訊的一種。OceanBase 2.0支援了相容Oracle的等高直方圖和頻率直方圖，可以通過自動或者手動的方式進行收集，并自動根據資料的特征選擇合适的采樣率，基于直方圖資訊，我們的優化器将能夠生成更為準确的執行計劃。
自适應計劃比對
在我們的業務中，經常會遇到所謂“大小賬号”問題，即，如果一條查詢是查詢某個商戶的銷售記錄的，那麼查詢某個大商戶時，勢必傳回很多記錄，而一個小商戶的相關記錄可能隻有幾條。
在這種情況下，要求我們使用不同的執行計劃，為了解決這個問題，在OceanBase 2.0中，引入了自适應計劃比對，其目的是處理同一條SQL不同參數時，可以選擇合适的執行計劃。基本思路是：通過條件選擇率的劃分，将整個計劃空間按計劃進行分割，根據入參的選擇率選擇恰當的執行計劃。
計劃演進
執行計劃演進是我們為了確定計劃穩定性而開發的重要功能，其基本思想是通過真實的流量灰階執行新生成的執行計劃，在確定新的計劃滿足預期後才完成新老計劃的替換，這個邏輯大大降低了由優化器自身問題而引入的計劃回退的現象。在Oracle18c的釋出會上，Larry Ellison也介紹了Oracle中的類似功能，從這點上看，我們和Oracle想到一起去了（甚至比他們還更早一些）。
并行查詢優化
并行查詢是OceanBase 2.0引入的全新特性。為了配合整個并行查詢架構的更新，我們對優化器也做了相應的調整和擴充，支援了更多的優化路徑。
Oracle相容性的工作才剛剛開始，OceanBase 2.0可以說是“萬裡長征的第一步”，其實很多相容性的工作到最後拼的都是對細節的掌握和處理。随着基本功能的支援和完善，可以預見，更大的挑戰是在整體的使用者體驗上能否追上甚至超越Oralce。隻有做到了這一點，我們才能充滿自信的說，我們為使用者的平滑遷移鋪平了道路。