节点工具紧凑型TimeWindowCompactionStrategy表

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
};

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

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

其中，记录的时间戳是插入的每个时间序列记录的时间戳。

显然，此方法起了作用，可以在org.apache.cassandra.db.compaction包上启用跟踪级别日志记录：

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紧凑型时，问题就出现了。

我们所期望的是为每个“一个小时的水桶”获得一个稳定的系统。我们得到的是一个巨大的稳定系统(每个节点)，所有的行都合并了！

这就是所谓的行为吗？我们做错什么了吗？

Answer 1

这是预期的行为。您可以将节点离线并将马厩拆分为X，也可以等待所有TTL过期，然后观看单个大型sstable被清除。记住用STWS关闭表上的修复，否则，事情会变得很混乱。我学到了艰难的方法。否则，对于时间序列数据来说，这是一个很好的压缩策略。