技术基础 | 模式配置的调优：压缩、读修复概率，布隆过滤器调优、墓碑的垃圾收集、缓存、推测性重试

为了减少磁盘空间的消耗，默认情况下Cassandra会以压缩格式来储存数据。然而，配置不合理的压缩方式有可能严重地伤害性能，因此使用正确的设置是很重要的。当前的配置信息可以通过输入DESCRIBE TABLE指令，在compression参数下找到。

可以使用ALTER TABLE <name> WITH compression = {...}来改变相关设置。

请注意，如果你改变了压缩设置，它们只会被应用到新创建的SSTable中。如果你也想将它们应用到已有的SSTable中，请使用指令nodetool upgradesstables -a keyspace table。

更多关于Cassandra内部压缩信息，请点击文末“阅读原文”参见文章《性能调优——在混合工作负载下的压缩》。

默认情况下，磁盘上的数据库表使用的是LZ4压缩算法。在压缩效率和压缩所需的额外的CPU负载之间，这个算法保持了很好的平衡。

Cassandra还支持其它的压缩模式（您可通过改变压缩参数中的sstable_compression实现）。

默认下，压缩后的数据块的大小是64Kb。也就是说，若想要提取需要的数据，数据库需要读取一个压缩块中的所有数据；这样会让数据库多消耗磁盘系统资源但是读到没用的数据。

你可以通过调整减小压缩后的数据块，如改为16Kb或32Kb。《性能调优——-在混合工作负载下的压缩》这篇文章（点击文末“阅读原文”即可查看）展示了通过改变chunk_length_kb这一属性的值使用较小的压缩块的效果。

压缩块的缩小会使得压缩效率的降低，进而导致磁盘上的数据量增加——请确保将这种情况纳入考虑

注意：缩小压缩块的策略仅适用于对自身存储的数据需要随机访问的表。

Cassandra有两种读修复：

read_repair_chance和dclocal_read_repair_chance这两个设置参数决定了在整个集群中或仅当前数据中心进行后台读修复(background read repair)的概率。

不过这样的设置并不是总能被准确地执行，甚至还有这样的bug：在当前数据中心进行本地修复时可能会引起跨数据中心操作(请参考CASSANDRA-9753)。

在数据出现不一致的情况下，当读取操作以LOCAL_QUORUM或QUORUM作为一致性级别执行操作时，无论如何前台读修复(foreground read repair)都会执行（在本地数据中心或整个集群的范围内）。在这种情况下，就没有必要再触发额外的后台读修复了。

要关闭后台读修复功能，可以将read_repair_chance和dclocal_read_repair_chance这两个值设为0。

如果您仍在使用带有此功能的Cassandra或DSE版本，请参考CASSANDRA-13910。在集群中任意一个节点输入以下命令即可以关闭后台读修复功能：

for i in `cqlsh -e 'describe schema;' |grep 'CREATE TABLE'|sed -e 's|CREATE TABLE \([^ ]*\) .*|\1|'`; do

echo "alter table $i with read_repair_chance = 0.0 and dclocal_read_repair_chance = 0.0;"
done| tee alters.cql
cqlsh -f alters.cql

布隆过滤器是一种内部数据结构，它优化了从磁盘中读取数据的过程。系统会为每一个SSTable文件都创建相应的布隆过滤器，并且它们会被加载到堆外内存中(Off-heap memory)。其消耗的内存和储存在SSTable中的分区键数量成正比，有些情况下它会十分巨大，甚至高达数十GB。

可通过执行nodetool tablestats（或早期Cassandra版本中的nodetool cfstats）查看命令行输出里每张表的Bloom filter off heap memory used那一行，可以看到布隆过滤器使用的堆外内存量（即以字节为单位的布隆过滤器的大小）。

你可以通过调整bloom_filter_fp_chance选项来控制特定的表的布隆过滤器大小。由于这个参数会增加假阳性率(false positive ratio)，因此布隆过滤器会变得更小。比如，将假阳性率提升到10%，布隆过滤器的内存消耗会降低将近一半。

不过，增加假阳性率也会引起读取更多不必要的SSTable的问题。因此建议只对数据很少会被读取的表的布隆过滤器进行调优，比如这样的表就比较适合进行相关调优：表中存储了仅为合规的档案，而且其中的数据很少会被读取或批量读取。

Cassandra不会直接删除数据，而是会在被删除的数据上先做一个特殊的标记，这个标记被称为“墓碑”。墓碑会隐藏被删除的数据。

一个墓碑会根据gc_grace_seconds参数在文件中保留至少一段时间，这个时间的长度默认是10天（864000秒）。请时刻记住，如果一个或多个节点在删除数据时宕机，这些节点必须重新加入集群，并在gc_grace_seconds期间内执行修复(repair)操作，不然这条被删掉的数据会在集群中重新复活。

如果服务器的宕机时间超过了gc_grace_seconds，请将该服务器上的Cassandra集群中的数据全部移除，并且执行节点更换(node replacement)操作。

请注意：在DSE6.0或之后的版本中，Nodesync功能会在Cassandra确保墓碑已经被同步到所有副本之前，防止已经启用该功能的表中的墓碑被移除。如果Nodesync的修复速度很慢，并且不能以足够快的速度同步数据，这可能会导致数据库表的墓碑数量增加，并会持续相当长的时间。

如果表中有大量的墓碑，这可能会对读性能造成很大的负面影响，在某些情况下你可能需要减小gc_grace_seconds参数的值从而更快地移除墓碑。如果改变了这个参数，你需要确保在这期间执行全令牌区间的修复操作(full token range repair)。如果一个节点已经宕机了一段时间，执行这个操作可能会变得很困难。

另外，过小的gc_grace_seconds会阻止hints的收集和重传，从而影响hinted handoff的执行。如果发生这种情况，集群也需要执行数据修复。

实质上的或辅助性的缓存数据会对Cassandra或DSE节点的读取性能产生影响。对于表来说，你可以调整缓存配置中的两项参数：

Cassandra有以下默认配置（只缓存所有的分区键，不缓存行）。

caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}

如果需要，你可以用ALTER TABLE指令改变它（从而不仅可以缓存所有的分区键，还可以缓存每个分区的10行数据）。

ALTER TABLE ks.tbl WITH caching = {'keys': 'ALL', 'rows_per_partition': 10};

默认情况下，协调节点会给足够多的副本节点发送查询语句以满足一致性级别的要求：如果一致性级别为ONE则向一个副本节点发送，如果一致性级别为QUORUM则向超过半数的副本节点发送，以此类推。

通过使用配置参数speculative_retry，你可以指定协调节点何时可以查询额外副本。当协调节点向某些副本发送查询，而回复很慢或没有响应时，这个功能就派上用场了。

推测性重试是用来减少95百分位或99百分位的尾部数据读取时延(tail read latency)，不过会给Cassandra节点造成更多的负载，而这些负载也许会导致Cassandra节点需要处理更多额外的读请求。在你清楚地意识到自己在做什么之前，请不要改变speculative_retry的默认值“99PERCENTILE”。

请注意：speculative_retry这一设置并不会影响一致性级别为ALL的读取性能，因为这种情况其实已经要求查询所有的副本了。

此speculative_retry这一配置参数可以有以下值（不区分大小写）：

• ALWAYS：对于该表的每次读取，协调节点都向剩下所有的节点发送额外的读取请求。

• Xpercentile：每个表的读取时延都会被追踪记录，并且协调节点会计算特定表通常的读取时延的X百分位数。当等待时间超过了计算好的延迟时间，协调节点就会发送额外的读取请求。不过该设置的问题在于，当节点不可用时，它会增加读取的时延，进而会增加X百分位的数值。

• Nms：协调节点如果没有在N毫秒内收到回复，它便会向剩下所有的副本发送额外的读取请求。

• NONE：协调节点不会发送额外的读取请求。

注意：在Cassandra 4.0中，speculative_retry可能会有更多的值。

本文内容版权归DataStax所有

未经书面允许禁止转载