OceanBase 2.0 釋出，全面降低金融業務向分布式架構轉型技術風險

小螞蟻說：

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請求，充分滿足運維需要。

成本效益提升

針對性能，我們主要做了兩方面的工作：送出協定的優化和工程實作層面的優化。送出協定優化指的是對分布式事務二階段送出協定的優化，在這一方面，目前在申請相關的專利，這裡暫時不展開。在工程實作優化方面，我們做了大量細緻的工作，包括記憶體配置設定、臨界區、資料類型轉換等。在降低存儲成本方面，通過對靜态資料進行編碼，有效地減少了存儲使用。通過這一系列的改進，在OLTP場景的實際應用中，2.0版本相對于1.4版本，性能提升了50%以上，存儲下降30%。

相容性提升

最後說說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]

歡迎留言及個人轉發，媒體轉載請聯系授權