壓縮
Cassandra 提供操作員按表格設定壓縮的功能。壓縮會透過壓縮 SSTable 中的使用者可設定壓縮 chunk_length_in_kb，來縮小磁碟上的資料大小。由於 Cassandra SSTable 不可變更，因此壓縮的 CPU 成本僅在寫入 SSTable 時需要 - 後續的資料更新會寫入不同的 SSTable，因此 Cassandra 在發出 UPDATE 指令時不需要解壓縮、覆寫和重新壓縮資料。在讀取時，Cassandra 會在磁碟上找到相關的壓縮區塊，解壓縮整個區塊，然後繼續執行讀取路徑的其餘部分（合併磁碟和記憶表中的資料、讀取修復等）。
壓縮演算法通常會在以下三個領域之間進行權衡
-
壓縮速度：壓縮演算法壓縮資料的速度。這在快取和壓縮路徑中很重要，因為資料必須在寫入磁碟之前壓縮。
-
解壓縮速度：壓縮演算法解壓縮資料的速度。這在讀取和壓縮路徑中很重要，因為資料必須從磁碟讀取整個區塊，然後才能解壓縮並傳回。
-
比例：未壓縮資料減少的比例。Cassandra 通常將其衡量為磁碟上資料大小相對於未壓縮大小的比例。例如，
0.5的比例表示磁碟上的資料大小為未壓縮資料大小的 50%。Cassandra 將此比例顯示為每個表格的nodetool tablestats的SSTable Compression Ratio欄位。
Cassandra 預設提供五種壓縮演算法，在這些領域中進行不同的權衡。雖然壓縮演算法的基準測試取決於許多因素（演算法參數，例如壓縮等級、輸入資料的可壓縮性、底層處理器類別等），但下表應有助於您根據應用程式的需求選擇起點，並根據這些領域的效能粗略評分不同的選擇（A 相對較好，F 相對較差）
| 壓縮演算法 | Cassandra 類別 | 壓縮 | 解壓縮 | 比率 | C* 版本 |
|---|---|---|---|---|---|
|
A+ |
A+ |
C+ |
|
|
|
C+ |
A+ |
B+ |
|
|
|
A- |
A- |
A+ |
|
|
|
A- |
A |
C |
|
|
|
C |
C |
A |
|
一般來說，對於效能至關重要的應用程式（延遲或處理量），LZ4 是正確的選擇，因為它能以極佳的比率消耗 CPU 週期。這就是它成為 Cassandra 中預設選項的原因。
然而，對於儲存至關重要的應用程式（磁碟空間），Zstd 可能會是更好的選擇，因為它能為 LZ4 獲得顯著的額外比率。
Snappy 保留以維持向後相容性，而 LZ4 通常會更受青睞。
Deflate 保留以維持向後相容性，而 Zstd 通常會更受青睞。
設定壓縮
壓縮會在每個表格的基礎上設定，作為 CREATE TABLE 或 ALTER TABLE 的選用引數。所有壓縮器都有三個可用的選項
-
class（預設：LZ4Compressor）：指定要使用的壓縮類別。兩個「快速」壓縮器是LZ4Compressor和SnappyCompressor，兩個「良好」比率壓縮器是ZstdCompressor和DeflateCompressor。 -
chunk_length_in_kb（預設：16KiB）：指定每個壓縮區塊的資料千位元組數。這裡的主要權衡是，較大的區塊大小會為壓縮演算法提供更多內容，並改善其比率，但需要讀取才能解除序列化並從磁碟讀取更多資料。
LZ4Compressor 支援下列額外選項
-
lz4_compressor_type（預設fast）：指定我們是否應該使用high（又稱LZ4HC）比率版本或fast（又稱LZ4）版本的LZ4。high模式支援可設定的層級，這可讓操作員透過lz4_high_compressor_level選項調整效能 <→ 比率權衡。請注意，在4.0及以上版本中，最好使用Zstd壓縮器。 -
lz4_high_compressor_level（預設9）：介於1到17（含）之間的數字，表示花費多少 CPU 時間嘗試取得更高的壓縮比。通常較低層級會「較快」，但壓縮比較低，而較高層級會較慢，但壓縮比較高。
ZstdCompressor 另外支援下列選項
-
compression_level（預設3）：介於-131072到22（含）之間的數字，表示花費多少 CPU 時間嘗試取得更高的壓縮比。層級愈低，速度愈快（但壓縮比愈低）。20 到 22 的值稱為「超高層級」，應謹慎使用，因為它們需要較多記憶體。預設值3適合與Deflate壓縮比競爭，而1適合與LZ4競爭。
使用者可以使用下列語法設定壓縮
CREATE TABLE keyspace.table (id int PRIMARY KEY)
WITH compression = {'class': 'LZ4Compressor'};或
ALTER TABLE keyspace.table
WITH compression = {'class': 'LZ4Compressor', 'chunk_length_in_kb': 64};啟用後，可以使用 ALTER TABLE 將 enabled 設定為 false 來停用壓縮
ALTER TABLE keyspace.table
WITH compression = {'enabled':'false'};不過，操作員應注意，變更壓縮並非立即生效。資料會在寫入 SSTable 時進行壓縮，而由於 SSTable 不可變更，因此在壓縮表之前，壓縮不會變更。透過 ALTER TABLE 發布變更壓縮選項後，現有的 SSTable 必須壓縮後才會變更 - 如果操作員需要壓縮變更立即生效，操作員可以使用 nodetool scrub 或 nodetool upgradesstables -a 觸發 SSTable 重寫，這兩個指令都會在磁碟上重建 SSTable，並在過程中重新壓縮資料。
其他選項
-
crc_check_chance（預設：1.0）：決定 Cassandra 在讀取時驗證每個壓縮區塊上檢查碼的機率，以防止資料毀損。除非您有設定檔指出這是一個效能問題，否則強烈建議不要關閉此選項，因為這是 Cassandra 唯一防止資料毀損的防護措施。在 Cassandra 的早期版本中，壓縮設定檔中存在這個選項的複本。後者已在 Cassandra 3.0 中標示為不建議使用，並在 Cassandra 5.0 中移除。
效益和用途
壓縮的主要效益是減少寫入磁碟的資料量。縮小的尺寸不僅節省儲存空間，還經常增加讀取和寫入的處理量，因為壓縮資料的 CPU 負載比從磁碟讀取或寫入大量未壓縮資料所需的時間還要快。
壓縮在包含許多列的表格中特別有用，其中列的性質相似。包含相似文字欄位的表格（例如重複的 JSON blob）通常可以壓縮得很好。包含已壓縮資料或隨機資料（例如基準資料集）的表格通常無法壓縮得很好。
營運影響
-
壓縮的元資料儲存在堆外，並隨著磁碟上的資料進行調整。這通常需要每 TB 磁碟資料 1-3 GB 的堆外 RAM，儘管確切的用量會隨著
chunk_length_in_kb和壓縮比而有所不同。 -
串流作業涉及壓縮和解壓縮壓縮表格中的資料 - 在某些程式碼路徑（例如非 vnode 引導程式）中，壓縮的 CPU 負擔可能會成為限制因素。
-
為了防止緩慢的壓縮器（
Zstd、Deflate、LZ4HC）過久地封鎖快取，所有三個快取都使用預設的快速LZ4壓縮器進行快取，然後依賴正常的壓縮將資料重新壓縮成所需的壓縮策略。請參閱 CASSANDRA-15379 以取得更多詳細資訊。 -
壓縮路徑會對資料進行檢查和驗證以確保正確性 - 雖然傳統的 Cassandra 讀取路徑沒有辦法確保磁碟上資料的正確性，但壓縮表格允許使用者設定
crc_check_chance（0.0 到 1.0 之間的浮點數）以允許 Cassandra 在讀取時機率性地驗證區塊，以驗證磁碟上的位元沒有損毀。
