OceanBase於2020年3月在阿里雲上完成了商業化，在公有云上正式對外開放。同步上線的還有相關的生態產品，包括集羣管控（OCP:OceanBase Cloud Platform），診斷（OTA:OceanBase Tunning Advisor），遷移服務（OMS:OceanBase Migration Service）及開發者中心（ODC:OceanBase Developer Center）。
一、公共雲OceanBase服務端部署
螞蟻金服自研分佈式關係數據庫OceanBase是一款純原生的分佈式關係數據庫，在代碼層面完全可控。公共雲OceanBase產品（圖1-1）是基於三份副本3AZ部署，通過paxos協議保證了多節點間的數據一致性，單點故障甚至單AZ故障，也可以保障業務連續性，RPO=0，RTO<30s，做到機房級高可用，未來還將推出三地五中心的產品形態，具備城市級高可用切換能力。同時，OceanBase的資源管理具有非常高的靈活性。它支持多租戶部署，在OceanBase集羣裏面，我們可以按需分配實例，並且可以進行在線資源擴容或者縮容。
從安全性和可用性來講，OceanBase是非常適合金融業務場景的。因爲監管需求，金融業務場景（像銀行業務等）不能上公有云。但是這並不影響類金融業務，像保險、基金等。
二、OceanBase架構原理
與大多數分佈式系統不同的地方在於，OceanBase這個系統沒有單獨的總控服務器或者總控進程。分佈式系統一般包含一個單獨的總控進程，用來做全局管理、負載均衡，等等。OceanBase沒有單獨的總控進程，它的總控是一個服務，叫做RootService，集成在ObServer裏面。OceanBase會從所有的工作機中動態地選出一臺ObServer執行總控服務，另外，當總控服務所在的ObServer出現故障時，系統會自動選舉一臺新的ObServer提供總控服務。這種方式的好處在於簡化部署，雖然實現很複雜，但是大大降低了使用成本。
OceanBase通過分區能力做到無限水平擴展（圖1-2）。OceanBase跟傳統數據庫分區不一樣的地方，在於傳統數據庫所有的分區只能在一臺服務器，而OceanBase每個分區可以分佈到不同的服務器，每個分區都有三副本。從數據模型的角度看，OceanBase可以被認爲是傳統的數據庫分區表在多機的實現。它可以把不同的用戶生成的數據全部融合到統一的表裏面。無論這些分區在多臺服務器上是如何分佈的，整個系統對用戶呈現的都是一張表，後臺實現對用戶完全透明。OceanBase在用戶入口使用了OBProxy，它是一個訪問代理，它會根據用戶請求的數據將請求轉發到合適的服務器。ObProxy的最大的亮點在於性能突出，它可以在非常一般的普通服務器上達到每秒百萬級的處理能力。
圖1-2
如圖1-2，多個分區分佈在多臺服務器上。由於多個分區跨ObServer，內部通過兩階段提交實現分佈式事務。當然，兩階段提交協議性能較差，OceanBase內部做了很多優化。它提出了分區組的概念，會把多個經常一起訪問，或者說訪問模式比較類似的不同表的分區放到一個分區組裏面。OB後臺會將同一個分區組儘可能調度到一臺服務器上，避免分佈式事務。同時優化了兩階段提交協議的內部實現。兩階段提交協議涉及多臺服務器，協議中包含協調者、參與者這兩種角色，參與者維護了每臺服務器的局部狀態，協調者維護了分佈式事務的全局狀態。常見的做法是對協調者記日誌來持久化分佈式事務的全局狀態，而OceanBase的做法是，如果出現故障，通過查詢所有參與者的狀態來恢復分佈式事務。這種方式節省了協調者日誌，而且只要所有的參與者都預提交成功，整個事務就成功了，不需要等協調者寫日誌就可以應答客戶端。
三、OceanBase存儲架構
OceanBase是一個shared noting的架構，每一個OBServer都有獨立的存儲引擎，將數據保存在本地，這樣可以滿足容災場景下的數據連續服務。OceanBase採用LSM-Tree的架構來設計Cache和數據存儲，數據首先被寫入內存中的MemTable當中，這樣最高頻和最活躍的數據都在內存訪問，極大的提升了熱數據的訪問效率。當MemTable的寫入到達一個閾值的時候，MemTable中的數據會做一次合併，將數據轉到磁盤的SSTable中。在很多基於LSM Tree的存儲系統中，爲了解決寫入的性能問題，通常會將SSTable分爲多層，當一層的SSTable個數或者大小達到某個閾值時，合併入下一層SSTable。
圖1-3
在OceanBase內部，也會有很多種不同類型的Cache，有類似於Oracle和MySQL的buffer。cache用於緩存sstable數據的塊緩存，還有用於緩存數據行的行緩存、日誌緩存、位置緩存等等。基線數據緩存到內存中提升查詢性能。對於不同租戶，每個租戶都有自己獨立的緩存，可以配置對應租戶內存使用的上下限，做到租戶隔離或者搶佔超賣，適用於不同需求的場景。
在存儲成本上，OceanBase採用了多種數據壓縮算法，例如lz4、zstd等。OceanBase會對數據集做兩層瘦身，第一層是encoding，會使用字典、RLE等算法對數據做瘦身，第二層是通用壓縮，使用lz4等壓縮算法對encoding之後的數據再做一次瘦身。在zstd算法下，相較傳統MySQL Innodb的壓縮，可以做到相同數據集只是用MySQL的1/3的存儲，幫助用戶極大的節省存儲成本。更重要的是，傳統數據庫定長頁的設計壓縮不可避免的會造成存儲的空洞，壓縮效率會受影響，而OB這樣的LSM-tree架構的存儲系統，壓縮對數據寫入性能是0影響的。
四、OceanBase SQL引擎
OceanBase的租戶支持Oracle和MySQL兩種SQL兼容性，首先相較於傳統MySQL，OB除了硬解析以外，與Oracle一樣支持軟解析，同時解析器還支持SQL參數化以及綁定變量，如圖1-4所示，解析器將解析後的SQL模板以及執行計劃放在plan cache中，已經存在plan cache中的SQL就可以省去每一次硬解析帶來的開銷，提升了SQL運行效率。
圖1-4
基於LSM-Tree的存儲架構，OB設計了一套獨特的代價模型，引入統計信息，擁有了基於代碼模型的優化器，這意味着OB可以根據統計信息，計算每條SQL的最優訪問路徑，給出最優的執行計劃。同時OB也可以根據用戶的需求，在線動態綁定固化執行計劃，針對應急、效率的場景可以很好的提供便捷性。在執行器方面，OB不僅僅支持Nest Loop的Join方式，同時也支持了Hash Join、Merge Join，針對大表join提高效率。還支持併發執行、分佈式SQL等等。
五、OceanBase的AACID特性
OceanBase是一個分佈式的關係型數據庫，符合ACID原則。在傳統ACID的基礎上，OceanBase特別強調多了一個A，可用性。基於Paxos協議的多副本日誌複製，可以在單點故障的情況下提供無數據丟失的業務連續性。在一致性上，OB採用MVCC的多版本一致讀，當數據塊被更新時，OB會新開啓一個數據塊並帶上數據版本於事務id，只有事務內的SQL可以訪問到，未提交的數據不會被其他會話訪問當。隔離性上，OB支持Oracle的提交讀和串行化兩種事務隔離級別，對Oracle做到了很好的兼容。在持久性上，和大多數傳統數據庫一樣的日誌先行，事務提交的時候先保證redo日誌的寫成功後才寫數據，出現異常情況時不會存在數據二義性。
在數據安全上，OB也做了多種保護措施，最大程度的保障數據安全。比如回收站機制，在租戶級別設置回收站的開關，當回收站打開的狀態下，drop table、truncate的情況下數據不會被立馬刪除，而是進入了回收站，在回收站保留有效期內，都可以通過flashback的命令將表恢復原狀，極大程度上避免了誤操作帶來的一些風險。
針對delete、update這種數據修改類的操作，OB支持基於位點的Flashback Query來將數據恢復到某一個時間點，這樣針對業務或者運維過程中的錯誤SQL執行，具備數據找回能力。同時在Oracle租戶下，還支持as of timestam/scn這種查詢。
2019年10月，OceanBase斬獲TPC-C性能測試榜首。創造了tpmc6088萬的世界記錄，是前任榜首Oracle的2倍。同年十一月份，在支付寶的雙十一大促中又創造了6100萬筆/秒的支付峯值，再次打破世界記錄。經過多次極端業務的考驗，OceanBase證明，在性能、可靠性、可用性上，分佈式數據庫是可以和集中式數據庫媲美的。傳統的商業數據庫，如oracle、SQL server、DB2都依賴高端的硬件設備（小機，存儲，還有光纖網絡），但是OceanBase只需要普通的PC服務器，SSD盤、萬兆網絡就行。而且它還具有高存儲壓縮率。OceanBase上雲後，目前除了數據庫本身是按規格收費、遷移服務按小時收費外，其它管理平臺（OCP、ODC、OTA）是免費的。通過OCP可以方便地管理集羣、租戶、數據庫。用戶，監控租戶和節點的性能。通過ODC可以方便地管理和維護數據庫對象（表/視圖/函數/存儲過程等）。使用其SQLConsole可以便捷地操作數據庫。通過OTA，可以及時發現當前業務庫存在問題的SQL，提供優化建議，綁定執行計劃。使用這些平臺可以使運維操作白屏化，降低了運維難度。
觀看直播：https://yq.aliyun.com/live/2301
產品詳情: https://www.aliyun.com/database/oceanbasept