各位關心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集群架構特點
從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的重試機制，可以做到大多數環境故障對業務透明，但相對於之前建立在高可靠硬件上的單機系統，還有一些差異，個別場景異常需要業務處理。
2線性拓展
在滿足業務高速發展的過程中，OceanBase數據庫要解決的首要問題就是擴展性問題。
通過全對等節點架構，我們消除了之前版本單點寫入瓶頸。業務對數據庫的要求是不停服務，永遠在線，為此所有的操作都要是在線的。傳統的垂直擴展的方式不行了，只能采用水平擴容的方式。這從方法上看也很直觀，怎么做呢？分三步走：
在集群中增加節點→讓新節點具備服務能力→將一部分負載分發到新節點上
看起來，似乎和將大象裝進冰箱一樣，步驟明確。但每一步都不是那么好做的。
因為OceanBase是無共享存儲的，要想新增加的節點能夠分擔負載，新節點上先要有數據。最難的是此過程中既要保證數據一致性，又要不影響業務。無論是機房擴容（機房內新增機器）還是擴展到新機房（很有可能是異地或公有雲場景），我們都必須做到在線。在OceanBase的實現中，主要依賴如下幾點：
-
多副本機制。多副本不僅是高可用的基礎，也是在線擴容的基礎。從本質上來看，擴容無外乎兩種：一種是將新數據寫入到新節點，后續對該部分數據的讀寫也在新節點；另一種是將現節點上的部分數據移動到新節點並在新節點提供服務。
第一種情況容易處理；第二種情況就需要利用多副本機制，簡單地理解就是把其中的一個副本從原節點遷移到新節點，說起來簡單，做起來有很多的細節要考慮，比如在異地增加一個副本，怎么樣做到既能高效地遷移數據同時又不影響現有服務。
-
細粒度的主備關系。傳統的主備大多數是節點級的，由於一個節點上保存的數據量較大，主備切換的影響很大。在OceanBase中，主備關系的粒度是分區級的，這是一個很細的粒度，切換對業務的影響比較小，並且切換是秒級的。
-
位置信息自動刷新。在擴容引起分區位置變化后，在第一次訪問原位置時，系統會檢測到變化，並且刷新位置信息來進行重試，執行成功后向客戶端返回正確的結果。除OBServer端以外，OBProxy也會根據服務端的反饋來更新自己保留的位置信息，后續的訪問就會被直接路由到正確的節點而無需集群內部轉發。
擴容是在線的，縮容也是如此。
3高可用
高可用是OceanBase數據庫安身立命的根本，以下三篇文章對此進行了詳細的描述：
它們包括了“OceanBase和傳統數據庫的差異，以及，在選舉協議上為什么我們選擇Paxos協議而不是更容易理解的Raft協議？”等內容。在這里簡短總結如下：
-
傳統數據庫高可用依賴專用硬件，而OceanBase是在普通商業硬件上實現高可用。
-
傳統數據庫在故障發生時缺乏仲裁機制，需要人在不丟數據和不停服務之間做選擇；OceanBase基於Paxos協議在少數派副本故障情況下可以自動恢復，不丟數據（RPO＝0），不停服務（受影響分區RTO小於30秒）。
-
采用Paxos協議而不是Raft協議的原因在於Raft協議要求日志確認必須是順序的，如果前面的某條日志因為種種原因沒有得到確認，后面的日志也都不能確認。這會造成一個嚴重后果，使得在業務邏輯層面不互相依賴的操作產生了互相依賴，對系統吞吐率有非常大的影響。尤其在高負載的時候。這種依賴是業務開發人員和DBA無法預測和規避的，發生的時候也無法有效解決。
除了異常情況下的可用性，系統升級、DDL變更等計划中的操作也不能影響系統可用性。我們通過逐個Zone升級的方式，實現升級過程的可灰度、可回滾；同時通過多個Zone之間的數據一致性校驗來驗證新升級系統的正確性。
通過實現多版本的數據庫對象定義，我們實現了DDL操作和查詢、更新操作互相不等待。針對多版本的數據庫對象定義，多補充一句，DDL操作對數據庫對象的影響保證能被對於同一個用戶Session后續的操作看到，哪怕這個用戶Session對應的是OBProxy到集群不同服務器的多個Session。
4高性能
高性能不僅僅意味着服務能力強，也意味着成本降低，在相同硬件條件下可以支撐規模更大的業務。OceanBase通過讀寫分離架構（LSM tree），將更新暫存在內存中，並且在內存中維護兩種類型的索引：Hash索引和B＋樹索引，分別用來加速主鍵查詢和索引范圍查詢，達到准內存數據庫的性能。
和傳統數據庫不同的是：更新操作不是原地進行的，沒有傳統數據庫的寫入放大問題，對於一般規模的系統，內存可以放下一天的增量。在系統高負載運行的時候，幾乎沒有數據文件寫，這會大大減少IO；在系統負載輕的時候，將內存增量批量合並到持久化存儲上。
除了讀寫分離架構帶來的性能提升外，我們在整個執行鏈路上做了不少優化，主要包括如下幾類：
-
Cache機制。在數據層面有行緩存和數據塊緩存，對於經常訪問的數據，IO讀大大降低了；在SQL引擎層，有執行計划緩存。
-
JIT編譯執行。在表達式計算及存儲執行過程中，都支持編譯執行，大大加速了大量數據行的計算。
-
自適應能力。SQL引擎會根據語句操作數據的分布情況選擇采用本地、遠程、分布式執行，並基於代價選擇合適的計划。在分布式執行的情況下，根據代價計算盡量將計算下降到節點。事務層會盡量采用本地事務，減少分布式事務以提升性能。
-
共享工作線程以及異步化。和傳統數據庫不同的是，OceanBase沒有采用專有工作線程方式，工作線程多Session共享。此外，在語句執行過程以及事務提交時，多處采用異步化操作，最大限度地減少了無謂等待，充分利用CPU。
除上述情況以外，我們還做了很多細致的工作。整體來看效果非常明顯：2017年“雙十一”峰值4200萬次操作每秒，用戶體驗相當順滑，系統表現很平穩。
5低成本
OceanBase一方面需要滿足業務對數據庫的要求，另一方面也要節約成本，不僅僅是運營成本，還包括業務遷移和人員學習成本。
OceanBase的成本優勢主要來自以下三點：
-
通過執行路徑性能提升降低計算成本；
-
通過讀寫分離架構優勢降低存儲成本，一個真實的案例是某內部業務從Oracle遷移到OceanBase，原先的100TB縮小到30幾個TB。因為OceanBase中可以采用壓縮比更高的壓縮算法，而在Oracle中，由於是原地更新要兼顧性能，沒法采用消耗CPU過多的高壓縮比壓縮算法；
-
通過多租戶架構，不同負載類型的業務通過多租戶方式混合部署，能更加充分地利用了機器資源（可參考：多租戶機制概述）。從實際應用來看，采用OceanBase數據庫的金融業務，單賬戶成本只有原先的1/5到1/10。
6兼容性
以上的幾個特點使得OceanBase具有競爭優勢，但要將業務真正從原系統遷移到OceanBase還需要一個額外的特性——兼容性。高兼容性使得系統遷移能在可控的成本下進行。
對公司內部MySQL業務，OceanBase能做到業務零修改遷移。可以這么說，主流關系數據庫具備的常用功能OceanBase都具備了。不僅是在語法層面，而且是在用戶體驗和業務體驗上完全一致。
從2017年開始，OceanBase開始服務外部客戶，我們發現兼容性做得還不夠，還需要再上一層樓：不僅常用功能要兼容，更要全面兼容；不僅是要兼容MySQL，還要兼容商業數據庫。只有這樣，才能使得外部業務具備零修改遷移OceanBase的可能性。這些工作正是我們目前在做的。
三、未來展望
接下來，OceanBase 2.0版本即將發布，屆時也會在DBAplus社群進行新特性的技術分享。這個全新的版本在分布式能力和SQL功能上相對於1.X版本都有質的提升，我們也真誠希望，OceanBase 2.0能夠讓分布式架構對業務透明、讓業務更方便地獲得更好的數據庫服務。
Q&A
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：多副本之間是如何復制的？物理日志？邏輯日志？還是其他方法？
答：物理日志。