各位關心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能夠讓分布式架構對業務透明、讓業務更友善地獲得更好的資料庫服務。
Q&AQ1：請問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：多副本之間是如何複制的？實體日志？邏輯日志？還是其他方法？
答：實體日志。
原文釋出時間為：2018-05-9
本文作者：蔣志勇
本文來自雲栖社群合作夥伴“
中生代技術”，了解相關資訊可以關注“
”。