?離首次測試Oceanbase 4.0社區(qū)版已經(jīng)過去幾個月了，不過4.0的文檔一直還處于開發(fā)階段，昨天拿到了OB4文檔的預(yù)覽版。從個人在去年的體驗上今天看到的OB4.0的文檔來看，OB4和以前的OB3.X做了很多架構(gòu)上的優(yōu)化，很多地方似乎都有重構(gòu)的痕跡。雖然對OB的新用戶來說，整體架構(gòu)的提升必然會提高可用性、可靠性和性能，不過對于OB的老用戶來說，這并不一定是一件好事。希望Oceanbase 4之后其主體能夠穩(wěn)定下來，今后的大版本升級能夠平順一些。今天我們先通過文檔來學(xué)習(xí)一下OB4.0企業(yè)版吧。

去年我寫過一篇吐槽國產(chǎn)數(shù)據(jù)庫文檔的文章，后來很多國產(chǎn)數(shù)據(jù)庫廠商都和我做了關(guān)于文檔方面的溝通，希望我給他們提一些建議。當(dāng)時我和OB、高斯關(guān)于文檔的溝通做得都很細(xì)。十分高興的是，我對OB文檔的一些建議得到了很好的響應(yīng)。在OB4文檔的預(yù)覽版中我十分高興地看到了《參考指南》這份文檔，更令我驚喜的是這份文檔十分詳盡，有7000多頁。從內(nèi)容上來看，這份文檔并不是對v2.2.7文檔中SQL參考和數(shù)據(jù)庫參考的簡單合并，而是真正的把和OB數(shù)據(jù)庫相關(guān)的信息都相對完整地做了最細(xì)致的描述。對于一個數(shù)據(jù)庫產(chǎn)品而言，豐富的參考文檔可以為使用者提供更好的幫助。

在文檔中還是美中不足，缺少了一份十分重要的文檔，那就是《數(shù)據(jù)庫升級指南》，讓用戶能夠更順利的從OB 2.x和OB 3.X升級到4.x。數(shù)據(jù)遷移指南中有十分詳盡的從Oracle、MySQL等數(shù)據(jù)庫將數(shù)據(jù)遷移到OB的介紹，但是就是找不到如何從低版本的OB中將數(shù)據(jù)升級或者遷移到OB4的描述。

下面關(guān)于OB4的介紹都不是我直接體驗OB4產(chǎn)品后寫的，而只是從文檔中了解的。要了解OB4企業(yè)版，首先我們需要了解一下OB4的社區(qū)版與企業(yè)版之間的差異。社區(qū)版是我們可以在社區(qū)下載安裝的，而企業(yè)版是需要付費購買許可證的。

 OB的社區(qū)版和企業(yè)版之間的差異并不太大，最主要是在支持與服務(wù)方面。在功能方面，OB社區(qū)版最主要是少了Oracle語法兼容租戶。另外少了ACS和SPM這兩個和SQL執(zhí)行與優(yōu)化有關(guān)的能力，以及安全審計和行級標(biāo)簽與表空間透明加密功能。除了Oracle語法兼容問題外，其他功能并不是剛需。

OB采用SHARE NOTHING架構(gòu)的對等模式，通過多個ZONE來實現(xiàn)多副本高可用。在服務(wù)器上會運行叫做 observer 的單進(jìn)程程序作為數(shù)據(jù)庫的運行實例，使用本地的文件存儲數(shù)據(jù) Redo 日志。

OB在復(fù)制層使用日志流(LS、LogStream) 在多副本之間同步狀態(tài)，每個OBSERVER中會有多個日志流，每個Tablet 都通過負(fù)載均衡的模式對應(yīng)一個唯一的日志流，DML 操作寫入 Tablet 的數(shù)據(jù)所產(chǎn)生的 Redo 日志會持久化在日志流中。日志流的多個副本會分布在不同的可用區(qū)中，多個副本之間通過共識算法選擇其中一個副本作為主副本，其他的副本皆為從副本。日志流以租戶為單位，每個租戶在每臺機(jī)器上都會有一個唯一的主副本日志流，同時存在多個其他副本的日志流。這種設(shè)計實際上實現(xiàn)了真正的租戶隔離，我們在分析某個數(shù)據(jù)庫是不是原生態(tài)支持多租戶的時候，日志流的隔離是一個十分重要的判斷因素，只有基于租戶粒度的日志流隔離，才能確保一個租戶與另外一個租戶之間保持真正的隔離。

當(dāng)創(chuàng)建新的Tablet的時候會基于負(fù)載均衡原則選擇一個日志流，而當(dāng)某個日志流的負(fù)載不均衡的時候，OB會自動裂變生成新的日志流并進(jìn)行自動均衡。OB4.0對副本做了優(yōu)化，以滿足不同的需求。其副本種類如下：

l全能型副本：也就是目前支持的普通副本，擁有事務(wù)日志，MemTable 和 SSTable 等全部完整的數(shù)據(jù)和功能。它可以隨時快速切換為 Leader 對外提供服務(wù)。

l日志型副本：只包含日志的副本，沒有 MemTable 和 SSTable。它參與日志投票并對外提供日志服務(wù)，可以參與其他副本的恢復(fù)，但自己不能變?yōu)橹魈峁?shù)據(jù)庫服務(wù)。日志型副本在構(gòu)建雙活系統(tǒng)中可以作為第三點存在，因為其只存儲日志，可以大大節(jié)約存儲空間。

l只讀型副本：包含完整的日志，MemTable 和 SSTable 等，但是它的日志比較特殊。它不作為 Paxos 成員參與日志的投票，而是作為一個觀察者實時追趕 Paxos 成員的日志，并在本地回放。這種副本可以在業(yè)務(wù)對讀取數(shù)據(jù)的一致性要求不高的時候提供只讀服務(wù)。因其不加入 Paxos 成員組，又不會造成投票成員增加導(dǎo)致事務(wù)提交延時的增加。

?當(dāng)一個Tablet被修改的時候，可以通過WAL來確保其一致性，而如果當(dāng)某個事務(wù)修改的數(shù)據(jù)跨多個日志流的時候，就需要通過兩階段提交算法來確保事務(wù)的一致性了。這時候事務(wù)層會選擇一個事務(wù)修改的日志流產(chǎn)生協(xié)調(diào)者狀態(tài)機(jī)，協(xié)調(diào)者會與事務(wù)修改的所有日志流通信，判斷WAL是否持久化，當(dāng)所有日志流都完成持久化后，事務(wù)進(jìn)入提交狀態(tài)，協(xié)調(diào)者會再驅(qū)動所有日志流寫下這個事務(wù)的Commit日志，表示事務(wù)最終的提交狀態(tài)。協(xié)調(diào)者狀態(tài)機(jī)的存在會對分布式事務(wù)的延時有所影響，這也是我以前總說的分布式數(shù)據(jù)庫可以提高并發(fā)事務(wù)處理的并發(fā)量，但是不會直接提高單個事務(wù)的性能。

在存儲架構(gòu)上，OB存儲層以一張表或者一個分區(qū)為粒度存儲數(shù)據(jù)，每個分區(qū)對應(yīng)一個用于存儲數(shù)據(jù)的 Tablet(分片)，用戶定義的非分區(qū)表也會對應(yīng)一個 Tablet。Tablet的內(nèi)部是分層存儲的結(jié)構(gòu)。DML操作首先寫入 MemTable，等到 MemTable 達(dá)到一定大小時轉(zhuǎn)儲到磁盤成為 L0 SSTable。L0 SSTable 個數(shù)達(dá)到閾值后會將多個L0 SSTable合并成一個 L1 SSTable。在每天配置的業(yè)務(wù)低峰期，Major Merge會將所有的MemTable、L0 SSTable和L1 SSTable 合并成一個 Major SSTable。Major Merge是一個高開銷的工作，因此在這個窗口內(nèi)不要安排大型的維護(hù)作業(yè)。

每個 SSTable 內(nèi)部是以2MB定長宏塊為基本單位，每個宏塊內(nèi)部由多個不定長微塊組成。

MajorSSTable 的微塊會在合并過程中用編碼方式進(jìn)行格式轉(zhuǎn)換，微塊內(nèi)的數(shù)據(jù)會按照列維度分別進(jìn)行列內(nèi)的編碼，每一列壓縮結(jié)束后，還會對多列進(jìn)行列間等值/子串等規(guī)則編碼。在編碼壓縮之后，還可以根據(jù)用戶指定的通用壓縮算法進(jìn)行無損壓縮，進(jìn)一步提升數(shù)據(jù)壓縮率。從上述的存儲結(jié)構(gòu)看，OB采用的是一種混合列壓縮結(jié)構(gòu)的存儲機(jī)制。

為了數(shù)據(jù)掃描的提高性能，OB設(shè)置了多個緩沖區(qū)， OceanBase是LSM-TREE存儲架構(gòu)的，因此其數(shù)據(jù)庫緩沖區(qū)與Oracle、Mysql、Postgresql等是完全不同的，在DB CACHE中不會產(chǎn)生數(shù)據(jù)修改，不會存在臟塊，因此OB的緩沖區(qū)是一個只讀的“純緩沖”。OB4的緩沖區(qū)設(shè)計與2.2版本基本相似，除了一些字典緩沖有些變化外，主要的緩沖區(qū)都基本上沿用了以前版本的設(shè)計。

對于LSM-TREE存儲架構(gòu)的數(shù)據(jù)庫，有可能同一行的數(shù)據(jù)存儲在多個SSTAB或者M(jìn)EMTAB中，為了提高訪問效率，OB設(shè)置了融合結(jié)果緩沖區(qū)FUSE ROW CACHE，查詢可以直接在FUSE ROW CACHE中命中。

雖然SST是排序表，可以通過二分法定位到某一行，不過對于訪問比較頻繁的數(shù)據(jù)行，還是有個緩沖比較好，于是row cache就承擔(dān)了這個工作。

Block Index Cache存儲的是宏塊中的微塊的地址，通過這個cache提高在2MB的宏塊中查找數(shù)據(jù)的效率。

Block Cache是類似于Oracle DB CACHE的緩沖，存儲的是OB的微塊。因為OB的微塊是可變長的，因此OB的Block Cache在訪問算法與特性上與Oracle DB CACHE有較大的不同。

   OB的BloomFilter CACHE 是一個針對宏塊的過濾器，當(dāng)一個宏塊上的空查次數(shù)超過某個閾值時，就會自動構(gòu)建 BloomFilter，并放入BloomFilter  Cache。

OB的CACHE都是可變長的，為了便于管理，OB設(shè)計了ObKVCacheMap結(jié)構(gòu)，以2MB為單位進(jìn)行內(nèi)存分配與釋放管理。

LSM-TREE存儲架構(gòu)的數(shù)據(jù)庫在CACHE上比BTREE架構(gòu)的要復(fù)雜的多，從CACHE的設(shè)計可以看出OB在這方面已經(jīng)有了比較成熟的解決方案，并且這些緩沖區(qū)的設(shè)計都是面向不同的業(yè)務(wù)場景的。

最后我們來看看OB的高可用，實際上OB高可用涉及的技術(shù)細(xì)節(jié)十分復(fù)雜，今天我們僅僅從集群架構(gòu)來看看應(yīng)用如何實現(xiàn)高可用。OB的高可用架構(gòu)在OB4里變化不大，除了數(shù)據(jù)庫本身通過Multi-Paxos共識協(xié)議實現(xiàn)副本之間的選舉與同步外，OBProxy依然是OB高可用的不可或缺的組件。應(yīng)用通過本身帶有高可用與負(fù)載均衡能力的OBProxy訪問單個或者多個OB集群，從而實現(xiàn)應(yīng)用級的高可用。當(dāng)客戶端通過OBProxy代理連接OBServer的時候，OBProxy需要幫助客戶端維持集群中的可用性狀態(tài)，OBProxy通過多種方式實現(xiàn)探活，并隨時更新黑名單，確保應(yīng)用的正確訪問。

今天簡單的分析一下OB，下周OB4.1的商用版就要發(fā)布了，我們也準(zhǔn)備等下周OB 4.1發(fā)布之后對OB4商用版進(jìn)行試用，屆時我再把測試的情況寫出來和大家分享吧。?