PARTITION BY (toYYYYMM(timestamp), event_source, event_name)
PRIMARY KEY id
ORDER BY (id, timestamp)
TTL toDateTime(timestamp) + toIntervalMonth(2)
SETTINGS index_granularity = 8192, parts_to_throw_insert = 600, max_replicated_merges_in_queue = 16;
и в aggregated MV вида (несколько, по разным ключам полям используем)
ENGINE = ReplicatedMergeTree()
PARTITION BY toYYYYMM(timestamp)
PRIMARY KEY (client_id, timestamp)
ORDER BY (client_id, timestamp)
TTL toDateTime(timestamp) + toIntervalDay(45)
SETTINGS index_granularity = 8192 AS
сейчас поставим параметр ttl_only_drop_parts = 1 , но не уверен поможет, TTLdelete мержей немного, но они большие, в mv они целиком в одну партицию попадают
если мы увеличим
merge_with_ttl_timeout и merge_with_recompression_ttl_timeout до, допустим, 24 часов (сейчас дефолт 4), стоит ожидать ускорения подрезки в совокупности? или наоборот, разовая подрезка за 24 будет 6х дольше чем 4 часа и все положит?
наша проблема в том, что части мержится не успевают, пока идет подрезка , очередь образуется
ttl_only_only_drop удаляет данные мгновенно, без него каждый раз оно удаляет только часть данных в парте, из-за чего нужны мержи, и это супер медленно и дорого, просто диск насилуете. Никогда не вешайте TTL если ttl_only_only_drop не включили
спасибо, включили ttl_only_only_drop, и увеличили таймаут, наблюдаем
Обсуждают сегодня