[TOC] # 轉儲和合并 ## 轉儲（Minor Compaction） 當 MemTable 的內存使用達到一定閾值時，就需要將 MemTable 中的數據存儲到磁盤上以釋放內存空間，這個過程稱之為“轉儲”。在轉儲之前首先需要保證被轉儲的 MemTable 不再進行新的數據寫入，這個過程稱之為“凍結”（Minor Freeze），凍結會阻止當前活躍的 MemTable 再有新的寫入，并同時生成新的活躍 MemTable。 在對凍結 MemTable 進行轉儲時，會掃描凍結 MemTable 中的數據行，并將這些數據行存儲到 SSTable 中，當一條數據被多個不同事務反復修改時，可能會有多個不同版本的數據行存儲到轉儲 SSTable 中。 轉儲發生在 MemTable 的大小滿足一定條件時，任何分區副本可以獨立決定凍結當前 MemTable，并轉儲到磁盤上。轉儲出的 SSTable 只與相同大版本的增量數據做數據歸并，不與全局靜態數據合并。這樣設計是基于增量數據遠小于全局數據的考慮，使得轉儲會比較快。 ## 轉儲觸發 轉儲有兩種觸發方式：自動觸發與手動觸發。 當一個租戶的 MemTable 內存使用量達到`memstore_limit_percentage`時，就會自動觸發轉儲。您也通過以下的運維命令手動觸發轉儲。 ~~~ ALTER SYSTEM MINOR FREEZE [zone] | [server_list] | [tenant_list] | [replica] tenant_list: TENANT [=] (tenant_name_list) tenant_name_list: tenant_name [, tenant_name ...] replica: PARTITION_ID [=] 'partition_idx%partition_count@table_id' server_list: SERVER [=] ip_port_list ~~~ 示例： ~~~ /*集群級別轉儲 */ alter system minor freeze; /*Server 級別轉儲 */ alter system minor freeze server='192.168.1001:2882' /*租戶級別轉儲 */ alter system minor freeze tenant='prod_tenant' /*Replica 級別轉儲 */ alter system minor freeze alter partition_id = '8%1@1099511627933' ~~~ 需要注意的是，盡管允許只針對單個分區手動觸發 Minor Freeze，但由于多個不同的分區可能共用相同的內存塊，因此對單個分區的 Minor Freeze 可能并不能有效地釋放內存，而針對租戶的 Minor Freeze 可以有效地釋放對應租戶 MemTable 的內存。 ## 合并（Major Compaction） 合并操作（Major Compaction）是將動靜態數據做歸并，會比較費時。當轉儲產生的增量數據積累到一定程度時，通過 Major Freeze 實現大版本的合并。 轉儲和合并的最大區別在于，合并是集群上所有的分區在一個統一的快照點和全局靜態數據進行合并的行為，是一個全局的操作，最終形成一個全局快照。 轉儲和合并的對比如下表所示： <table data-tag="table" id="table-17j-uy2-8t8" class="table"><colgroup width="350" span="1" data-tag="col" id="col-sju-ivx-mwe" colwidth="1*" colnum="1" colname="col1" style="width:50%" class="col"></colgroup><colgroup width="372" span="1" data-tag="col" id="col-phn-ocb-qxh" colwidth="1*" colnum="2" colname="col2" style="width:50%" class="col"></colgroup><thead id="thead-dre-uh8-raj" class="thead"><tr id="tr-ibl-siw-mmm"><th id="td-dsv-vma-x7l"><p id="p-l1j-2ca-z73"><b>轉儲（</b>Minor Compaction<b>）</b></p></th><th id="td-eze-ydb-wcq"><p id="p-p80-a8r-2hb"><b>合并（Major </b>Compaction<b>）</b></p></th></tr></thead><tbody data-tag="tbody" id="tbody-zmi-8ql-m0j" class="tbody"><tr data-tag="tr" id="tr-u48-6mk-joa" class="tr"><td data-tag="td" id="td-xiz-njk-0ov" class="td"><p data-tag="p" id="p-2c6-z7q-kw8" class="p">Partition 或者租戶級別，只是 MemTable 的物化。</p></td><td data-tag="td" id="td-gru-762-k96" class="td"><p data-tag="p" id="p-91a-8ny-31z" class="p">全局級別，產生一個全局快照。</p></td></tr><tr data-tag="tr" id="tr-vzr-mdg-kta" class="tr"><td data-tag="td" id="td-qlz-jyr-k63" class="td"><p data-tag="p" id="p-vnm-124-qo2" class="p">每個 OBServer 的每個租戶獨立決定自己 MemTable 的凍結操作，主備分區不保持一致。</p></td><td data-tag="td" id="td-w41-yrk-g9h" class="td"><p data-tag="p" id="p-d7k-tye-gvo" class="p">全局分區一起做 MemTable 的凍結操作，要求主備 Partition 保持一致，在合并時會對數據進行一致性校驗。</p></td></tr><tr data-tag="tr" id="tr-xh5-05d-kze" class="tr"><td data-tag="td" id="td-3if-ozl-feu" class="td"><p data-tag="p" id="p-e53-a6c-ez0" class="p">可能包含多個不同版本的數據行</p></td><td data-tag="td" id="td-53t-mx0-gxv" class="td"><p data-tag="p" id="p-iul-9p8-m7q" class="p">只包含快照點的版本行</p></td></tr><tr data-tag="tr" id="tr-hyd-cg2-b0v" class="tr"><td data-tag="td" id="td-sxz-wjb-a7e" class="td"><p data-tag="p" id="p-a01-nv3-fc4" class="p">轉儲只與相同大版本的 Minor SSTable 合并，產生新的 Minor SSTable，所以只包含增量數據，最終被刪除的行需要特殊標記。</p></td><td data-tag="td" id="td-xmk-zj2-r6x" class="td"><p data-tag="p" id="p-off-yer-uyc" class="p">合并會把當前大版本的 SSTable 和 MemTable 與前一個大版本的全量靜態數據進行合并，產生新的全量數據。</p></td></tr></tbody></table> 合并有很多種不同的方式，具體的描述如下。 **全量合并** 全量合并是 OceanBase 數據庫的一種合并算法，和 HBase 與 Rocksdb 的 Major Compaction 過程是類似的。顧名思義，在全量合并過程中，會把當前的基線數據都讀取出來，和增量數據合并后，再寫到磁盤上去作為新的基線數據。在這個過程中，會把所有數據都重寫一遍。全量合并會極大的耗費磁盤 IO 和空間，如非必要或者 DBA 強制指定，OceanBase 數據庫一般不會主動做全量合并。 OceanBase 數據庫發起的全量合并一般發生在列類型修改等 DDL 操作之后。DDL 變更是實時生效的，不阻塞讀寫，也不會影響到多副本間的 Paxos 同步，將對存儲數據的變更延后到合并的時候來做，這時就需要將所有數據重寫一遍。 **增量合并** 增量合并是相對于全量合并而言的概念，同樣是 OceanBase 數據庫的一種合并算法。大多數情況下，當需要進行合并時并不是所有的宏塊都需要被修改，當一個宏塊沒有增量修改時，直接重用它，而不是重寫它，這種方式稱之為增量合并。相對于全量合并的把所有的宏塊的重寫一邊而言，增量合并只重寫發生了修改的宏塊。增量合并極大地減少了合并的工作量，也是 OceanBase 數據庫目前默認的合并算法。 更進一步地，對于宏塊內部的微塊，很多情況下也并不是所有的微塊都會被修改。當發現宏塊有行被修改過時，在處理每一個微塊時，會先判斷這個微塊是否有行被修改過，如果沒有，只需要把這個微塊的數據直接拷貝到新的宏塊上，這樣沒被修改過的微塊就省去了解析行、選擇編碼規則、對行進行編碼以及計算列 Checksum 等操作。微塊級增量合并進一步減少了合并的時間。 **漸進合并** 在執行某些 DDL 操作時，例如執行表的加列、減列、修改壓縮算法等操作后，可能需要將數據重寫一遍。OceanBase 數據庫并不會立即對數據執行重寫操作，而是將重寫動作延遲到合并時進行。基于增量合并的方式，無法完成對未修改數據的重寫，為此 OceanBase 數據庫引入了“漸進合并”，即把數據的重寫分散到多次合并中去做，在一次合并中只進行部分數據的重寫。 通過以下命令可以控制一張表的漸進輪次： ~~~ ALTER TABLE [table_name] set default_progressive_merge_num=? ~~~ 例如： ~~~ obclient> ALTER TABLE mytest set default_progressive_merge_num=60; ~~~ 將表`mytest`的漸進輪次設置為`60`，當執行加列或減列操作后的 60 次合并過程中，每一次合并會重寫 60 分之一的數據，在 60 輪合并過后，數據就被整體重寫了一遍。 當未對表的`progressive_merge_num`進行設置時，其默認值為`0`，目前語義為在執行需要重寫數據的 DDL 操作之后，做漸進輪次為 100 的漸進合并。當表的`progressive_merge_num`被設置為 1 時，表示強制走全量合并。 **輪轉合并** 一般來說合并會在業務低峰期進行，但并不是所有業務都有業務低峰期。在合并期間，會消耗比較多的 CPU 和 IO，此時如果有大量業務請求，勢必會對業務造成影響。為了規避合并對業務的影響。借助 OceanBase 數據庫的多副本分布式架構，引入了輪轉合并的機制。 一般配置下，OceanBase 數據庫會同時有 3 個數據副本，當一個數據副本在進行合并時，可以將這個副本上的查詢流量切到其他沒在合并的集群上面，這樣業務的查詢就不受每日合并的影響。等這個副本合并完成后，再將查詢流量切回來，繼續做其他副本的合并，這一機制稱之為輪轉合并。 為了避免流量切過去后，Cache 較冷造成的 RT 波動，在流量切換之前，OceanBase 數據庫還會做 Cache 的預熱，通過參數可以控制預熱的時間。 **合并觸發** 合并觸發有三種觸發方式：自動觸發、定時觸發與手動觸發。 * 當集群中任一租戶的 Minor Freeze 次數超過閾值時，就會自動觸發整個集群的合并。 * 也可以通過設置參數來在每天的業務低峰期定時觸發合并。 ~~~ obclient> ALTER SYSTEM SET major_freeze_duty_time = '02:00'; ~~~ * 也通過以下的運維命令手動觸發合并。 ~~~ obclient> ALTER SYSTEM MAJOR FREEZE; ~~~