操作Cassandra（5）-Compression

壓縮

Cassandra為操作員提供了在每個表上配置壓縮的能力。通過使用者可配置壓縮參數chunk_length_in_kb壓縮SSTable來減小磁盤上的資料大小。因為Cassandra SSTables是不可變的，壓縮的CPU成本隻有在寫入SSTable時才是必要的，随後的資料更新将落在不同的SSTables中，是以Cassandra不需要在釋出UPDATE指令時解壓縮，覆寫和重新壓縮資料。在讀取時，Cassandra将在磁盤上定位相關的壓縮塊，解壓縮完整的塊，然後繼續讀取剩餘的路徑（合并來自磁盤和memtables的資料，讀取修複等）。

壓縮配置

壓縮在每個表上配置了CREATE TABLE或ALTER TABLE的可選參數。預設情況下，三個選項是相關的：

• class指定壓縮類 - Cassandra提供三個類（LZ4Compressor，SnappyCompressor和DeflateCompressor）。預設值為SnappyCompressor。

• chunk_length_in_kb

  指定每個壓縮塊的資料的千位元組數。預設值為64KB。

• crc_check_chance

  确定Cassandra在讀取期間驗證每個壓縮塊上的校驗的可能性。預設值為1.0。

使用者可以使用以下文法設定壓縮：

CREATE TABLE keyspace.table (id int PRIMARY KEY) WITH compression = {'class': 'LZ4Compressor'};
      

或者

ALTER TABLE keyspace.table WITH compression = {'class': 'SnappyCompressor', 'chunk_length_in_kb': 128, 'crc_check_chance': 0.5};
      

啟用後，可以使用ALTER TABLE語句設定enable為false來禁用壓縮：

ALTER TABLE keyspace.table WITH compression = {'enabled':'false'};
      

然而，操作者應該意識到，改變壓縮不是立即的。當SSTable被寫入時，資料被壓縮，并且由于SSTables是不可變的，是以在表被壓縮之前不會修改壓縮。在通過ALTER TABLE發出對壓縮選項的更改時，現有SSTables将不會被修改，直到它們被壓縮 - 如果操作員需要壓縮更改立即生效，操作員可以使用nodetool scrub或nodetool upgradeesstables觸發SSTable重寫，兩者都将重建磁盤上的SSTables，重新壓縮過程中的資料。

好處和用途

壓縮的主要好處是它減少了寫入磁盤的資料量。不僅減小的大小節省了存儲需求，它經常增加讀取和寫入吞吐量，因為壓縮資料的CPU開銷比從磁盤讀取或寫入更大量的未壓縮資料所需的時間更快。

壓縮在包含許多行的表中最有用，其中行在本質上是類似的。包含類似文本列（如重複的JSON blob）的表格通常壓縮得很好。

操作影響

• 壓縮後中繼資料存儲在堆外，并與磁盤上的資料進行比較。每TB資料在磁盤上通常需要有1-3GB的堆外RAM，精确的數值随chunk_length_in_kb和壓縮比而變化。
• 流操作涉及在壓縮表上壓縮和解壓縮資料 - 在一些代碼路徑（例如非vnode引導）中，壓縮的CPU開銷可能是一個限制因素。
• 壓縮可以校驗資料以確定正确性 - 而傳統的Cassandra讀取無法確定磁盤上資料的正确性，壓縮表允許使用者設定crc_check_chance（從0.0到1.0的浮點數）來讓Cassandra進行機率驗證磁盤上的位塊是否損壞。

進階用法

進階使用者可以通過實作org.apache.cassandra.io.compress.ICompressor上的接口來提供自己的壓縮類。