INDEX в кх? документация весьма скудно описывает типы индексов, как выбирать их GRANULARITY тоже не вполне понятно. спасибо
в КХ есть только кластерный индекс, и скип индексы (с очень ограниченным пространством применения). грануларити обычно лучше не трогать
речь идет о data skipping индексах
GRANULARITY выбираешь исходя из того, насколько часто индексом пользоваться надо. Если редко, то можно сэкономить на памяти для индекса.
способ только один, просто подбором, ставите 10, проверяете запросы, ставите 5 , проверяете
А есть какой-нибудь конкретный профиль использования этих пропускающих индексов? У меня задача: ускорить обычные агрегирующие запросы к таблице с сырыми данными (лог событий), когда WHERE в запросе не имеет полей из ПК таблицы
могу с уверенностью 88% сказать что skip индексы вам не помогут
Тогда еще один вопрос: ПК таблицы, записанный как ORDER BY (ts, a, b), будет участвовать в запросах, где есть WHERE ts = x AND b = y (то есть нет условия по полю a)?
Будет участвовать, да. Но если a часто меняется, то толку мало будет
зависит от кардинальности ts, так ts это похоже на timestamp то нет. короче вопрос ЧТО ТАКОЕ TS ?
Верно, именно timestamp события. Таблица - лог запросов к рекламному трекеру. Задача - сообразить ПК/индексы так, чтобы максимально быстро выполнять агрегирующие запросы пользователей, в которых могут быть любые комбинации WHERE и GROUP BY
начните с ORDER BY (a, b, ts) если не подойдет то проверьте ORDER BY (toStartOfHour(ts), a, b) ORDER BY (toStartOfDay(ts), a, b)
1. А a и b у вас что? Тикер/номер компании? 2. Паттерн обычно какой: запрашивают по своей компании или сразу по многим?
Запрашивают по своему id юзера разные кампании
2. Даже так: обычно id юзера в WHERE, а id кампании часто в GROUP BY
Тогда можно что-то вроде OK = (user_id, timestamp) Масштабировать на кластер по user_id % X или консистентное хеширование
Ещё можно data skipping index bloom_filter завести на id кампании, если надо искать на большие промежутки, но с ограничением по кампаниям
ну IMHO тут очень сильно зависит от того как данные в ваших столбцах по которым вы пытаетесь data skip index размыты по разным system.parts data skip означает что при сканировании парт сначала проверяется что искомые значения ОТСУТСТВУЮТ в конкретном парт если есть вероятность что они есть. то идет обычное сканирование парта... то есть data skip index помогут если условия фильтрации по запросам данные локализованы именно в рамках 1-нескольких партов а если у вас user=1 на половине таблицы, то не помогут
Вообще без id кампаний в OK? Бывают сравнительно часто запросы данных по конкретным кампаниям, то есть WHERE id юзера AND id кампании
Тут пробовать надо. Либо с bloom_filter индексом дополнительно, что такие запросы может ускорить, либо уже полноценная отдельная MV с сортировкой по кампании. Промежуточные варианты с toStartOfHour, как @den_crane выше предлагал это промежуточные по скорости варианты для обоих запросов.
Обсуждают сегодня