今天我們來討論OB，我也是一個OB的初學(xué)者，因此我對OB的內(nèi)在原理和應(yīng)用特性也知之甚少，我的大部分觀點都是基于我對數(shù)據(jù)庫的理解套用在OB上的。

另外，對于OB、TIDB等基于LSM-TREE存儲引擎的數(shù)據(jù)庫，經(jīng)常會有人產(chǎn)生一些對比，因此在一些分析中我也會與TIDB進(jìn)行對比。同樣，對于TIDB，我也是只知道一些皮毛，因此這些對比很可能也有一些錯誤。

以前我也寫文章分析過，TIDB和OCEANBASE雖然底層都是使用LSM-TREE存儲引擎，不過其架構(gòu)上是不同的。OB是一種典型的MPP架構(gòu)的數(shù)據(jù)庫，而TIDB是存儲計算完全分離的架構(gòu)。不過TIDB 5.0中也引入了MPP計算框架，具體是如何實現(xiàn)的，我還沒有做研究，因此這里不展開討論。

以往TIDB與OB進(jìn)行爭論的時候，TIDB往往會指出MPP的缺點來證明TIDB比OB的優(yōu)越，而TIDB引入MPP計算框架反而證明了這種指責(zé)的不全面。以前我也說過，目前的大多數(shù)分布式數(shù)據(jù)庫并不具備通用計算的能力，可能針對某種業(yè)務(wù)負(fù)載很好用，而對于一些其他的負(fù)載，就差強人意。

實際上任何一個分布式數(shù)據(jù)庫廠家都在努力改善自己的產(chǎn)品，從而適應(yīng)更廣泛的應(yīng)用場景。5.0以前的TIDB沒有MPP的sharding key死結(jié)，不過也正因為如此，在TIDB層面上實現(xiàn)BUFFER CACHE十分困難，因為這需要引入緩沖區(qū)融合機制，在大規(guī)模分布式計算引擎上引入緩沖區(qū)融合將會是一個災(zāi)難。缺少TIDB層面BUFFER CAHCE，如果你不能接受穩(wěn)定的稍慢，那么就需要提高硬件的配置，使用ssd盤等方式來提高SQL的響應(yīng)速度，因此TIDB對硬件的要求很高。TIDB 5.0引入MPP計算模式我想也是從這方面考慮入手吧，這種計算模式的引入可以優(yōu)化TIDB以往版本對某些場景的支持能力。

OB和TIDB的架構(gòu)不同，OB是天生的SHARED NOTHING的MPP架構(gòu)的，因此OB與其他的LSM-TREE存儲引擎的數(shù)據(jù)庫不同，設(shè)計了十分復(fù)雜的緩沖結(jié)構(gòu)。為什么說是十分復(fù)雜的緩沖結(jié)構(gòu)呢，因為OB是一種多租戶的分布式數(shù)據(jù)庫，在租戶隔離上設(shè)計的十分完整，緩沖區(qū)可以細(xì)粒度到租戶級別，每個租戶都有獨立的內(nèi)存，CPU等的資源隔離。

另外一方面，Oceanbase是基于谷歌的五分鐘原則設(shè)計的數(shù)據(jù)庫系統(tǒng)(谷歌認(rèn)為如果某個數(shù)據(jù)5分鐘內(nèi)會被訪問至少一次，那么這個數(shù)據(jù)最好是放在內(nèi)存中)。OB采用LSM-TREE，因此需要大量的內(nèi)存來存儲MEMT 。因此操作系統(tǒng)的物理內(nèi)存可以盡可能多的交給OB SERVER，由OceanBase自己管理。

從上面的一張圖里可以看到OB的內(nèi)存使用策略。通過memory_limit_percentage參數(shù)可以設(shè)置最多有多少OS的內(nèi)存可以給OB使用。這個參數(shù)的建議設(shè)置值是如果服務(wù)器內(nèi)存為384GB，則設(shè)置為80%，如果服務(wù)器內(nèi)存為512GB或者更高，則設(shè)置為90%。從這個策略也可以看出，OB還是比較吃內(nèi)存的，為了有比較好的性能，建議給OB的服務(wù)器配置多一點內(nèi)存。

實際上，OB的緩沖區(qū)除了其他LSM-TREE數(shù)據(jù)庫所通用的實現(xiàn)外，還和B-TREE/HEAP存儲引擎的數(shù)據(jù)庫一樣設(shè)計了BLOCK CACHE。

可以看出，OB設(shè)計了兩層CACHE，一層是從SST讀取到內(nèi)存中的BLOCK CACHE，這層CACHE可以用于一般的SQL掃描操作，而在BLOCK CACHE之上，還設(shè)計了一層row cache，存儲某些熱行，這些熱行用于一些簡單的，執(zhí)行頻率較高的，訪問少量行的SQL。

這種雙層CACHE的設(shè)計(MEMSTORE的寫緩沖不算在內(nèi))實際上是十分復(fù)雜的。Oracle數(shù)據(jù)庫也有BLOCK CACHE和ROW CACHE兩種緩沖設(shè)計，不過ROW CACHE只用來做字典緩沖使用，實際上是一種應(yīng)用特定的緩沖，是應(yīng)用級的。Oracle數(shù)據(jù)庫對數(shù)據(jù)字典的訪問是有特殊的業(yè)務(wù)邏輯的，為了提高效率而設(shè)計的ROW CACHE是按照固定的業(yè)務(wù)邏輯來設(shè)計的。而通用型的業(yè)務(wù)負(fù)載無法使用小巧高效的ROW CAHCE，必須使用統(tǒng)一的BLOCK CACHE。

而OB的row cache并不是用于內(nèi)部計算使用，是面向通用業(yè)務(wù)場景的，如果某一行在block cache中的使用頻率較高，那么就會被放入row cache中。為了避免每個訪問都去查詢row cache，從而導(dǎo)致row cache的命中率過低，影響CACHE的訪問效率，在row cache上增加了一個布魯姆過濾器。

我第一次看到OB的row cache結(jié)構(gòu)的時候，就感到這種設(shè)計很互聯(lián)網(wǎng)。這種架構(gòu)，對于一些互聯(lián)網(wǎng)應(yīng)用的開發(fā)人員來說可能很熟悉，很容易讓人想起應(yīng)用-布魯姆過濾器-REDIS-數(shù)據(jù)庫的應(yīng)用架構(gòu)。對于這層CACHE，我還是十分疑惑的，因為CACHE的設(shè)計原則是簡單高效，這層和業(yè)務(wù)結(jié)合的十分緊密的row cache是不是讓應(yīng)用開發(fā)人員自己去建立更好一些呢?當(dāng)然對于應(yīng)用類型十分吻合這種架構(gòu)，又沒有能力自己構(gòu)建內(nèi)存緩沖層的用戶來說，這層row cache確實可以簡化應(yīng)用。我還沒有深入去研究OB的row cache，不知道這層CACHE是否是可以在租戶級關(guān)閉的，如果能夠很方便的開關(guān)，這是一個不錯的設(shè)計，否則我覺得如果遇到一些和這種場景不適合的應(yīng)用，這種結(jié)構(gòu)很可能會影響整體的性能。

LSM-TREE存儲引擎的BLOCK CACHE性能問題，在國外的一些論壇上也多有討論，比較主流的觀點是效率不如HEAP/B-TREE存儲引擎的數(shù)據(jù)庫。這可能也是OB要引入row cache的一個原因吧。OB官方文檔上對此的解釋是：OLTP 業(yè)務(wù)大部分操作為小查詢，通過小查詢優(yōu)化，OceanBase 數(shù)據(jù)庫避免了傳統(tǒng)數(shù)據(jù)庫解析整個數(shù)據(jù)塊的開銷，達(dá)到了接近內(nèi)存數(shù)據(jù)庫的性能。

這種描述，對于某些應(yīng)用場景來說可能是準(zhǔn)確的，特別是像支付寶這樣的交易類系統(tǒng)，而對于ERP，MIS系統(tǒng)等來說，就不一定適合了。大部分傳統(tǒng)企業(yè)的OLTP系統(tǒng)并不能整合成如此簡單的訪問場景。從今天我們討論的問題上，我們也看得出，分布式數(shù)據(jù)庫廠商都在采用一些自己的獨特技術(shù)，讓數(shù)據(jù)庫更加適合通用型的場景，從而在擁有分布式數(shù)據(jù)庫的高可靠性、強大的橫向擴(kuò)展能力之外，能夠像通用集中式數(shù)據(jù)庫一樣，對各種通用計算場景都能提供很好的支持。