操作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上的接口来提供自己的压缩类。