OceanBase 原始碼解讀（三）：分割槽的一生

引言

原始碼是OceanBase的“方向盤”，本系列主要圍繞“原始碼解讀”，透過文章闡述，幫助大家理清資料庫的內在本質。此前，帶你讀原始碼第二篇《 戳這裡回顧： OceanBase原始碼解讀（二）：SQL的一生 》為大家 介紹了OceanBase 資料庫中一條 SQL 的執行流程主路徑，包括接收、處理、返回結果給客戶端的過程， 探討了OceanBase的SQL引擎模組。

本文為 OceanBase 資料庫原始碼解讀系列文章的第三篇，將主要為大家介紹 OceanBase  的 儲存層像相關知識。

正文

假若分割槽是 OceanBase 的一等公民。一個表由一個或者若干個分割槽組成，分割槽是 OceanBase 邏輯上水平可擴充套件概念和物理上資料組織的基本單位。分割槽是自包含的：每個分割槽有自己獨立的選舉和 leader，獨立的事務日誌、資料儲存和索引。分割槽可大可小，一般大小在 G B量級，它可以被 RS 在多個節點之間排程以實現負載均衡。

每個分割槽有一個唯一標識 OBPartitionKey，由租戶 id、表 id、分割槽 id 組成。從儲存層來說，每個節點就是儲存和組織這些 key 對應的分割槽副本，每個節點上可以有數萬個副本。副本有多種型別，比如只讀副本與主副本之間不是透過 paxos 協議，而是非同步訊息同步事務日誌。

storage/ob_partition_service.h 是儲存層的總入口，它對外提供了儲存層的所有 RPC 服務，如建立刪除分割槽副本。實際上，它是每個節點上所有分割槽級介面的入口，包括事務控制介面、分割槽讀寫的介面等。

前面講過，建表和新增分割槽等 DDL 語句是由 RS 執行的，RS 在根據一定策略選定節點後，就會 RPC 呼叫這裡的 create_xxx。

從這個入口一層一層追下去，可以找到所有儲存結構。但儲存層內部有大量類似的介面，很容易混淆。每個分割槽都是一個“索引組織表”，索引結構是多層的 LSM-Tree。雖然是多層，但是有引數可以調整，儘量只有記憶體裡的 memtable（見storage/memtable）和磁碟上的 major sstable（見 storage/blocksstable）兩層。每次 major compaction 的時候，memtable, minor sstable 的資料與原來的 major sstable 合併，產生新版本的 major sstable。在合併期間，可能有多個版本的 major sstable 同時提供服務。一個分割槽副本的多層儲存結構合起來，就是類 OBPartitionStore。

分析到這裡，大家還以為“分割槽是 OB 的一等公民”嘛嗎？其實PG 才是。此 PG 非彼 PG。PG，Partition Group，表示共享同一個事務日誌流和 memtable 的“有緊密關係的”一組分割槽。外部一般不使用這個特性，一般一個 PG 裡面只有一個分割槽，這就是為什麼這裡的儲存結構和操作物件會有奇怪的pg字首和 OBPGKey了。

為了表達誠意，獻上我畫的儲存結構相關類圖。

一圖勝千言。

sql/engine/table 是 SQL 物理執行計劃中執行表掃描的運算元，它透過 ob_partition_service.h 的 table_scan 介面獲得一個迭代器（迭代結束要呼叫 revert_scan_iter），這就是儲存層提供的資料訪問入口。還有 DML（sql/engine/dml）使用的insert_rows, delete_rows, update_rows和lock_rows 等介面。

當分割槽或表被刪除的時候，OBPGPartition 及其所有包含的儲存結構將被刪除。但是並非立即釋放資源，要等所有引用失效且資源不被使用時執行清理。

以上便是分割槽的一生。 在後續的原始碼解讀第四篇我們將會為大家解析 OceanBase 資料庫事務的外部介面，敬請期待。