開源分布式Key-Value存儲系統 Cassandra 新特性：分層壓縮

Cassandra的 數據模型借鑒自Google的BigData模型，簡單來說就是將寫操作放在一個內存塊中，當內存塊大小達到一定大小時，將內存中的數據排序后寫成一個 sstable文件，而這種方式會有一些問題，而前段時間Google的Chromium團隊開發的一個開源的key-value存儲以其分層壓縮機制給了大家一種新的思路，Cassandra也適時的將這種思路引入到Cassandra中，也就是今天我們要介紹的Cassandra的分層壓縮。

目前的壓縮機制：Tiered Compaction

在講分層壓縮之前，我們先來看一下Cassandra目前的數據存儲模型和數據壓縮機制。

像我們上面說的一樣，Cassandra在內存數據達到一定大小時，會將數據排序寫入磁盤生成一個sstable文件塊，當第一級的sstable 數目達到四個時，由于這四個sstable相當于是按時間劃分的一段時間的數據快照，所以這四個塊中會有一些相同的數據。我們將這四個sstable會進 行合并壓縮，就可憎減小空間。具體過程如下圖所未：

上圖綠色塊就表示一個sstable，當第一級的sstable達到四個，就會合并成一個新的第二級的sstable。當然，當第二級的 sstable也達到四個，就會再進行合并生成第三級的sstable，以此類推。如果下圖所未，當一二三四級sstable都已經有三個，可能這個合并 就會一直進行下去。

由于sstable之間可能有重復的數據，也就是同一個數據的不同版本可能存在在多個sstable中，所以上面的方式在更新比較頻繁的系統中，可能會有下面一些問題：

• 第一是性能的影響，由于一條記錄可能存在在多個sstable中，最BT的情況下可能某一條記錄會存在在所有sstable中，所以具體需要合并多個少sstable才能保證一條記錄在所有sstable中只存了一次就變得不太確定了。
• 這種方式在存儲空間上也比較浪費，因為一個被刪除的記錄可能的老版本可能會一直存在在一些老的sstable中，直到進行一次完整的合并才行。這對于一個經常會有刪除操作的系統來說會造成空間的極大浪費。
• 在不怎么刪除的系統上，也會造成一些空間的浪費，最壞的情況下，如果一條記錄都沒有重復，那么合并操作實際上完全是浪費時間，合并后的數據大小和合并前相比不會變，但是合并操作本身會需要和當前數據集一樣大的空間成本。

新的壓縮機制：Leveled Compaction

新的壓縮機制借鑒自LevelDB， 這種機制最大的特點在于其同一層的各個sstable之間不會有重復的數據。所以在某一層和它上一層的數據塊進行合并時，可以明確的知道某個key值處在 哪個數據塊中，可以一個數據塊一個數據塊的合并，合并后生成新塊就丟掉老塊。不用一直到所有合并完成后才能刪除老的塊。

另外，新的分層式壓縮方式將數據分成條個層，最底層的叫L0，其上分別是L1，L2….，每一層的數據大小是其上的那一層數據最大大小的10倍，其中最底層L0的大小為5M

如下圖所未，當淺綠色的L0塊生成時，它會馬上和L1層的數據進行合并，并生成新的L1塊（藍色塊），當L1的塊越來越多，大于這一層的最大大小時，這些塊又會和L2層的數據進行合并并生新的L2層的塊（紫色塊）

可以這樣理解，層級越小的塊，其保存的數據越少，也越新，比如L0層保存的就是最新的數據版本，但是其只會保存5M數據，其上的L1層會保存50M數據，但是并不是最新的。當一個系統運行的時間足夠長，那么其數據結構可能會如下圖所未：

這種方式的優點是塊之間沒有重復數據，帶來的好處就是在合并操作的時候，并不需要掃描一層中的所有數據塊。合并的開銷變小了。具體能夠保證以下一些優點：

• 可以保證90%的讀操作只需要對一個sstable進行隨機讀操作。而最壞情況下，也能保證讀操作最大只會等于層數，如果10T數據的話，也只有七層，只需要七次隨機讀操作。
• 在空間利用上，可以保證最多只有10%的空間會浪費在無用數據上。
• 在壓縮合并操作的開銷上，也最多只會使用10倍于sstable大小的空間。

你可以通過在創建Column Family時指定compaction_strategy參數為LeveledCompactionStrategy來使用新的分層壓縮策略。

當然，這種策略也不是萬能的，對于一個更新操作和刪除操作比較多的系統，使用分層壓縮是比較合適的。因為這種系統會產生同一份數據的多個版本。但是由于這種壓縮會在壓縮中進行更多的IO操作，所以如果是一個主要是insert操作的系統，建議不要使用分層壓縮方法。