Компонент nodetool с таблицами 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
};

, поскольку это исторические данные, импортированные из другой БД, мы изменили метку времени в запросе вставки следующим образом:

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

где [отметка времени записи] - отметка времени каждой вставленной записи временного ряда.

Видимо, этот метод сработал, что подтверждается включением ведения журнала уровня TRACE в пакете 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

Где мы нашли несколько ведер "один час".

Проблема возникла, когда мы запустили nodetool compact на каждом узле Кассандры.

Мы ожидали получить один sstable для каждого «часового сегмента». Мы получили один огромный sstable (на узел) со всеми объединенными строками!

Это предполагаемое поведение? мы что-то делаем не так?

Answer 1

Это ожидаемое поведение. Вы можете либо перевести узел в автономный режим и разбить sstables на X, либо дождаться истечения срока действия всех TTL, а затем посмотреть, как будет очищен один большой sstable. Не забудьте отключить ремонт на столах с помощью STWS, иначе все может стать грязным. Я узнал, что трудный путь. В противном случае это отличная стратегия сжатия данных временных рядов.