離首次測試Oceanbase 4.0社群版已經過去幾個月了，不過4.0的文件一直還處於開發階段，昨天拿到了OB4文件的預覽版。從個人在去年的體驗上今天看到的OB4.0的文件來看，OB4和以前的OB3.X做了很多架構上的最佳化，很多地方似乎都有重構的痕跡。雖然對OB的新使用者來說，整體架構的提升必然會提高可用性、可靠性和效能，不過對於OB的老使用者來說，這並不一定是一件好事。希望Oceanbase 4之後其主體能夠穩定下來，今後的大版本升級能夠平順一些。今天我們先透過文件來學習一下OB4.0企業版吧。去年我寫過一篇吐槽國產資料庫文件的文章，後來很多國產資料庫廠商都和我做了關於文件方面的溝通，希望我給他們提一些建議。當時我和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企業版，首先我們需要了解一下OB4的社群版與企業版之間的差異。社群版是我們可以在社群下載安裝的，而企業版是需要付費購買許可證的。 | | | |
| | | |
| 高 級 執 行 計 劃 管 理 (SPM，ACS) | | |
| | | |
| | | 不支援，社 區 版 本 不 支 持 行 級 標 籤 、數 據 和 日 志 加 密 存 儲(TDE)。 |
| | | 支援，社群版本支援 OCP、 OMS、ODC 等商業配套 圖 形 化 開 發 和 管 控 工 具 二 進 制 免 費 下 載 使 用 ， 但不包含 OMA。 |
| | | 社 區 版 本 僅 提 供 社 區 化 的 產 品 技 術 諮 詢 服 務 ， 採用社群 issues 運作模 式 ， 不 提 供 商 業 化 專 家 團隊技術諮詢 |
| | | 社 區 版 本 僅 支 持 在 OceanBase 社群官方網 站 或 官 方 社 區 提 供 在 線 服 務 諮 詢 ， 不 提 供 商 業 化專家團隊專屬服務 |
| 專 家 服 務 (規 劃 、 實 施 、巡 檢 、故 障 恢 復 、 生產保障) | | |
| | | 社 區 版 本 不 提 供 故 障 應 急處理服務 |
OB的社群版和企業版之間的差異並不太大，最主要是在支援與服務方面。在功能方面，OB社群版最主要是少了Oracle語法相容租戶。另外少了ACS和SPM這兩個和SQL執行與最佳化有關的能力，以及安全審計和行級標籤與表空間透明加密功能。除了Oracle語法相容問題外，其他功能並不是剛需。OB採用SHARE NOTHING架構的對等模式，透過多個ZONE來實現多副本高可用。在伺服器上會運行叫做 observer 的單程式程式作為資料庫的執行例項，使用本地的文件儲存資料 Redo 日誌。OB在複製層使用日誌流(LS、LogStream) 在多副本之間同步狀態，每個OBSERVER中會有多個日誌流，每個Tablet 都透過負載均衡的模式對應一個唯一的日志流，DML 操作寫入 Tablet 的資料所產生的 Redo 日誌會持久化在日誌流中。日誌流的多個副本會分佈在不同的可用區中，多個副本之間透過共識演算法選擇其中一個副本作為主副本，其他的副本皆為從副本。日誌流以租戶為單位，每個租戶在每臺機器上都會有一個唯一的主副本日誌流，同時存在多個其他副本的日誌流。這種設計實際上實現了真正的租戶隔離，我們在分析某個資料庫是不是原生態支援多租戶的時候，日誌流的隔離是一個十分重要的判斷因素，只有基於租戶粒度的日誌流隔離，才能確保一個租戶與另外一個租戶之間保持真正的隔離。當建立新的Tablet的時候會基於負載均衡原則選擇一個日誌流，而當某個日誌流的負載不均衡的時候，OB會自動裂變生成新的日誌流並進行自動均衡。OB4.0對副本做了最佳化，以滿足不同的需求。其副本種類如下：l全能型副本：也就是目前支援的普通副本，擁有事務日誌，MemTable 和 SSTable 等全部完整的資料和功能。它可以隨時快速切換為 Leader 對外提供服務。l日誌型副本：只包含日誌的副本，沒有 MemTable 和 SSTable。它參與日誌投票並對外提供日誌服務，可以參與其他副本的恢復，但自己不能變為主提供資料庫服務。日誌型副本在構建雙活系統中可以作為第三點存在，因為其只儲存日誌，可以大大節約儲存空間。l只讀型副本：包含完整的日誌，MemTable 和 SSTable 等，但是它的日誌比較特殊。它不作為 Paxos 成員參與日誌的投票，而是作為一個觀察者實時追趕 Paxos 成員的日誌，並在本地回放。這種副本可以在業務對讀取資料的一致性要求不高的時候提供只讀服務。因其不加入 Paxos 成員組，又不會造成投票成員增加導致事務提交延時的增加。當一個Tablet被修改的時候，可以透過WAL來確保其一致性，而如果當某個事務修改的資料跨多個日誌流的時候，就需要透過兩階段提交演算法來確保事務的一致性了。這時候事務層會選擇一個事務修改的日誌流產生協調者狀態機，協調者會與事務修改的所有日志流通訊，判斷WAL是否持久化，當所有日誌流都完成持久化後，事務進入提交狀態，協調者會再驅動所有日誌流寫下這個事務的Commit日誌，表示事務最終的提交狀態。協調者狀態機的存在會對分散式事務的延時有所影響，這也是我以前總說的分散式資料庫可以提高併發事務處理的併發量，但是不會直接提高單個事務的效能。在儲存架構上，OB儲存層以一張表或者一個分割槽為粒度儲存資料，每個分割槽對應一個用於儲存資料的 Tablet(分片)，使用者定義的非分割槽表也會對應一個 Tablet。Tablet的內部是分層儲存的結構。DML操作首先寫入 MemTable，等到 MemTable 達到一定大小時轉儲到磁碟成為 L0 SSTable。L0 SSTable 個數達到閾值後會將多個L0 SSTable合併成一個 L1 SSTable。在每天配置的業務低峰期，Major Merge會將所有的MemTable、L0 SSTable和L1 SSTable 合併成一個 Major SSTable。Major Merge是一個高開銷的工作，因此在這個視窗內不要安排大型的維護作業。每個 SSTable 內部是以2MB定長宏塊為基本單位，每個宏塊內部由多個不定長微塊組成。MajorSSTable 的微塊會在合並過程中用編碼方式進行格式轉換，微塊內的資料會按照列維度分別進行列內的編碼，每一列壓縮結束後，還會對多列進行列間等值/子串等規則編碼。在編碼壓縮之後，還可以根據使用者指定的通用壓縮演算法進行無失真壓縮，進一步提升資料壓縮率。從上述的儲存結構看，OB採用的是一種混合列壓縮結構的儲存機制。為了資料掃描的提高效能，OB設定了多個緩衝區， OceanBase是LSM-TREE儲存架構的，因此其資料庫緩衝區與Oracle、Mysql、Postgresql等是完全不同的，在DB CACHE中不會產生資料修改，不會存在髒塊，因此OB的緩衝區是一個只讀的“純緩衝”。OB4的緩衝區設計與2.2版本基本相似，除了一些字典緩衝有些變化外，主要的緩衝區都基本上沿用了以前版本的設計。對於LSM-TREE儲存架構的資料庫，有可能同一行的資料儲存在多個SSTAB或者MEMTAB中，為了提高訪問效率，OB設定了融合結果緩衝區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在這方面已經有了比較成熟的解決方案，並且這些緩衝區的設計都是面向不同的業務場景的。最後我們來看看OB的高可用，實際上OB高可用涉及的技術細節十分複雜，今天我們僅僅從叢集架構來看看應用如何實現高可用。OB的高可用架構在OB4裡變化不大，除了資料庫本身透過Multi-Paxos共識協議實現副本之間的選舉與同步外，OBProxy依然是OB高可用的不可或缺的元件。應用透過本身帶有高可用與負載均衡能力的OBProxy訪問單個或者多個OB叢集，從而實現應用級的高可用。當客戶端透過OBProxy代理連線OBServer的時候，OBProxy需要幫助客戶端維持叢集中的可用性狀態，OBProxy透過多種方式實現探活，並隨時更新黑名單，確保應用的正確訪問。今天簡單的分析一下OB，下週OB4.1的商用版就要釋出了，我們也準備等下週OB 4.1釋出之後對OB4商用版進行試用，屆時我再把測試的情況寫出來和大家分享吧。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/70024923/viewspace-2938572/，如需轉載，請註明出處，否則將追究法律責任。
