今天我們來討論OB，我也是一個OB的初學者，因此我對OB的內在原理和應用特性也知之甚少，我的大部分觀點都是基于我對數據庫的理解套用在OB上的。

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

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

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

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

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

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

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

實際上，OB的緩沖區除了其他LSM-TREE數據庫所通用的實現外，還和B-TREE/HEAP存儲引擎的數據庫一樣設計了BLOCK CACHE。

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

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

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

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

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

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