我有六个节点的Cassandra集群,它们承载着一个不可更改的大型列族(cql表)(因为从应用程序角度来看,这是一种历史表)。该表大约是 400Go 压缩数据,
因此,在将表截断后,再提取其中的应用程序历史记录数据后,我会在每个节点上触发 nodetool compact ,以减少读取次数,从而获得最佳读取性能SSTables。压缩策略是 STCS 。
运行 nodetool compact 后,我触发 nodetool compactionstats 来跟踪压缩进度:
id compaction type keyspace table completed total unit progress
xxx Compaction mykeyspace mytable 3.65 GiB 1.11 TiB bytes 0.32%
小时之后,我在同一节点上
id compaction type keyspace table completed total unit progress
xxx Compaction mykeyspace mytable 4.08 GiB 1.11 TiB bytes 0.36%
因此压缩过程似乎可以正常运行,但是它非常慢。
即使使用 nodetool setcompactionthreshold-0 ,压缩仍然非常缓慢。此外,由于这种压缩, CPU 似乎习惯了 100%。
问题:
答案 0 :(得分:2)
压缩的性能取决于底层硬件-它的性能取决于所使用的磁盘类型等。但是,它还取决于允许运行多少个压缩线程以及为压缩线程配置了什么吞吐量。通过命令行压缩,吞吐量是由nodetool setcompactionthroughput
配置的,而不是您所使用的nodetool setcompactionthreshold
。并发压缩程序的数量由nodetool setconcurrentcompactors
设置(但在IIRC 3.1中可用)。您还可以在cassandra.yaml
中配置默认值。
因此,如果您有足够的CPU能力和好的SSD磁盘,则可以提高压缩吞吐量和压缩器数量。