Cassandra 时间窗口压缩策略答案

【问题标题】：Cassandra Time Window Compaction StrategyCassandra 时间窗口压缩策略
【发布时间】：2019-12-15 20:15:44
【问题描述】：

有 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)。我认为这与压缩策略有关。我是否应该将此策略与较小的 compaction_window_strategy 一起使用，例如3天？如何使用 ttl 调整压缩策略？这些参数如何关联？ O 也许我的主键有误？

Cassandra ring 3 个节点，8CPU，16GB 内存。每个节点加载 ~90GiB。

【问题讨论】：

标签： cassandra

【解决方案1】：

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

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

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

还记得关闭修复有 TWCS 的表。我已经看到把事情搞得一团糟。

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

-吉姆

【讨论】：