技術分享 | LSM-Tree 和 OceanBase 分層轉儲

一、LSM-Tree

• Memt

  able
  : 常駐記憶體的 KV 查詢樹  +

  無序的 WAL 檔案
• SS

  Table (Sorted Strin

  g Table)
  : 一組儲存在磁碟的不可變檔案，儲存有序的鍵值對

  
  

寫入流程

1、同步寫 Memtable

2、非同步寫 SSTable

• 第 i 層所有檔案均由 i - 1 層的 SSTable 合併排序而來，可以透過設定閾值（檔案個數...）來控制合併的行為

• 檔案之間是有序的，且每個檔案的 key 集合不會與其他檔案有交集（Level 0 的 SSTable 除外）

Compaction 策略

常用的 Compaction 策略有 Classic Leveled、Tiered、Tiered & Leveled 、FIFO 等，簡單介紹下前3種。

1、Classic Leveled

2、Tiered

3、Tiered & Leveled

Tiered & Leveled 模式是指對於層級較小的 Level ，資料量比較小，寫入的資料較新，被更新的可能性比較大，使用 Size-Tiered 模式減少寫放大問題；對於層級較大的 Level ， SSTable 的資料量較大，資料比較舊不太容易被更新，使用 Leveled 模式減少空間放大問題。

二、OceanBase 的分層轉儲

Mini Compaction (轉儲)

Minor Compaction

1、L0 -> L0

2、L0 - > L1

Leveled 型別的 Compaction，將若干個 Mini SSTable 與 Minor SSTable 合成一個新的 Minor SSTable，放置於 L1 層。對應的型別是 MINOR_MERGE

實驗（使用社群版 OceanBase 4.0.0.0）

memstore_limit_percentage = 50
freeze_trigger_percentage = 20
minor_compact_trigger = 2
_minor_compaction_amplification_factor = 25
major_compact_trigger = 9999  （我們本次實驗僅是想>探索L0、L1級的Compaction，不希望觸發大合併，所以該引數設定一個極大值）

實驗一：在持續資料流的情況下，觀測L0, L1層轉儲的時機

租戶每觸發一次轉儲 memtable dump flush 的資料必然是包含許多表的，我這裡只建立1張業務表，僅是希望後續測試時業務變更相對集中

sysbench /usr/share/sysbench/oltp_insert.lua --mysql-host=172.30.134.1 --mysql-db=sysbench  --mysql-port=2881 --mysql-user=root@ob_bench  --tables=1 --table_size=1000000 --report-interval=10 --db-driver=mysql --skip-trx=on --db-ps-mode=disable --create-secondary=off --mysql-ignore-errors=6002,6004,4012,2013,4016 --threads=10 --time=600  prepare

先透過檢視 DBA_OB_TABLE_LOCATIONS 找到 sbtest1 對應的 TABLET_ID ，然後透過 GV$OB_TABLET_COMPACTION_HISTORY 查詢到在建立100W資料過程中，已經觸發了4次 MINI_MERGE 和1次 MINI_MINOR_MERGE

3、對 sbtest1 持續的寫資料，觀測 sbtest1 表級的轉儲情況

sysbench /usr/share/sysbench/oltp_insert.lua --mysql-host=172.30.134.1 --mysql-db=sysbench  --mysql-port=2881 --mysql-user=root@ob_bench  --tables=1 --table_size=1000000 --report-interval=10 --db-driver=mysql --skip-trx=on --db-ps-mode=disable --create-secondary=off --mysql-ignore-errors=6002,6004,4012,2013,4016 --threads=10 --time=600  run

測試總結：

如上測試時我們設定的 minor_compact_trigger = 2 ，按理解在每兩次觸發 MINI_MERGE 之後，就會觸發一次 MINOR_MERGE ，把L0層的 SSTable 下壓到L1層。實際測試下來發現未必如此，當達到 minor_compact_trigger 的閾值後，必然會觸發 Minor Compaction ，但它可能是L0層上的 MINI_MINOR_MERGE（同層資料合併），也可能是L0->L1層的 MINOR_MERGE（資料下壓到下一層）。但是具體什麼情況下，觸發哪種 Minor Compaction ，在官方文件只是介紹會受隱藏引數_minor_compaction_amplification_factor控制，但是具體如何影響的 也並沒有給到相應的觀測手法。

實驗二：alter system minor freeze 是否真的在L1層做一個 MINOR_MERGE 型別的 compaction ？

1、同實驗一的引數配置，且minor_compact_trigger = 2

先對sbtest1表記錄做一次update，然後手動執行 alter system minor freeze ;（因為我們實驗觀測的是指定表的 merge 情況，所以在 minor freeze 之前要做一次 update 操作，主要是保證 memtable 中有對該表操作的記錄）

我們再執行一次 alter system minor freeze ;

2、同實驗一的引數配置，但設定 minor_compact_trigger = 0

同樣是多次執行 alter system minor freeze ，每次執行後觀察 merge 情況。

測試總結：

透過實驗二的測試我們發現，alter system minor freeze 真正做的是形成一個 mini sstable (MINI_MERGE) ，在 MINI_MERGE 之後是否還會觸發其他的 merge ，同樣是受引數 minor_compact_trigger 和 _minor_compaction_amplification_factor 的控制。並且指令中的 minor freeze 實際上並不是特別準確，因為看到 minor 總會讓人想到L1層，如果改成 mini freeze 會更合適一些。

參考資料