淺析Cassandra LeveledCompactionStrategy

前言

Cassandra是基於LSM架構的分佈式數據庫。LSM中有一個很重要的過程，就是壓縮（Compaction）。默認的壓縮策略是SizeTieredCompactionStrategy，今天主要說一下另外一種壓縮策略LeveledCompactionStrategy。

LeveledCompactionStrategy

LeveledCompactionStrategy被用在讀密集的場景，讀操做的延遲相對容易估算（最壞狀況讀的文件數量能夠肯定），舊數據能夠更快被淘汰。缺點是會有更多的磁盤IO消耗，可能會影響到讀寫操做延遲。

這個壓縮算法主要是將數據分級(L0,L1,L2……)。最開始數據在內存（memtable）裏，而後被flush到磁盤上，也就是到了L0這級。L0的sstable會和L1的合併成更大的sstable。

增長SSTable：

大於L1的層級，sstable都被合併成大於或等於sstable_size_in_mb（默認：160MB）。超過L0的層級，建立的sstable大小都大體相同。每一個層級之間數據量是10倍的關係，即L2的數據量是L1的10倍。咱們假設L1能夠容納10*160MB，那麼L2能夠容納100*160MB。若是在L1作壓縮，結果大於10，會被移動到L2.

很是屢次寫入後：

LCS compaction會保證從L1開始沒有重複數據。因此對於讀操做來講，只要檢索1個或者2個sstable就能查到數據（L0 + LN）。事實上，90%的讀操做都只須要讀取1個sstable。因爲L0是不壓縮的，若是大量讀請求集中在L0，任然可能致使大量讀IO消耗。

LCS compaction發生的會更頻繁，會消耗更多IO。若是是寫密集型的，並不適合，由於IO開銷可能大於讀的收益。

更多壓縮策略選擇能夠參考：https://docs.datastax.com/en/dse/6.7/dse-dev/datastax_enterprise/config/configChooseCompactStrategy.html

寫在最後

爲了營造一個開放的Cassandra技術交流環境，社區創建了微信公衆號和釘釘羣。爲廣大用戶提供專業的技術分享及問答，按期開展專家技術直播，歡迎你們加入。另雲Cassandra免費火爆公測中，歡迎試用：https://www.aliyun.com/product/cds

 

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。