при этом агрегационная функция - argMax(value, timecode_1).
Я создал таблицу с TTL (см. запрос ниже). Через 30 минут после последнего таймкода данные свернулись. В результате при агрегации я получил 2 строки, в одной учлись данные с 1 по 25 timecode_1, в другой с 26 по 30. При этом был выставлен параметр merge_with_ttl_timeout = 1200 - 20 минут.
Перепроверил через несколько часов, данные не схлопнулись в одну строку.
Вопросы:
1. Почему так произошло? Вроде merge_with_ttl_timeout позволяет производить принудительные мержи, нет? Может есть особенности задания интервала в TTL части?
2. Может есть более оптимальный способ посчитать argMax в данной задаче? *State не подходит.
3. Если ли способ решить ту же задачу, но воспользовавшись движком SummingMergeTree? Далее потребуется считать суммы, было бы удобно
create table kubernetes.test5
(
id UInt64,
timecode_1 DateTime,
timecode_agg DateTime,
value Float32
)
engine = MergeTree()
PARTITION BY toYYYYMMDD(timecode_1)
ORDER BY (id, timecode_agg)
TTL timecode_1 + INTERVAL 30 minute GROUP BY id, timecode_agg SET value=argMax(value, timecode_1)
SETTINGS index_granularity = 8192, merge_with_ttl_timeout=1200;
Коллеги, подскажите, пожалуйста, с чем может быть связана проблема? Иногда строки вообще не сворачиваются, есть периоды, где данные лежат с гранулярностью 1 минута, а до и после них свернуты до 30 минут. Подозреваю, что природа ошибки та же
Обсуждают сегодня