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