带有 TimeWindowCompactionStrategy 表的 nodetool compact

Question

使用 cassandra 版本 3.11.4，我们在使用 TimeWindowCompactionStrategy 创建的表中导入了几天的“类似时间序列”的数据，compaction_window_unit 以小时为单位，compaction_window_size 为 1：

CREATE TABLE MYTABLE (
  some_fields text,
(...)
AND compaction = {
  'class' : 'TimeWindowCompactionStrategy',
    'compaction_window_unit': 'HOURS',
    'compaction_window_size': 1
};

由于这是从另一个数据库导入的历史数据，我们以这种方式更改了插入查询的时间戳：

INSERT INTO MYTABLE (...) USING TIMESTAMP [timestamp of the record] AND TTL ...

其中 [timestamp of the record] 是插入的每个时间序列记录的时间戳。

显然这种方法有效，已验证在 org.apache.cassandra.db.compaction 包上启用 TRACE 级别日志记录：

TRACE [CompactionExecutor:421] ...TimeWindowCompactionStrategy.java:252 - buckets {
1523124000000=[BigTableReader(path='.../md-487-big-Data.db')], 
1523070000000=[BigTableReader(path='.../md-477-big-Data.db')], 
1523109600000=[BigTableReader(path='.../md-530-big-Data.db')], 
1523134800000=[BigTableReader(path='.../md-542-big-Data.db')] }, 
max timestamp 1523134800000

我们发现几个“一小时”大的桶。

当我们在每个 cassandra 节点上运行 nodetool compact 时，问题就出现了。

我们期望为每个“一小时桶”获得一个 sstable。 我们得到的是一个巨大的 sstable（每个节点），所有行都合并了！

这是假定的行为吗？我们是不是做错了什么？

Answer 1

这是预期的行为。您可以使节点脱机并将 sstable 拆分为 X，或者等待所有 TTL 过期，然后观察单个大型 sstable 被清理。请记住关闭使用 STWS 对表的修复，否则，事情会变得一团糟。我很难学到这一点。否则，对于时间序列数据来说，这是一个很好的压缩策略。