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也许我的主键错了

---

卡桑德拉环3个节点，8CPU，16GB ram。每个节点负载约90GiB

您的TWCS配置似乎不太理想。您告诉Cassandra要做的是每7天进行一次窗口/桶（合并），这也是您的TTL。从我所读到的内容来看，通常情况下，您想要的TTL周期为15-30个“桶”。这就是说，在你的情况下，你想做的是花7天的时间，把它分成，比如说，30桶。如果你把它改为12小时的桶，你会有14个桶，这看起来还可以

在12小时内，当前存储桶/窗口将发生STC。12小时后，该窗口中存在的所有sstable将合并为一个sstable。7天后，您将有14个sstables，其中最旧的可以简单地删除（v.s.压缩比较）

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

还记得关闭带有TWCS的工作台上的维修。我见过那把事情搞得一团糟

至于大的等待I/O问题，可能是压缩，可能是刷新，可能是很多事情。在您当前的TWCS配置中，可能需要压缩（取决于SSCS表的数量和大小）。我认为您可以尝试使用其他工具查看繁忙线程的位置（例如ttop）。不管怎样，我都会修复您的TWCS配置，使其符合最佳实践

-吉姆