LSM 优化系列(二)-- dCompaction: Speeding up Compaction of the LSM-Tree via Delayed Compaction
文章目錄
- 背景描述
- dCompaction設計
- 觸發條件 VCT
- 觸發VT 合并的條件 VSMT
- 測試數據
優化的重心集中在減少寫放大上,同時將讀性能維持在和rocksdb 原生讀性能接近,優化思想是中國科學院的2位博士 提出的。
論文原地址:
dCompaction: Speeding up Compaction of the LSM-Tree via Delayed Compaction
背景描述
關于LSM的問題,這里不多介紹,有興趣的同學可以看看之前 總結的相關優化論文的描述:
1. PebblesDB Building Key-Value Stores using FLSM-Tree(Fragmented) SOSP‘17
2. X-Engine: An Optimized Storage Engine for
Large-scale E-commerce Transaction Processing SIGMOD’19
論文中 通過YSCB 構造的workload 來統計 三種類型的操作造成的IO:Compaction, Get, Put.
如下圖:
其中IO操作主要是由compaction 造成的,而讀IO僅僅會由讀的比例的增加而增加,且最大不會超過 總的IO的20%,也就是大部分IO操作都是由Compaction造成的。
再通過分析Compaction的實現 如下圖:
可以發現實際compaction過程中針對同一個key可能會寫入多次,比如C2–>C3 compaction,會將選擇的C3的文件經過合并再次寫入到C3之中,這就是寫放大的源頭。
dCompaction設計
為了減少寫放大,dCompaction核心設計了 virtual compaction 和 virtual SSTables,如下圖:
compaction過程中 內存里維護virtual sstables ,之間以樹狀結構來管理實際的real stabiles。virtual sstables 包含如下幾種類型的元數據:
- smallest key
- largest key
- file number
- file size
- Parent SStables
相比于實際的real sstables 多了一個parent SStables,用來管理實際的sst文件
dCompaction 實際的過程如下圖
原本的Compaction實現:
-
T22@L2 + T32,T33@L3 --> T34,T35,T36@L3
-
T34,T35,T36@L3 + T42,T43@L4 --> T44,T45,T46,T47,T48@L4
也就是T34,T35,T36中的key-value會被多讀、多寫一次
dCompaction實現:
-
T22@L2 + T32,T33@L3 --> VT34,VT35,VT36@L3
這一步僅僅將實際的sstable中的元數據讀上來,在內存中構造 virtual table,合并real table的元數據,從而完成virtual compaction。不需要對T34,T35,T36中的數據多讀寫一次。
-
VT34,VT35,VT36@L3 + VT42,VT43@L4 --> T44,T45,T46,T47,T48@L4
這一步通過L3的virtual table + L4的virtual table 完成一次real compaction。
通過dCompaction,將實際T22@L2 + T32,T33@L3 + T22@L2 + T32,T33@L3 + T42,T43@L4 --> T44,T45,T46,T47,T48@L4
降低為T22@L2 + T32,T33@L3 + T42,T43@L4 --> T44,T45,T46,T47,T48@L4
所有的key-value僅僅只需要產生一次IO操作即可,能夠有效得降低讀寫放大,提升寫性能。
但是這個過程 對讀性能有影響。dCompaction 下的讀 和 原生rocksdb的讀 流程對比如下圖:
實際的讀在有virtual table的情況下會有如下幾步:
- 讀memtable
- 讀block cache
- 讀virtual table
- 確認key是在VT smallest – largest key之間
- 讀Parent sstables
- 從實際的T 中讀取key-value
相比于從實際的T中直接讀取 多了兩步。
觸發條件 VCT
VCT定義了一個閾值用來控制當前compaction是virtual compaction還是real compaction,觸發算法如下:
-
compaction開始
-
選擇需要被合并的 sst files
-
sst files 計數
-
Count = sst files 計數
-
如果 Count < VCT
? 觸發virtual compaction
否則
? 觸發real compaction
如果VCT 被設置為0,那么默認就是real compaction;
隨著VCT被設置的數值不斷增加,virtual compaction會觸發得越來越頻繁,compaction產生的IO會降低,但是VCT 越大,并不代表系統性能越好。
- 這其實也是變相的compaction delay,virtual compaction進行的越多,單次real compaction的量會越大,這一次的 real compaction會將系統的性能拖到低谷。
- Virtual compaction越多,real ssttables 也會越多,這其實會增加讀延時,從而降低讀性能。
所以VCT的值需要做一個實際的測試來平衡real compaction 和 sst files 計數 compaction
觸發VT 合并的條件 VSMT
這個閾值主要是用來控制一個virtual sstables 能夠包含多少real sstables,如果讀的過程中發現virtual sstables的real sstables 超過了這個閾值,就對當前virtual sstables進行合并。
這個參數主要是為了 降低 的讀請求命中VT 的時 對讀性能的影響。
比如讀請求命中 VT34,發現其中的real sstables 的個數超過VSMT,那么觸發VT的合并。
將VT34 管理的三個real sstables T22,T32,T33都讀到內存中,合并為T34,T35,T36。
同理 其他的VT35,VT36 也需要合并到T35,T36。這個過程其實是對IO帶寬的一種浪費,但是VT merge 能夠減少查找時的IO,提升讀性能。
實際的合并算法:
-
如果 sstable.type == virtaul sstable
? 2. 計算VT中有多少個real sstables
? 3. Count = the number of real sstables
? 4. 如果 Count >= VSMT
? 合并virtual sstable 到real sstables
實際VSMT 也不能隨意設置,否則同樣會對性能有很大的影響。
如果VSMT設置的過小,VT merge會很頻繁,將增加合并過程中的IO消耗(需要讀到內存,合并 并寫入)。為了降低一部分讀延時,缺增加了dCompaction對讀寫放大的優化效果。
而如果VSMT設置的過大,VT 得不到合并,同樣無法達到提升讀性能的效果。
測試數據
硬件如下:
CPU: Intel Xeon E5645 (6core,2.4GHz, 12MB L3 cache)
DRAM:2GB
2 * 1TB SATA hdd( 平局尋道時間/旋轉延時 : 8.5 ms/4.2 ms, 傳輸帶寬:150M/s)
1 * 480GB SATA intel ssd (平均讀/寫延時:80 μs/85 μs, 平均讀/寫帶寬:550/520 MB/s)
rocksdb 配置 都是默認的配置,dCompaction的VCT 是12, VSMT 是5。
使用YCSB 按照讀寫比,生成的workload。
和開頭提到的 dCompaction的目標集中在減少寫放大,保證讀性能。
如下圖為四種workload下的測試情況:
D1: (2.4×10^7, 1, 0, 256 B, 6 GB),
D2: (2.4×10^7, 0.8, 0.2, 256 B, 5 GB),
D3: (2.4×10^7, 0.2, 0.8, 256 B, 2 GB),
D4: (2.4×10^7, 0, 1, 256 B, 6 GB)
其中 D(O, W, R, V, S) 為數據集的描述,O表示操作次數,W 表示寫占的比例,R 表示讀占的比例,V 表示value siz,S 表示總的數據集大小。
如上圖可以看到 dCompaction的實現對整體的寫性能有很大的提高,同時也有不弱于rocksdb的讀性能。
后續還有更加詳細的性能數據,相同數據量下兩種compaction產生的IO量對比,讀寫延時對比,不同數據集對性能的影響 以及 VCT和VSMT 指標對性能的影響。
總結
以上是生活随笔為你收集整理的LSM 优化系列(二)-- dCompaction: Speeding up Compaction of the LSM-Tree via Delayed Compaction的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 星之守护者索拉卡是谁画的呢?
- 下一篇: Rocksdb 的 rate_limit