建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
今天我們來(lái)討論OB，我也是一個(gè)OB的初學(xué)者，因此我對(duì)OB的內(nèi)在原理和應(yīng)用特性也知之甚少，我的大部分觀點(diǎn)都是基于我對(duì)數(shù)據(jù)庫(kù)的理解套用在OB上的。
成都創(chuàng)新互聯(lián)專(zhuān)注于順德企業(yè)網(wǎng)站建設(shè),響應(yīng)式網(wǎng)站設(shè)計(jì),商城系統(tǒng)網(wǎng)站開(kāi)發(fā)。順德網(wǎng)站建設(shè)公司,為順德等地區(qū)提供建站服務(wù)。全流程按需網(wǎng)站設(shè)計(jì)，專(zhuān)業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，成都創(chuàng)新互聯(lián)專(zhuān)業(yè)和態(tài)度為您提供的服務(wù)
另外，對(duì)于OB、TIDB等基于LSM-TREE存儲(chǔ)引擎的數(shù)據(jù)庫(kù)，經(jīng)常會(huì)有人產(chǎn)生一些對(duì)比，因此在一些分析中我也會(huì)與TIDB進(jìn)行對(duì)比。同樣，對(duì)于TIDB，我也是只知道一些皮毛，因此這些對(duì)比很可能也有一些錯(cuò)誤。
以前我也寫(xiě)文章分析過(guò)，TIDB和OCEANBASE雖然底層都是使用LSM-TREE存儲(chǔ)引擎，不過(guò)其架構(gòu)上是不同的。OB是一種典型的MPP架構(gòu)的數(shù)據(jù)庫(kù)，而TIDB是存儲(chǔ)計(jì)算完全分離的架構(gòu)。不過(guò)TIDB 5.0中也引入了MPP計(jì)算框架，具體是如何實(shí)現(xiàn)的，我還沒(méi)有做研究，因此這里不展開(kāi)討論。
以往TIDB與OB進(jìn)行爭(zhēng)論的時(shí)候，TIDB往往會(huì)指出MPP的缺點(diǎn)來(lái)證明TIDB比OB的優(yōu)越，而TIDB引入MPP計(jì)算框架反而證明了這種指責(zé)的不全面。以前我也說(shuō)過(guò)，目前的大多數(shù)分布式數(shù)據(jù)庫(kù)并不具備通用計(jì)算的能力，可能針對(duì)某種業(yè)務(wù)負(fù)載很好用，而對(duì)于一些其他的負(fù)載，就差強(qiáng)人意。
實(shí)際上任何一個(gè)分布式數(shù)據(jù)庫(kù)廠家都在努力改善自己的產(chǎn)品，從而適應(yīng)更廣泛的應(yīng)用場(chǎng)景。5.0以前的TIDB沒(méi)有MPP的sharding key死結(jié)，不過(guò)也正因?yàn)槿绱耍赥IDB層面上實(shí)現(xiàn)BUFFER CACHE十分困難，因?yàn)檫@需要引入緩沖區(qū)融合機(jī)制，在大規(guī)模分布式計(jì)算引擎上引入緩沖區(qū)融合將會(huì)是一個(gè)災(zāi)難。缺少TIDB層面BUFFER CAHCE，如果你不能接受穩(wěn)定的稍慢，那么就需要提高硬件的配置，使用ssd盤(pán)等方式來(lái)提高SQL的響應(yīng)速度，因此TIDB對(duì)硬件的要求很高。TIDB 5.0引入MPP計(jì)算模式我想也是從這方面考慮入手吧，這種計(jì)算模式的引入可以?xún)?yōu)化TIDB以往版本對(duì)某些場(chǎng)景的支持能力。
OB和TIDB的架構(gòu)不同，OB是天生的SHARED NOTHING的MPP架構(gòu)的，因此OB與其他的LSM-TREE存儲(chǔ)引擎的數(shù)據(jù)庫(kù)不同，設(shè)計(jì)了十分復(fù)雜的緩沖結(jié)構(gòu)。為什么說(shuō)是十分復(fù)雜的緩沖結(jié)構(gòu)呢，因?yàn)镺B是一種多租戶(hù)的分布式數(shù)據(jù)庫(kù)，在租戶(hù)隔離上設(shè)計(jì)的十分完整，緩沖區(qū)可以細(xì)粒度到租戶(hù)級(jí)別，每個(gè)租戶(hù)都有獨(dú)立的內(nèi)存，CPU等的資源隔離。
另外一方面，Oceanbase是基于谷歌的五分鐘原則設(shè)計(jì)的數(shù)據(jù)庫(kù)系統(tǒng)(谷歌認(rèn)為如果某個(gè)數(shù)據(jù)5分鐘內(nèi)會(huì)被訪問(wèn)至少一次，那么這個(gè)數(shù)據(jù)最好是放在內(nèi)存中)。OB采用LSM-TREE，因此需要大量的內(nèi)存來(lái)存儲(chǔ)MEMT 。因此操作系統(tǒng)的物理內(nèi)存可以盡可能多的交給OB SERVER，由OceanBase自己管理。
從上面的一張圖里可以看到OB的內(nèi)存使用策略。通過(guò)memory_limit_percentage參數(shù)可以設(shè)置最多有多少OS的內(nèi)存可以給OB使用。這個(gè)參數(shù)的建議設(shè)置值是如果服務(wù)器內(nèi)存為384GB，則設(shè)置為80%，如果服務(wù)器內(nèi)存為512GB或者更高，則設(shè)置為90%。從這個(gè)策略也可以看出，OB還是比較吃?xún)?nèi)存的，為了有比較好的性能，建議給OB的服務(wù)器配置多一點(diǎn)內(nèi)存。
實(shí)際上，OB的緩沖區(qū)除了其他LSM-TREE數(shù)據(jù)庫(kù)所通用的實(shí)現(xiàn)外，還和B-TREE/HEAP存儲(chǔ)引擎的數(shù)據(jù)庫(kù)一樣設(shè)計(jì)了BLOCK CACHE。
可以看出，OB設(shè)計(jì)了兩層CACHE，一層是從SST讀取到內(nèi)存中的BLOCK CACHE，這層CACHE可以用于一般的SQL掃描操作，而在BLOCK CACHE之上，還設(shè)計(jì)了一層row cache，存儲(chǔ)某些熱行，這些熱行用于一些簡(jiǎn)單的，執(zhí)行頻率較高的，訪問(wèn)少量行的SQL。
這種雙層CACHE的設(shè)計(jì)(MEMSTORE的寫(xiě)緩沖不算在內(nèi))實(shí)際上是十分復(fù)雜的。Oracle數(shù)據(jù)庫(kù)也有BLOCK CACHE和ROW CACHE兩種緩沖設(shè)計(jì)，不過(guò)ROW CACHE只用來(lái)做字典緩沖使用，實(shí)際上是一種應(yīng)用特定的緩沖，是應(yīng)用級(jí)的。Oracle數(shù)據(jù)庫(kù)對(duì)數(shù)據(jù)字典的訪問(wèn)是有特殊的業(yè)務(wù)邏輯的，為了提高效率而設(shè)計(jì)的ROW CACHE是按照固定的業(yè)務(wù)邏輯來(lái)設(shè)計(jì)的。而通用型的業(yè)務(wù)負(fù)載無(wú)法使用小巧高效的ROW CAHCE，必須使用統(tǒng)一的BLOCK CACHE。
而OB的row cache并不是用于內(nèi)部計(jì)算使用，是面向通用業(yè)務(wù)場(chǎng)景的，如果某一行在block cache中的使用頻率較高，那么就會(huì)被放入row cache中。為了避免每個(gè)訪問(wèn)都去查詢(xún)r(jià)ow cache，從而導(dǎo)致row cache的命中率過(guò)低，影響CACHE的訪問(wèn)效率，在row cache上增加了一個(gè)布魯姆過(guò)濾器。
我第一次看到OB的row cache結(jié)構(gòu)的時(shí)候，就感到這種設(shè)計(jì)很互聯(lián)網(wǎng)。這種架構(gòu)，對(duì)于一些互聯(lián)網(wǎng)應(yīng)用的開(kāi)發(fā)人員來(lái)說(shuō)可能很熟悉，很容易讓人想起應(yīng)用-布魯姆過(guò)濾器-REDIS-數(shù)據(jù)庫(kù)的應(yīng)用架構(gòu)。對(duì)于這層CACHE，我還是十分疑惑的，因?yàn)镃ACHE的設(shè)計(jì)原則是簡(jiǎn)單高效，這層和業(yè)務(wù)結(jié)合的十分緊密的row cache是不是讓?xiě)?yīng)用開(kāi)發(fā)人員自己去建立更好一些呢?當(dāng)然對(duì)于應(yīng)用類(lèi)型十分吻合這種架構(gòu)，又沒(méi)有能力自己構(gòu)建內(nèi)存緩沖層的用戶(hù)來(lái)說(shuō)，這層row cache確實(shí)可以簡(jiǎn)化應(yīng)用。我還沒(méi)有深入去研究OB的row cache，不知道這層CACHE是否是可以在租戶(hù)級(jí)關(guān)閉的，如果能夠很方便的開(kāi)關(guān)，這是一個(gè)不錯(cuò)的設(shè)計(jì)，否則我覺(jué)得如果遇到一些和這種場(chǎng)景不適合的應(yīng)用，這種結(jié)構(gòu)很可能會(huì)影響整體的性能。
LSM-TREE存儲(chǔ)引擎的BLOCK CACHE性能問(wèn)題，在國(guó)外的一些論壇上也多有討論，比較主流的觀點(diǎn)是效率不如HEAP/B-TREE存儲(chǔ)引擎的數(shù)據(jù)庫(kù)。這可能也是OB要引入row cache的一個(gè)原因吧。OB官方文檔上對(duì)此的解釋是：OLTP 業(yè)務(wù)大部分操作為小查詢(xún)，通過(guò)小查詢(xún)優(yōu)化，OceanBase 數(shù)據(jù)庫(kù)避免了傳統(tǒng)數(shù)據(jù)庫(kù)解析整個(gè)數(shù)據(jù)塊的開(kāi)銷(xiāo)，達(dá)到了接近內(nèi)存數(shù)據(jù)庫(kù)的性能。
這種描述，對(duì)于某些應(yīng)用場(chǎng)景來(lái)說(shuō)可能是準(zhǔn)確的，特別是像支付寶這樣的交易類(lèi)系統(tǒng)，而對(duì)于ERP，MIS系統(tǒng)等來(lái)說(shuō)，就不一定適合了。大部分傳統(tǒng)企業(yè)的OLTP系統(tǒng)并不能整合成如此簡(jiǎn)單的訪問(wèn)場(chǎng)景。從今天我們討論的問(wèn)題上，我們也看得出，分布式數(shù)據(jù)庫(kù)廠商都在采用一些自己的獨(dú)特技術(shù)，讓數(shù)據(jù)庫(kù)更加適合通用型的場(chǎng)景，從而在擁有分布式數(shù)據(jù)庫(kù)的高可靠性、強(qiáng)大的橫向擴(kuò)展能力之外，能夠像通用集中式數(shù)據(jù)庫(kù)一樣，對(duì)各種通用計(jì)算場(chǎng)景都能提供很好的支持。
網(wǎng)頁(yè)名稱(chēng)：聊聊 OB 的緩沖區(qū)機(jī)制，你明白了嗎？
文章出自：http://m.5511xx.com/article/cdgsjjd.html
