有Cassandra表:
CREATE TABLE data.data (
dataid bigint,
sequencenumber bigint,
createdat timestamp,
datetime timestamp,
PRIMARY KEY (dataid, sequencenumber)) WITH CLUSTERING ORDER BY (sequencenumber ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class': 'org.apache.cassandra.db.compaction.TimeWindowCompactionStrategy', 'compaction_window_size': '7', 'compaction_window_unit': 'DAYS', 'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 3600
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
CREATE INDEX data_datetime_idx ON data.data(datetime);
用写选项ttl写数据7天。我注意到,每周的同一天,我们都会遇到大cassandra节点负载,尤其是大wa(i/o)。我认为这与压缩策略有关。我是否应该将此策略与较小的压缩窗口策略(例如3天)结合使用?如何用ttl调整压缩策略?这些参数是如何关联的?o也许我的主键错了?
cassandra环3个节点,8cpu,16gb ram。每个节点负载~90gib。
1条答案
按热度按时间guykilcj1#
您的twcs配置似乎不太理想。你告诉cassandra要做的是每7天进行一次窗口/桶(合并),这也是你的ttl。从我读到的内容来看,通常你想要的是15-30个“桶”作为你的ttl周期。这就是说,在你的情况下,你想做的是花7天的时间,把它分成,比方说,30桶。如果你把它改成12个小时的桶,你会有14个桶,这看起来还可以。
在12小时内,当前bucket/window将发生stcs。12小时后,该窗口中存在的所有sstable都将合并到一个sstable中。7天后,您将有14个sstables,其中最旧的可以简单地删除(v.s.压缩比较)。
只要不更新或删除跨窗口的行,twcs就可以节省大量资源,而且非常有效。我们可以随时使用它。如果要更新先前bucket中存在的行,那么twcs不是一个好的选择。
还记得关闭有twcs的table上的维修。我见过那些人把事情搞得一团糟。
至于您的大等待i/o问题,可能是压缩,可能是刷新,可能是很多事情。对于您当前的twcs配置,它可能是压缩(取决于sstable的数量和大小)。我认为您可以尝试使用其他工具来查看繁忙线程的位置(例如ttop)。不管怎样,我都会修改您的twcs配置,使之符合最佳实践。
-吉姆