正文共：6477 字 7 圖

閱讀時間： 7 分鐘

本文根據DBAplus社群（微信公眾號：DBAplus）第144期線上分享整理而成，圍繞資料庫、大資料、PaaS雲，頂級大咖、技術乾貨，每天精品原創文章推送，每週線上技術分享，每月線下技術沙龍，受眾20W+，是運維圈專注圍繞“資料”的學習交流和專業社群！

十多年的資料庫行業從業人員，曾先後在神舟軟體公司、神舟通用公司從事國產資料庫研發和推廣工作，作為核心成員參與多個國家級資料庫專案。2014年加入螞蟻金服OceanBase團隊，負責SQL引擎開發。

本文熱度：★★

深度閱讀前，中生代君邀您先思考以下問題：

• OceanBase與傳統的資料庫有哪些不同？

• 如何解決高可用問題？

• 擴充套件性如何保證？

各位關心OceanBase資料庫的同學，大家好！我是OceanBase團隊的蔣志勇。借DBAplus社群直播平臺，和大家聊一聊近八年來OceanBase的發展以及關鍵特性。

一、發展歷程

OceanBase資料庫是阿里巴巴和螞蟻金服完全自主研發的金融級分散式關係資料庫系統，和基於開源資料庫產品進行改造的解決方案不同的是：OceanBase核心100多萬行程式碼都是我們的同學一行行寫出來的，所以我們對其有完全的掌控力，這一點對OceanBase的持續發展以及獲得更廣泛的應用有著十分重要的意義。

從2010年立項開始算起的八年時間裡，OceanBase版本號也從0.1版本升到即將推出的2.0版本。從最初的Key－Value儲存系統發展到現在功能齊備的關係資料庫系統。整個過程中，我們始終不變的初心就是服務業務，解決業務實際問題，不斷增強產品能力，然後更好地服務業務。

遵循“解決問題→發展產品→解決更大的問題→鍛煉出更好的產品”這個迴圈：

• OceanBase從解決收藏夾的海量資料儲存問題入手，有了一個小團隊並活了下來；

• 為了解決高可用的問題，採用三叢集部署方式；

• 為了降低業務遷移成本及支援分析型應用，增加了SQL功能；

• 到目前的全對等架構、三地五中心城市級自動容災（可參考：）、支援主流關係資料庫功能使得業務零修改遷移，最終使得支付寶核心業務能夠執行在OceanBase上。

OceanBase從立項開始，目標之一就是在不可靠的硬體上提供可靠的關係資料庫服務。我們誕生於高速發展的網際網路行業，高階儲存和專用伺服器的訂貨週期太長，供應也很受限。能方便獲取的硬體只有普通PC伺服器，所以OceanBase只能依靠分散式架構，用軟體的手段，在不可靠的硬體環境中實現金融級可靠性及資料一致性。

經過八年多的實踐，從淘寶的收藏夾業務走到今天支撐支付寶所有核心業務，並且在每年的“雙十一”持續地創造交易資料庫峰值處理能力的世界紀錄。在去年“雙十一”大促中支撐了支付寶全部的核心業務（含交易、支付、會員、賬務），峰值處理請求數達到4200萬次每秒。

二、關鍵特性的逐步實現

從特性上說，OceanBase具備線性擴充套件、高可用、高效能、低成本，以及和主流關係資料庫產品高度相容等特點。

從1.0版本開始，OceanBase架構就進化成為全對等節點，無共享儲存方式。這個架構特點消除了單點，每個節點都具有完備處理能力，能夠管理本節點上的資料。在節點角色上，有幾個節點（root service）負責管理叢集拓撲結構等全域性資訊，相對特殊一點，但每個節點都具備承擔這個角色的能力，如果當前承擔該角色的節點發生故障，叢集會自動選舉出新的節點承擔這個角色。

此外，為了高可用，叢集節點分佈在多個不同的可用區，可以是同城不同機房，或者異地多個機房；一份資料在多個可用區裡有副本，副本個數通常是奇數個。在螞蟻金服的實踐中，通常是3個或者5個，少數副本故障不影響系統可用性。

百萬級QPS前端代理

在OceanBase叢集之上，我們提供一個反向代理OBProxy。看到這個，大家可能會聯想到基於中介軟體構建的MySQL叢集，但這兩者是有本質區別的：簡單地說，沒有OBProxy，OceanBase叢集一樣能夠工作，具備完整處理能力。

那我們為什麼要有OBProxy呢？主要出於兩方面的考慮：

• 一個是效能，通過OBProxy的路由功能，可以比較準確地將語句路由到合適的節點處理，減少叢集內部轉發；

• 另外一個是容錯能力，在網路發生閃斷情況下，OBProxy可以重建連線，讓業務無感知。

分散式架構對業務透明

對業務來說，OceanBase分散式架構能做到的最好狀態是什麼呢？我認為是對業務透明。通過分散式架構，我們做到高可用、做到可擴充套件，但是對業務系統，要做到透明，表現為一個單節點資料庫，體現在如下幾點：

• 業務無需關心資料庫物件的物理位置。業務連上OBProxy或者任何一個OB節點，就能看到完整的檢視，能訪問所有它有許可權訪問的資料。

• 叢集SQL功能集等同於單節點SQL功能集。採用標準SQL語法，並且不因為資料分佈影響SQL功能。當前版本大部分功能都做到了資料位置無關，但還有少數功能受位置影響，比如我們不支援在一條DML語句中修改多個節點的資料。在即將釋出的2.0版本中，這些問題都會得到解決。

• 完整支援事務ACID特性，統一事務操作介面。業務無需區分分散式事務和單機事務，資料庫內部會對不同的場景進行區分並做相應的優化。

• 自動處理分散式環境故障、做到業務無感知。通過OBServer 和OBProxy的重試機制，可以做到大多數環境故障對業務透明，但相對於之前建立在高可靠硬體上的單機系統，還有一些差異，個別場景異常需要業務處理。

在滿足業務高速發展的過程中，OceanBase資料庫要解決的首要問題就是擴充套件性問題。

通過全對等節點架構，我們消除了之前版本單點寫入瓶頸。業務對資料庫的要求是不停服務，永遠線上，為此所有的操作都要是線上的。傳統的垂直擴充套件的方式不行了，只能採用水平擴容的方式。這從方法上看也很直觀，怎麼做呢？分三步走：

在叢集中增加節點→讓新節點具備服務能力→將一部分負載分發到新節點上

看起來，似乎和將大象裝進冰箱一樣，步驟明確。但每一步都不是那麼好做的。

因為OceanBase是無共享儲存的，要想新增加的節點能夠分擔負載，新節點上先要有資料。最難的是此過程中既要保證資料一致性，又要不影響業務。無論是機房擴容（機房內新增機器）還是擴充套件到新機房（很有可能是異地或公有云場景），我們都必須做到線上。在OceanBase的實現中，主要依賴如下幾點：

• 多副本機制。多副本不僅是高可用的基礎，也是線上擴容的基礎。從本質上來看，擴容無外乎兩種：一種是將新資料寫入到新節點，後續對該部分資料的讀寫也在新節點；另一種是將現節點上的部分資料移動到新節點並在新節點提供服務。

  第一種情況容易處理；第二種情況就需要利用多副本機制，簡單地理解就是把其中的一個副本從原節點遷移到新節點，說起來簡單，做起來有很多的細節要考慮，比如在異地增加一個副本，怎麼樣做到既能高效地遷移資料同時又不影響現有服務。

• 細粒度的主備關係。傳統的主備大多數是節點級的，由於一個節點上儲存的資料量較大，主備切換的影響很大。在OceanBase中，主備關係的粒度是分割槽級的，這是一個很細的粒度，切換對業務的影響比較小，並且切換是秒級的。

• 位置資訊自動重新整理。在擴容引起分割槽位置變化後，在第一次訪問原位置時，系統會檢測到變化，並且重新整理位置資訊來進行重試，執行成功後向客戶端返回正確的結果。除OBServer端以外，OBProxy也會根據服務端的反饋來更新自己保留的位置資訊，後續的訪問就會被直接路由到正確的節點而無需叢集內部轉發。

擴容是線上的，縮容也是如此。

高可用是OceanBase資料庫安身立命的根本，以下三篇文章對此進行了詳細的描述：

它們包括了“OceanBase和傳統資料庫的差異，以及，在選舉協議上為什麼我們選擇Paxos協議而不是更容易理解的Raft協議？”等內容。在這裡簡短總結如下：

• 傳統資料庫高可用依賴專用硬體，而OceanBase是在普通商業硬體上實現高可用。

• 傳統資料庫在故障發生時缺乏仲裁機制，需要人在不丟資料和不停服務之間做選擇；OceanBase基於Paxos協議在少數派副本故障情況下可以自動恢復，不丟資料（RPO＝0），不停服務（受影響分割槽RTO小於30秒）。

• 採用Paxos協議而不是Raft協議的原因在於Raft協議要求日誌確認必須是順序的，如果前面的某條日誌因為種種原因沒有得到確認，後面的日誌也都不能確認。這會造成一個嚴重後果，使得在業務邏輯層面不互相依賴的操作產生了互相依賴，對系統吞吐率有非常大的影響。尤其在高負載的時候。這種依賴是業務開發人員和DBA無法預測和規避的，發生的時候也無法有效解決。

除了異常情況下的可用性，系統升級、DDL變更等計劃中的操作也不能影響系統可用性。我們通過逐個Zone升級的方式，實現升級過程的可灰度、可回滾；同時通過多個Zone之間的資料一致性校驗來驗證新升級系統的正確性。

通過實現多版本的資料庫物件定義，我們實現了DDL操作和查詢、更新操作互相不等待。針對多版本的資料庫物件定義，多補充一句，DDL操作對資料庫物件的影響保證能被對於同一個使用者Session後續的操作看到，哪怕這個使用者Session對應的是OBProxy到叢集不同伺服器的多個Session。

高效能不僅僅意味著服務能力強，也意味著成本降低，在相同硬體條件下可以支撐規模更大的業務。OceanBase通過讀寫分離架構（LSM tree），將更新暫存在記憶體中，並且在記憶體中維護兩種型別的索引：Hash索引和B＋樹索引，分別用來加速主鍵查詢和索引範圍查詢，達到準記憶體資料庫的效能。

和傳統資料庫不同的是：更新操作不是原地進行的，沒有傳統資料庫的寫入放大問題，對於一般規模的系統，記憶體可以放下一天的增量。在系統高負載執行的時候，幾乎沒有資料檔案寫，這會大大減少IO；在系統負載輕的時候，將記憶體增量批量合併到持久化儲存上。

除了讀寫分離架構帶來的效能提升外，我們在整個執行鏈路上做了不少優化，主要包括如下幾類：

• Cache機制。在資料層面有行快取和資料塊快取，對於經常訪問的資料，IO讀大大降低了；在SQL引擎層，有執行計劃快取。

• JIT編譯執行。在表示式計算及儲存執行過程中，都支援編譯執行，大大加速了大量資料行的計算。

• 自適應能力。SQL引擎會根據語句操作資料的分佈情況選擇採用本地、遠端、分散式執行，並基於代價選擇合適的計劃。在分散式執行的情況下，根據代價計算儘量將計算下降到節點。事務層會盡量採用本地事務，減少分散式事務以提升效能。

• 共享工作執行緒以及非同步化。和傳統資料庫不同的是，OceanBase沒有采用專有工作執行緒方式，工作執行緒多Session共享。此外，在語句執行過程以及事務提交時，多處採用非同步化操作，最大限度地減少了無謂等待，充分利用CPU。

除上述情況以外，我們還做了很多細緻的工作。整體來看效果非常明顯：2017年“雙十一”峰值4200萬次操作每秒，使用者體驗相當順滑，系統表現很平穩。

OceanBase一方面需要滿足業務對資料庫的要求，另一方面也要節約成本，不僅僅是運營成本，還包括業務遷移和人員學習成本。

OceanBase的成本優勢主要來自以下三點：

• 通過執行路徑效能提升降低計算成本；

• 通過讀寫分離架構優勢降低儲存成本，一個真實的案例是某內部業務從Oracle遷移到OceanBase，原先的100TB縮小到30幾個TB。因為OceanBase中可以採用壓縮比更高的壓縮演算法，而在Oracle中，由於是原地更新要兼顧效能，沒法採用消耗CPU過多的高壓縮比壓縮演算法；

• 通過多租戶架構，不同負載型別的業務通過多租戶方式混合部署，能更加充分地利用了機器資源（可參考：多租戶機制概述）。從實際應用來看，採用OceanBase資料庫的金融業務，單賬戶成本只有原先的1/5到1/10。

以上的幾個特點使得OceanBase具有競爭優勢，但要將業務真正從原系統遷移到OceanBase還需要一個額外的特性——相容性。高相容性使得系統遷移能在可控的成本下進行。

對公司內部MySQL業務，OceanBase能做到業務零修改遷移。可以這麼說，主流關係資料庫具備的常用功能OceanBase都具備了。不僅是在語法層面，而且是在使用者體驗和業務體驗上完全一致。

從2017年開始，OceanBase開始服務外部客戶，我們發現相容性做得還不夠，還需要再上一層樓：不僅常用功能要相容，更要全面相容；不僅是要相容MySQL，還要相容商業資料庫。只有這樣，才能使得外部業務具備零修改遷移OceanBase的可能性。這些工作正是我們目前在做的。

三、未來展望

接下來，OceanBase 2.0版本即將釋出，屆時也會在DBAplus社群進行新特性的技術分享。這個全新的版本在分散式能力和SQL功能上相對於1.X版本都有質的提升，我們也真誠希望，OceanBase 2.0能夠讓分散式架構對業務透明、讓業務更方便地獲得更好的資料庫服務。

Q1：請問OceanBase支援多表Join、分組、視窗函式等複雜查詢嗎？

答：支援。

Q2：Paxos是保證多副本一致性嗎？

答：是的。

Q3：OceanBase查詢優化器和Oracle相比如何?有沒有像Oracle執行計劃變更造成SQL效能下降的問題？

答：優化器相對於Oracle還有差距，也需要解決穩定性問題。

Q4：是每個Zone上的資料是不同的、每個Zone上有三副本麼？

答：通常每個Zone資料是相同的，一份資料在各個Zone都有一個副本。

Q5：OceanBase多副本，副本間如何高效同步，又如何保持從多副本讀寫效率的高效呢？

答：對於強一致讀，只能讀主。

Q6：DDL如何實現線上？

答：多版本Schema。

Q7：如果查詢設計多個表，而所分配的MergeServer快取的子表資訊不全，是否需要通過請求多個MergeServer共同完成？

答：在1.0以後，沒有MergeServer了，都是全對等節點。涉及多個節點的查詢會生成分散式計劃。

Q8：跨區域的資料是實時同步嗎?

答：取決於副本的分佈和網路延遲。

Q9：請問阿里在雙十一這種活動場景下，對超熱點資料有什麼特別的優化？比其他主流資料庫的效能如何呢？

答：比如說提前解行鎖，效能能滿足大促要求。

Q10：如果在獲取ChunkServer資料的過程中MergeServer掛了怎麼辦？

答：現在沒這些角色區分了，如果節點故障，會重試。

Q11：OceanBase你說的Zone是Shard分片的意思麼？

答：Zone是可用區的意思，你可以理解成一個子叢集。

Q12：OceanBase是否對OLAP和OLTP系統是否由使用者選擇不同的儲存引擎，還是同一個引擎支援？

答：一種儲存引擎。

Q13：OceanBase沒有Shard的功能對麼？那麼提供高可用、城市級容災、線上擴容，記得你說資料可能不在同一個節點，那就是資料分片了嗎？

答：資料是分片的，分片的規則由使用者來定，類似於Oracle的分割槽。

Q14：多副本下怎麼保證每次讀取的是最新或是滿足一致性的資料?讀取也走一次Paxos Instance?

答：強一致性讀只讀主副本。

Q15：多副本之間是如何複製的？物理日誌？邏輯日誌？還是其他方法？

答：物理日誌。

https://m.qlchat.com/live/channel/channelPage/2000000411799213.htm

近期熱文

↓↓↓點這裡觀看本期分享回放