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

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

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

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

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

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

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

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

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

l日志型副本：只包含日志的副本，沒有 MemTable 和 SSTable。它參與日志投票并對外提供日志服務，可以參與其他副本的恢復，但自己不能變?yōu)橹魈峁祿旆铡Ｈ罩拘透北驹跇嫿p活系統(tǒng)中可以作為第三點存在，因為其只存儲日志，可以大大節(jié)約存儲空間。

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

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

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

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

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

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

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

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

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

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

   OB的BloomFilter CACHE 是一個針對宏塊的過濾器，當一個宏塊上的空查次數超過某個閾值時，就會自動構建 BloomFilter，并放入BloomFilter  Cache。

OB的CACHE都是可變長的，為了便于管理，OB設計了ObKVCacheMap結構，以2MB為單位進行內存分配與釋放管理。

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

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

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