小螞蟻說：

9月21日下午，在雲棲大會ATEC數字金融架構轉型分論壇中，螞蟻金服OceanBase團隊的資深技術專家蔣志勇正式宣佈OceanBase 2.0重磅發佈！併為我們深入解讀了OceanBase 2.0的產品新特性和重大技術突破點。下面小編就帶大家一起來看看OceanBase的前世今生以及本次發佈的精華內容。

前言

OceanBase是一款完全自主研發的金融級分佈式關係數據庫，超過100萬行的核心代碼都由OceanBase團隊的同學一行行敲出來。

從2010年立項到今天，過了8年；在最近4年多時間裡，一直服務於金融核心業務。2014年，OceanBase開啟了支付寶核心業務去Oracle的進程，在當年的“雙十一”，支撐了10%的交易流量；最終在2017年，成功完成支付寶交易、支付、賬務、會員等全部核心業務的去Oracle的工作。這在中國乃至全球都是一個標誌性的事件。

對比一下美國的情況，前段時間有報道稱亞馬遜準備在2020年徹底去除對Oracle數據庫的依賴，立刻引來了Oracle創始人的反擊，他表示亞馬遜已經嘗試過很多次，但從未成功，足以見得去Oracle這件事對於企業而言的難度之大。

同樣在2017年，OceanBase和螞蟻金融科技的其他產品一起幫助南京銀行建立了互聯網金融核心系統。從去年開始截止到今天，OceanBase已經在6家外部金融機構上線，包括商業銀行和保險機構。全球前三名的支付平臺，兩家的核心繫統都在使用OceanBase數據庫。

為了滿足業務快速發展以及持續可用的要求，系統架構從集中式轉向分佈式是大勢所趨。在數據庫層面，要相應地從單機數據庫轉向分佈式數據庫。

OceanBase 2.0版本發佈

今天，我們發佈OceanBase 2.0版本，這是OceanBase數據庫自身發展的里程碑，也是我們參與金融行業向分佈式架構轉型的關鍵一步，用數據庫技術創新為業務架構轉型奠定基礎，解除行業發展的後顧之憂。

在架構轉型過程中，技術決策者往往會碰到三大挑戰：

第一大挑戰：技術風險

第一個是技術風險，傳統單機數據庫系統經過幾十年的發展，運行在可靠的專用硬件和存儲上，在金融行業得到充分鍛鍊，整體穩定。分佈式數據庫系統運行在普通商業硬件上，採用廉價存儲，運行環境和傳統方式有很大差異，保證系統可用性和可靠性的手段也大不相同；同時在某些基本行為方面和傳統單機數據庫也有差異。比如要獲取一個系統一致性快照，對單機數據庫是一件很輕鬆的事情，但在分佈式系統中，卻沒那麼容易。如果不能提供一致性快照，業務系統就被迫要做相應的改造和調整，調整就會帶來風險。可以說：對於一些基本特性，分佈式數據庫系統相對於傳統數據庫的每一個行為上的差異都增加了架構轉型的不確定性，很有可能就是在轉型的道路上埋了一個雷。

第二大挑戰：遷移實施成本

傳統數據庫是功能的集大成者，分佈式數據庫由於發展時間較短以及分佈式架構自身的複雜性，在功能上比傳統數據庫有所欠缺。如果缺少的正是業務系統需要的功能，往往就要通過修改業務系統來解決。除了系統改造成本，還有運維成本，人員知識結構更新帶來的成本，等等。

第三大挑戰：新產品的質量和服務

最後一點是新產品的質量和服務能否滿足金融業務的要求。數據庫產品和其他產品的重要差異在於它關乎企業的核心數據資產。數據庫新產品的質量不能僅僅依靠測試報告來保證，而是要看有沒有經過實際業務的長期鍛鍊。對於應用過程中出現的任何問題，技術研發和服務團隊有沒有能力限期解決。

上述的三個問題，是技術決策者需要思考和解決的。

OceanBase 2.0的發佈，在一定程度上就是為了解決上面的三個問題，減輕技術決策者的決策風險。今天的報告分成如下六個部分，分別介紹OceanBase2.0在減少分佈式架構對業務的影響、提高數據可用性、增強運維能力、提升性價比和產品兼容性方面的進展，最後還會談一談2.0版本在今年“雙十一”大促中將要承擔的任務。

業務透明的分佈式系統

對分佈式數據庫而言，如果對業務能表現成一個具備動態伸縮能力、功能完備的高可用單機數據庫，那基本上就達到了向業務屏蔽分佈式架構複雜性的目標。把分佈式架構實現的複雜性留給了自己，把便利性提供給了業務。為了這個目標，OceanBase 2.0版本實現了全局一致性快照，支持了全局索引，豐富了負載均衡策略。

1. OceanBase的整體架構

先來看一下OceanBase的架構，從1.0版本就確立下來的對等節點無共享存儲分佈式架構。集群中的每一個節點都是對等的，包含完備的SQL、事務、存儲引擎，負責管理一部分分區，並響應客戶端的請求。

在所有的節點中，有部分節點承擔了集群全局性的管理功能，圖例中的Root Service節點，略微有點特殊，但是這個管理能力是其他節點都具備的，在必要的時候可以隨時接管。

為了高可用，數據通常有多個副本，分佈在不同的可用區，圖例中部署有三個可用區，單節點故障、單可用區故障都不會影響系統和數據的可用性。在9月20日ATEC主論壇中演示的“三地五中心”高可用架構，在發生城市級故障的時候數據不丟失，26秒恢復業務，用的數據庫就是OceanBase。OceanBase也是雲數據庫，單個集群服務多個租戶，租戶之間數據和資源隔離。

2. 全局一致性快照

在沒有實現全局一致性快照之前，分佈式數據庫在功能上是有比較大的欠缺的。有兩個典型問題：一個是無法實現跨節點的一致性讀，另一個是無法保證因果序。

無法實現跨節點的一致性讀，對於應用系統設計和開發人員是很有挑戰的，他們得保證在一條SQL語句中訪問的多個表、多個分區都在同一個節點上，否則這個查詢就會出錯。

無法保證因果序的一個表現是：用戶在兩個事務中分別修改了位於兩個節點上的兩張表，先修改了源表，再改了目的表。但在另外的一個觀察者看來：後修改的表已經在查詢中反映出來了，但源表還沒有變。這對於依賴操作順序的業務系統，簡直是個災難。

OceanBase 2.0版本實現的全局一致性快照，從根本上解決了這些問題。相對於Google Truetime基於原子鐘的硬件實現，OceanBase的全局時間戳（GTS）服務是純軟件實現的。不依賴特定的硬件設備，也不對客戶方的部署環境提額外的要求，使得OceanBase能夠服務更廣泛的專有云客戶。

全局時間戳（GTS）服務是系統的基礎服務，該服務的性能和可用性對系統有很大的影響。OceanBase 2.0的單個全局時間戳服務1秒鐘內能夠響應2百萬次以上的時間戳獲取請求，滿足單租戶百萬級TPS的要求。在系統滿負荷運行的情況下，對性能的影響不超過5%。時間戳服務的高可用機制和數據分區高可用機制相同，後者在過去幾年中經歷了支付寶生產系統嚴苛的檢驗，非常穩定。

2.0版本的全局時間戳服務缺省打開，跨節點讀寫、因果序的行為和單機數據庫完全一致。對於數據都集中在一臺機器上的小租戶，或者對性能有極致要求的租戶，可以選擇關閉自己的全局時間戳服務。

3. 全局索引

全局索引是單機數據庫的常用功能，在分佈式數據庫中比較難實現。對於分區表來說，全局索引的價值在於為不帶分區鍵條件的查詢提供一種性能提升手段。在沒有全局索引的時候，不帶分區鍵條件的查詢性能是比較差的，要在每一個分區上做一遍這個查詢，而大部分分區上根本沒有滿足條件的記錄。

我們看到，有些業務不能接受這麼長的查詢響應時間，就會創建另外一張表來模擬全局索引的功能，這個額外創建的表的維護就會帶來很多問題，數據一致性、以及在何種情況下使用這個表都需要應用系統去管理。

全局索引功能將業務從這些問題中解脫出來。在全局索引的創建和使用上，OceanBase都基於代價做選擇，在創建的時候，可以基於基本表，也可以基於另外一個索引。大表的索引創建通常耗時較長，對於大規模的分佈式系統，設備故障也並不少見，為了提高創建索引成功率，在發生錯誤的時候採用子任務級別的重試。

對於查詢優化器來說，何時採用哪一個全局索引也是基於代價計算的，目前索引回表查詢是通過在計劃上生成基礎表和全局索引表的連接操作來實現的，代價模型也和一般查詢相同。對有全局索引表的DML和查詢操作很容易產生分佈式查詢和分佈式事務，為了提升性能，在實現上做了很多細節優化，比如對於分佈式查詢，將任務的粒度從之前的分區級提升到節點級，以便減少RPC的次數。

4. 負載均衡

在負載均衡方面，2.0版本豐富了均衡策略。租戶內的負載均衡讓該租戶上的工作負載能比較平均地分配在租戶的多個節點上，對於數據裝載和分析型的查詢，可以有效地減少響應時間。此外，還可以設置租戶間的親和關係，實現將負載高峰出現時段相同的租戶分佈在不同節點上，峰值時段不同的租戶分佈在同一個節點上，充分地利用系統資源。除了提供給用戶可配置的手段，負載均衡還結合CPU、Mem、存儲等資源的使用情況，在負載差異超過閾值的時候，自動平衡節點間的負載，簡化運維操作。

數據持續可用

在9月20日下午螞蟻金服副CTO胡喜的主題演講中，演示了OceanBase三地五中心城市級故障無損容災方案，樹立了金融核心業務高可用新標杆。

這一場三地五中心方案的現場演示是我們1.4版本支持的特性。在提升數據可用性方面，2.0版本也有了顯著改進，索引實時生效、閃回查詢、在線分區分裂，這三個新特性，每一個都解決了業務使用中的痛點。

1. 索引實時生效

瞭解OceanBase之前版本的同學都知道，索引生效和每日合併是強綁定的，普通索引的生效要經過一次每日合併，唯一索引要經過兩次。有的時候，索引創建失敗了，業務還不知道，造成了很大的困擾。

在2.0版本中，索引創建和每日合併解耦，索引基於數據的一個全局快照創建，再合併後續的變更，創建成功即可使用。如果出現錯誤，也能及時給用戶反饋，提升了用戶體驗。通過先在一個數據副本上創建索引，成功以後再通過複製的方式生成其他的副本，避免同時在多個副本上創建索引造成的系統資源浪費。支持創建全局唯一索引，進行全局唯一性檢查；在數據一致性校驗方面，和之前的版本一樣，會檢查索引和表中的相同列的一致性。

2. 閃回查詢

閃回查詢功能，可以指定查詢某個歷史時間點的數據，對減少用戶誤操作造成的影響很有幫助。假如用戶不小心刪除了一些有價值的數據，可以通過指定刪除之前的時間點來查詢之前的數據。

在OceanBase的實現中，內存中的修改記錄原本就是多版本的。為了支持閃回查詢，要求轉儲到外存中的數據也要保留多個版本。至於保留多長時間範圍內的版本，用戶可以根據自己的需要進行配置，每一個表都可以按需單獨配置。為了減少多版本轉儲對存儲的壓力，存儲層也將數據編碼和通用壓縮應用在轉儲上，有效地減少存儲消耗。同時，在執行查詢語句時，如果指定了快照版本號，查詢也可以在從副本執行，分擔主副本節點的壓力。

3. 在線分區分裂

另外一個提高數據可用性的功能是在線分區分裂，該功能對系統擴容很有幫助。在業務早期設計表的時候，對未來的增量很有可能預估不足，所以業務發展起來以後，就需要把單個分區再拆分，分成多個分區，再用多臺服務器來服務這些分裂出來的分區，達到系統擴容的目的。

如果需要拆表的業務不能停服務，拆分操作就需要在線完成。在2.0版本中，分區分裂分成兩個步驟，邏輯拆分和物理拆分，邏輯拆分是在表模式上把單個分區變成多個分區，完成表的元信息更新。物理拆分是把原先單個分區中的數據移動到新生成的分區中去。邏輯拆分在用戶的DDL語句返回的時候就完成了，物理拆分是後臺運行的。在物理拆分沒有最終完成前，仍然會用到之前分區的數據。

在分區分裂的過程中，也控制了存儲空間的使用，舊分區某一個宏塊的數據全部被轉移到新分區了，該宏塊空間就被回收了。

在分佈式系統中，分區大小對負載均衡、副本遷移、複製都有影響，把分區控制在較小的規格是有價值的。在線下OceanBase 2.0測試集群中，單個節點能夠服務百萬個分區；線上生產系統單節點服務十萬個分區。滿足分區拆分以及雲環境下對單節點分區服務能力的要求。

可運維性增強

分佈式數據庫相對於單機數據庫，無論是部署還是運維都要複雜一些，所以提高系統的可運維性也是2.0版本的一個重要目標。今天主要講三個方面：DB Replay功能、在線升級以及新運維管控平臺OCP2.0。

1. DB Replay

DB Replay是一個很有用的功能，一方面可以降低系統升級的風險，另一方面也可以用來做壓測，保障大促。DB Replay主要分成三個部分：線上流量抓取，要求不能影響線上系統的服務能力；第二部分是流量分析，因為真實系統的流量非常大，抓取的數據量也很大，對分析的性能要求高，同時為了更接近抓取時的Session併發情況，在併發語句相關性分析上，粒度是行級而不是同類產品通常採用的表級；第三個部分是流量回放，保持和線上系統同樣的會話之間的關係，並且可以通過調整語句之間的時間間隔來放大或者縮小對系統的壓力，達到壓測的目的。

2. 在線升級

作為長期支持核心業務的數據庫系統，對升級的要求就是平滑、可灰度、可回滾。版本之間的數據格式是兼容的，新版本的程序能理解老版本的數據。同時通過可用區輪轉升級，可以做到在線升級；在升級的過程中可以灰度切流驗證，在出現異常的情況下可以回滾，不會對系統造成嚴重影響。

3. 新版雲管控平臺

數據庫運維管理一直就不是一件容易的事情，對於分佈式數據庫更是如此。“工欲善其事、必先利其器”。OCP（Open Cloud Platform）2.0就是一款專門用來管理OceanBase數據庫集群的管控平臺，通過OCP平臺，可以一鍵安裝、部署、升級OceanBase集群，監控集群的運行狀態，創建和維護運維任務。

相對於1.0版本，2.0版本進行了架構上的改造，提升了服務的可用性，去除了對HBase、JStorm等外部組件的依賴，減少了最小化部署對服務器資源的消耗，從原先的3臺物理服務器到2個Docker，非常適合對成本敏感的專有云客戶。同時提供SDK供第三方定製管控平臺。在服務能力方面，OCP集群能夠動態擴展，每秒能夠響應百萬次的http請求，充分滿足運維需要。

性價比提升

針對性能，我們主要做了兩方面的工作：提交協議的優化和工程實現層面的優化。提交協議優化指的是對分佈式事務二階段提交協議的優化，在這一方面，目前在申請相關的專利，這裡暫時不展開。在工程實現優化方面，我們做了大量細緻的工作，包括內存分配、臨界區、數據類型轉換等。在降低存儲成本方面，通過對靜態數據進行編碼，有效地減少了存儲使用。通過這一系列的改進，

兼容性提升

最後說說2.0版本的兼容性，我們花很大的力氣做兼容性，就是要減少數據庫遷移造成的業務系統改造，降低遷移成本，同時使得業務數據庫設計人員、開發人員、數據庫管理員原先積累的知識和經驗能夠在新系統中複用。

1. 兩種兼容模式

在1.x版本中，我們主要做的是MySQL兼容。2.0版本支持兩種兼容模式：MySQL和Oracle，目前Oracle兼容還比較有限，不久之後會有一個顯著的提升。同一個集群中的多個租戶，可以採用不同的兼容模式，在租戶創建的時候指定，後續不能更改。對兼容性的要求，不僅僅是語法層面的兼容，還有語義方面、異常情況下的行為、併發行為、甚至於性能，都可以看作兼容性表現的一部分。

試想一下，同樣的語句，新系統的響應時間是原系統的10倍，哪怕是語法兼容做得再好，也根本無法滿足業務要求，又有什麼用呢？

2. 存儲過程功能

在功能方面，2.0版本實現了一個標誌性新特性—存儲過程。我們實現存儲過程，有兩個方面的目的：一個是兼容性，我們瞭解到，在傳統行業中還是有不少系統是基於存儲過程實現的。通過支持存儲過程可以顯著降低這部分系統的遷移成本。另外一個是高可用，通過使用存儲過程，可以顯著減少業務系統和數據庫服務器之間的交互，如果業務流程的幾十條、幾百條SQL語句通過一個存儲過程來實現，即便出現跨城的業務對數據庫的調用，也不會對用戶體驗有明顯的影響，系統的容災將會更容易實現，穩定性也會更高。在為數不多的原生分佈式數據庫產品中，OceanBase是第一款支持存儲過程功能的。

存儲過程也支持MySQL、Oracle兩種模式。如果業務不想讓數據庫來管理代碼，也可以採用匿名塊的使用方式，既有開發靈活性，又能獲得存儲過程帶來的好處。存儲過程採用LLVM編譯執行，效率比解釋執行高；支持基本調試功能，方便對大規模存儲過程的開發和調試。

OceanBase 2.0的第一個“雙十一”

作為阿里系的產品，不經過“雙十一”的考驗是不完整的。今年是天貓的第十個“雙十一”，也是OceanBase 2.0經歷的第一個“雙十一”。

雖然剛剛出道，也要堪當大任。2.0版本將要承擔一大部分支付寶的核心業務，同時，藉助於2.0的在線分區分裂技術和全局索引功能，業務核心表要實現拆分，從非分區表拆成若干個分區表。

今年大促的峰值流量預計會大幅增加，但數據庫服務器的成本不能增加，要靠提升數據庫性能來幫助實現“零新增成本大促”這個目標。

聽到這裡，大家應該明白了，2.0版本所做的技術創新和產品改進，都來自於業務的真實需求，也會很快接受業務的檢驗。這是推動OceanBase數據庫不斷向前發展的原動力，也是OceanBase區別與市場同類產品的最大不同。我們輸出到外部市場的產品都是經過內部業務嚴格檢驗過的，每年的“雙十一”大促都是對OceanBase數據庫獨一無二的壓力測試。

最後，以OceanBase 2.0相關的幾個數字來作為結尾：

“1”

第一個支持存儲過程的原生分佈式數據庫系統

“30｜50”

存儲減少30%，性能提升50%

“100萬”

單臺服務器的分區服務能力達到100萬個

“200萬”

單個租戶GTS服務能力達到每秒200萬次

OceanBase 2.0技術交流群

想了解更多 OceanBase 2.0 特性？

想與螞蟻金服OceanBase的一線技術專家深入交流？

掃描下方二維碼聯繫螞蟻金服加群小助手，快速加入OceanBase技術交流群！

— END —

螞蟻金服官方唯一對外技術傳播渠道

投稿郵箱：[email protected]

閱讀更多 螞蟻金服科技 的文章

關鍵字: 軟件 TPS遊戲 小螞蟻