带有timewindowcompactionstrategy表的nodetool压缩

huus2vyu  于 2021-06-10  发布在  Cassandra
关注(0)|答案(1)|浏览(223)

使用cassandra版本3.11.4,我们在使用timewindowcompactionstrategy、Compression\u window\u unit in hours和Compression\u window\u size 1创建的表中导入了几天的“类似时间序列”的数据:

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

由于这是从另一个数据库导入的历史数据,因此我们以以下方式更改了insert查询的时间戳:

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

其中,[记录的时间戳]是插入的每个时间序列记录的时间戳。
很明显,这种方法是有效的,在org.apache.cassandra.db.compression包上启用跟踪级别日志记录:

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(每个节点),所有的行都合并了!
这就是所谓的行为吗?我们做错什么了吗?

brgchamk

brgchamk1#

这是预期的行为。您可以使节点脱机并将sstables拆分为x,或者等待所有ttl过期,然后看着单个大sstable被清理。记住关闭维修的表与stws,否则,事情会变得一团糟。我通过艰苦的方式学会了这一点。否则,它是时间序列数据的一种很好的压缩策略。

相关问题