我剛開始工作時做一個OA系統(tǒng)，業(yè)務(wù)也比較簡單，用戶數(shù)也很少，數(shù)據(jù)很“單純”，一個SQL Server數(shù)據(jù)庫感覺就綽綽有余了。
后來互聯(lián)網(wǎng)大爆發(fā)，尤其是移動互聯(lián)網(wǎng)到來以后，數(shù)據(jù)越來越多，越來越雜。
圖片
單機存不下來，又得搞分布式，分庫分表；不僅僅是OLTP，還需要OLAP，HTAP……
公司被迫采用各種各樣的文檔數(shù)據(jù)庫、列式數(shù)據(jù)庫、鍵值數(shù)據(jù)庫來應(yīng)對，變成了大雜燴。
我時常在想，有沒有一種的數(shù)據(jù)庫，把這些問題統(tǒng)一解決呢？
解決不了全部，能解決80%也行啊。
答案是肯定的，那就是OceanBase。
OceanBase我在之前的漫畫中給大家介紹過，它最早是為了解決淘寶和支付寶中海量數(shù)據(jù)處理而誕生的，完全自主研發(fā)的原生分布式數(shù)據(jù)庫。
圖片
OceanBase 已連續(xù) 10 年穩(wěn)定支撐雙 11，創(chuàng)新推出“三地五中心”城市級容災(zāi)新標準，在被譽為“數(shù)據(jù)庫世界杯”的 TPC-C 和 TPC-H 測試上都刷新過世界紀錄。
OceanBase采用了一種一體化的設(shè)計思路來解決數(shù)據(jù)庫問題，包括一體化架構(gòu)、一體化引擎和一體化產(chǎn)品，接下來分別給大家聊一下。
圖片
1.一體化架構(gòu)
一體化架構(gòu)的意思是單機分布式一體化，實現(xiàn)數(shù)據(jù)可大可小。
如果企業(yè)規(guī)模小，數(shù)據(jù)量也小，完全可以把OceanBase做單機部署。實際上，OceanBase甚至可以部署到樹莓派這樣簡單的計算機中，實現(xiàn)主備庫的模式。
在企業(yè)的數(shù)據(jù)變大的時候，OceanBase能實現(xiàn)平滑伸縮，把單機變成分布式，對用戶完全透明。
圖片
2.一體化引擎
2.1 一體化存儲引擎
大家都知道，交易型應(yīng)用（OLTP）和分析型應(yīng)用(OLAP)對存儲的要求是不同的。
圖片
但是現(xiàn)在很多系統(tǒng)既要支持OLTP，又要支持OLAP，即混合負載(HTAP) 。
OceanBase是一個Shared Nothing的多副本架構(gòu)，這就有兩種設(shè)計思路：
（1）每個副本都用相同格式（如行存/行列混合），所有請求都直接由主副本提供服務(wù)。
這種方案沒有數(shù)據(jù)延遲的問題，但沒有支持列存，OLAP差一些，適合OLTP+非常輕量的OLAP場景。
（2）副本采用不同的存儲格式，主副本行存支持OLTP，某一備副本用列存支持OLAP。
這種方案通過引入列存大幅提升了OLAP的能力，但是主副本與備副本之間會額外引入毫秒級的延遲，適合簡單的OLTP的場景加上中等的OLAP的場景。
對于這兩種方式，OceanBase通過一體化的存儲引擎都會進行支持，通過一套數(shù)據(jù)庫內(nèi)核，同時實現(xiàn)OLTP和OLAP兩種業(yè)務(wù)。
2.2 一體化執(zhí)行引擎
在混合負載下，肯定既有簡單查詢，又有復(fù)雜查詢，對于簡單查詢，數(shù)據(jù)量小，那就由SQL層把數(shù)據(jù)從存儲層拉上來。
復(fù)雜查詢涉及到的數(shù)據(jù)量比較大，所以要并行執(zhí)行，SQL層需要把執(zhí)行計劃推到存儲層，降低網(wǎng)絡(luò)開銷。
圖片
這種推拉結(jié)合的方式，讓執(zhí)行引擎把簡單查詢和復(fù)雜查詢很好地融入到了一套系統(tǒng)中。
2.3 存算分離引擎
OceanBase是Share Nothing架構(gòu)，但云端是Share Storage，兩者之間似乎存在矛盾，如何融合呢？
OceanBase采用了LSM-Tree做底層存儲，數(shù)據(jù)分為 基線數(shù)據(jù)+增量數(shù)據(jù)，在多個副本之間，基線數(shù)據(jù)是一樣的，所以可以共享一份存儲。
通過日志副本和仲裁副本的方式，進一步降低計算開銷，最終用一個副本的存儲，接近兩個副本之間的計算的極小代價，在云端實現(xiàn)了彈性。
3.一體化產(chǎn)品
3.1 一體化SQL
相比集中式數(shù)據(jù)庫和單機數(shù)據(jù)庫，分布式數(shù)據(jù)庫有些事情很難實現(xiàn)，比如大事務(wù)，涉及到參與者，分區(qū)數(shù)特別多，分布式事務(wù)基本上不可能完成。
再比如鎖表，如果表涉及的分區(qū)特別多，也不可能把每個分區(qū)都鎖住。
本質(zhì)的問題就是原生分布式數(shù)據(jù)庫是一個分區(qū)一個獨立日志流，使得鎖表這樣的操作和分區(qū)數(shù)成正比。
OceanBase則通過動態(tài)日志流的技術(shù)，把一臺機器上所有分區(qū)動態(tài)融入到一個日志流，使得大事務(wù)，鎖表的復(fù)雜度與機器數(shù)成正比，不與分區(qū)成正比。
最終實現(xiàn)分布式數(shù)據(jù)庫與集中式數(shù)據(jù)庫與單機數(shù)據(jù)庫完全對標的SQL功能。
圖片
3.2 多模融合
OceanBase數(shù)據(jù)庫不但可以支持多種模型，并且支持模型之間的互操作，真正實現(xiàn)了多模融合。
圖片
3.3 一體化產(chǎn)品家族
OceanBase圍繞關(guān)鍵業(yè)務(wù)負載，提升關(guān)鍵生態(tài)能力。
比如OceanBase實現(xiàn)了很多關(guān)鍵核心業(yè)務(wù)要求的“變更操作可以回溯，回滾”，把企業(yè)的合規(guī)流程融入到了數(shù)據(jù)庫開發(fā)者工作流程中。
很多關(guān)鍵應(yīng)用，用戶都要求新老系統(tǒng)長期并跑，一鍵逃生，不管新系統(tǒng)出現(xiàn)什么問題，都可以一鍵逃生到老系統(tǒng)。
圖片
4.OceanBase 4.2.1 LTS版本
最新發(fā)布的OceanBase 4.2.1 LTS是首個長期支持、可規(guī)模化使用的一體化數(shù)據(jù)庫，具備OLTP完整的核心功能。
在以上描述的核心技術(shù)支持下，它性能更強，TP性能是3.2版本的1.9倍；AP性能是3.2版本的2.7倍。
通過引入基于仲裁的無損容災(zāi)方案，通過兩個副本實現(xiàn)RPO等于0。
在OceanBase列存實驗室版本展示中，與業(yè)界業(yè)內(nèi)頂流列存數(shù)據(jù)庫ClickHouse跑分PK，結(jié)果不僅性能處于同一水平，甚至還快了那么一點點。
5.總結(jié)
對數(shù)據(jù)庫這個產(chǎn)品來說，其實用戶并不關(guān)注底層的具體實現(xiàn)，集中式也好，分布式也罷，行存也行，列存也行。用戶關(guān)注的是使用體驗，是不是高可用、高安全、高性價比。
OceanBase在這一點上做得很好，它在不斷解決各種場景問題，尤其是關(guān)鍵業(yè)務(wù)處理時，摸索出了一套最佳實踐，形成了一體化的解決思路，這就是OceanBase最驚艷的地方。
當(dāng)然，一體化不是簡單的拼裝組合，也不是要解決所有的問題，就像有了手機、電視，我們還是回去電影院看電影一樣，在特殊領(lǐng)域還是需要用專業(yè)的數(shù)據(jù)庫的。
用技術(shù)讓海量的數(shù)據(jù)管理和使用更簡單，希望OceanBase持續(xù)打造能夠承載關(guān)鍵業(yè)務(wù)負載的一體化數(shù)據(jù)庫，不斷滿足客戶的需求。
