Question

有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节点负载，尤其是big wa（I / O）。我认为这与压缩策略有关。我应该以较小的compaction_window_strategy使用此策略吗？ 3天？如何使用ttl调整压缩策略？这些参数如何关联？哦，也许我的主键错误？

Cassandra环3x节点，8CPU，16GB内存。每个节点负载约90GiB。

Answer 1

您的TWCS配置似乎不是最佳的。您告诉Cassandra要做的是每7天发生一次窗口/存储桶（合并），这也是您的TTL。根据我的阅读，通常您想要的是TTL期间的15-30个“存储桶”。话虽这么说，您要处理的情况是7天，将其分成30个存储桶。如果将其更改为12 HOUR桶，则将有14个桶，这似乎还可以。

在12个小时内，当前存储段/窗口将发生STCS。在12小时标记时，该窗口中存在的所有sstable将被合并为一个sstable。 7天后，您将拥有14个sstable，其中最旧的sstable可以简单地删除（相对于压缩比较）。

只要您不更新或删除跨窗口的行，TWCS可以节省大量资源并且非常高效。我们会尽可能使用它。如果要更新先前存储桶中存在的行，则TWCS并不是一个不错的选择。

还请记住关闭具有TWCS的桌子的维修。我已经看到事情变得很糟。

对于大的等待I / O问题，可能是压缩，可能是刷新，可能是很多事情。使用您当前的TWCS配置，它可能是压缩的（取决于sstable的数量和大小）。我认为您可以尝试使用其他工具查看繁忙线程的位置（例如ttop）。无论哪种方式，我都会将您的TWCS配置修改为符合最佳做法。

-吉姆

卡桑德拉时间窗压缩策略

1 个答案: