У tokenbf_v1 фиксированный размер Bloom-фильтра на гранулу: рост уникальных токенов может ухудшить селективность, но причину деградации нужно измерить.
[имя] и высококардинальные логи: стек Vector + ClickHouse начал деградировать, потому что один сервис записывает в поле `message` уникальные идентификаторы запросов, из-за чего резко выросла кардинальность индекса `tokenbf_v1`.
У tokenbf_v1 фиксированный размер Bloom-фильтра на гранулу: рост уникальных токенов может ухудшить селективность, но причину деградации нужно измерить.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Условие
[имя] и высококардинальные логи: стек Vector + ClickHouse начал деградировать, потому что один сервис записывает в поле message уникальные идентификаторы запросов, из-за чего резко выросла кардинальность индекса tokenbf_v1. Поиск по логам за последние сутки стал занимать 40 секунд вместо двух; TTL ещё не истёк, объём данных — 4 ТБ в день. Как диагностируете причину деградации без изменения данных, что сделаете с индексом прямо сейчас без полного удаления таблицы и как системно защититесь от подобных ситуаций на уровне пайплайна?
Ответ
У tokenbf_v1 фиксированный размер Bloom-фильтра на гранулу: рост уникальных токенов может ухудшить селективность, но причину деградации нужно измерить.
Сравните query_log, read_rows/bytes и EXPLAIN indexes=1, затем ограниченный запрос с use_skip_indexes=0. Если индекс бесполезен, его можно убрать через ALTER TABLE ... DROP INDEX без удаления строк таблицы; перестроение делайте отдельно. В pipeline вынесите request_id из message, нормализуйте шаблоны и контролируйте объём. TTL не устраняет плохую селективность до удаления данных.
Источник: clickhouse.com, clickhouse.com.