根据DataStax Cassandra yaml文档链接https://docs.datastax.com/en/cassandra/2.1/cassandra/configuration/configCassandra_yaml_r.html
compaction_throughput_mb_per_sec
(默认值: 16 )将压缩压缩到整个系统的指定总吞吐量。插入数据的速度越快,您需要更快地压缩以保持SSTable倒计时。建议值是写吞吐率的16到32倍(以MB /秒为单位)。将值设置为0将禁用压缩限制。
我对上述文本的字面解释是,如果您正在观察磁盘I / O(mb / s),如38 mb / s,现在只考虑Cassandra节点上的写入负载,则compaction_throughput_mb_per_sec应设置为38 * 16 = 608或38 * 32 = 1216,这与压实策略无关。
如果上述解释是正确的,那么请帮助我理解值608或1216在限制压缩和整个系统总吞吐量的上下文中的实际含义尺寸分层压缩策略(默认)的示例可以通过扩展一个如下所述。
左图:
根据文档,SizeTieredCompactionStrategy的min_threshold值为6.在我们的示例中,它保持不变。平均而言,每个节点的磁盘I / O大约为38 mb / s(仅写入,不会发生读取操作)。 compaction_throughput_mb_per_sec值为16。
什么是价值16的压实工作流程?如果我们将其更改为608,那么究竟会发生什么变化,哪些会受到影响以及如何影响?
答案 0 :(得分:0)
让我们重新审视压缩的含义。
压缩过程合并键,组合列,驱逐逻辑删除,合并SSTable,并在合并的SSTable中创建新索引。
...
compaction_throughput_mb_per_sec参数设计用于大型分区,因为压缩会限制整个系统中指定的总吞吐量。
要在混合读写工作负载中保持读取性能,您需要减少在一次长时间运行的压缩过程中小SSTable积累的趋势。
因此,当您更新compaction_throughput_mb_per_sec时,您将更新新的合并SSTable的写入速率;并且转向可以帮助您减轻压实过程中小SSTable积累的趋势。
因此,总之,当你从16到608增加compaction_throughput_mb_per_sec的价值,你会增加写作SSTables所需的写入吞吐量,进而减少小SSTables的机会越来越创建,并最终提高读取性能。