OceanBase於2020年3月在阿里雲上完成了商業化,在公有云上正式對外開放。同步上線的還有相關的生態產品,包括集羣管控(OCP:OceanBase Cloud Platform),診斷(OTA:OceanBase Tunning Advisor),遷移服務(OMS:OceanBase Migration Service)及開發者中心(ODC:OceanBase Developer Center)。算法
螞蟻金服自研分佈式關係數據庫OceanBase是一款純原生的分佈式關係數據庫,在代碼層面徹底可控。公共雲OceanBase產品(圖1-1)是基於三份副本3AZ部署,經過paxos協議保證了多節點間的數據一致性,單點故障甚至單AZ故障,也能夠保障業務連續性,RPO=0,RTO<30s,作到機房級高可用,將來還將推出三地五中心的產品形態,具有城市級高可用切換能力。同時,OceanBase的資源管理具備很是高的靈活性。它支持多租戶部署,在OceanBase集羣裏面,咱們能夠按需分配實例,而且能夠進行在線資源擴容或者縮容。
從安全性和可用性來說,OceanBase是很是適合金融業務場景的。由於監管需求,金融業務場景(像銀行業務等)不能上公有云。可是這並不影響類金融業務,像保險、基金等。數據庫
圖1-1緩存
與大多數分佈式系統不一樣的地方在於,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是一個shared noting的架構,每個OBServer都有獨立的存儲引擎,將數據保存在本地,這樣能夠知足容災場景下的數據連續服務。OceanBase採用LSM-Tree的架構來設計Cache和數據存儲,數據首先被寫入內存中的MemTable當中,這樣最高頻和最活躍的數據都在內存訪問,極大的提高了熱數據的訪問效率。當MemTable的寫入到達一個閾值的時候,MemTable中的數據會作一次合併,將數據轉到磁盤的SSTable中。在不少基於LSM Tree的存儲系統中,爲了解決寫入的性能問題,一般會將SSTable分爲多層,當一層的SSTable個數或者大小達到某個閾值時,合併入下一層SSTable。併發
圖1-3oracle
在OceanBase內部,也會有不少種不一樣類型的Cache,有相似於Oracle和MySQL的buffer。cache用於緩存sstable數據的塊緩存,還有用於緩存數據行的行緩存、日誌緩存、位置緩存等等。基線數據緩存到內存中提高查詢性能。對於不一樣租戶,每一個租戶都有本身獨立的緩存,能夠配置對應租戶內存使用的上下限,作到租戶隔離或者搶佔超賣,適用於不一樣需求的場景。負載均衡
在存儲成本上,OceanBase採用了多種數據壓縮算法,例如lz四、zstd等。OceanBase會對數據集作兩層瘦身,第一層是encoding,會使用字典、RLE等算法對數據作瘦身,第二層是通用壓縮,使用lz4等壓縮算法對encoding以後的數據再作一次瘦身。在zstd算法下,相較傳統MySQL Innodb的壓縮,能夠作到相同數據集只是用MySQL的1/3的存儲,幫助用戶極大的節省存儲成本。更重要的是,傳統數據庫定長頁的設計壓縮不可避免的會形成存儲的空洞,壓縮效率會受影響,而OB這樣的LSM-tree架構的存儲系統,壓縮對數據寫入性能是0影響的。
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是一個分佈式的關係型數據庫,符合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,提供優化建議,綁定執行計劃。使用這些平臺可使運維操做白屏化,下降了運維難度。
將來,OceanBase將會根據用戶需求提供更多實用、高效的特性,同時周邊生態產品的功能也會愈來愈完善,敬請期待。
免費看直播並有好禮相送:https://yq.aliyun.com/live/2301
100%自研數據庫OceanBase正式對外開放,歡迎前來體驗:https://www.aliyun.com/database/oceanbasept