🧭 Индексы в ClickHouse — это не то, к чему ты привык

🔥 Главная мысль

Очень частая ошибка новичков — думать, что индекс в ClickHouse работает как в классической OLTP-базе.

Но ClickHouse — аналитическая СУБД. А значит, и логика индексации тут другая.

Если сказать совсем просто:

индекс в ClickHouse не хранит “точный путь к каждой строке”.

Он помогает быстро понять, какие большие куски данных точно можно не читать.

И это очень важное отличие.

🟢 Плюсы:

• индекс хорошо подходит для больших объёмов данных • не требует безумного расхода памяти, как классический индекс на каждую строку • помогает быстро отсекать ненужные гранулы • хорошо сочетается с OLAP-нагрузкой

Пример плюса: если у тебя запрос по диапазону дат, ClickHouse может быстро понять, какие гранулы подходят, а какие можно вообще не читать.

🔴 Минусы:

• это не индекс для точечного поиска одной строки • он не решает вообще все сценарии фильтрации • без хорошего primary key пользы будет мало • для regex, in и текстового поиска primary index уже часто недостаточен

Пример минуса: если ты ждёшь, что индекс поможет мгновенно найти одну запись по произвольному полю, как в транзакционной БД, то в ClickHouse это часто не так.

🧪 Живые примеры

Что такое индекс в ClickHouse по сути:

это карта данных, которая помогает понять, где могут лежать нужные значения, а где их точно нет.

В ClickHouse основной индекс — разреженный minmax индекс. Он хранит не каждое значение по каждой строке, а минимальные и максимальные значения на гранулу строк. По умолчанию гранула — 8192 строки.

То есть логика такая:

• данные хранятся не “по одной строке в индексе” • а блоками • для каждого блока известны min/max значения • если блок точно не подходит под условие — его можно пропустить

Простой пример:

если запрос ищет данные за январь, а у гранулы min/max полностью лежат в июне, то эту гранулу можно не читать.

Вот в этом и сила такого индекса.

🏗 Архитектурная мысль

В больших компаниях индекс в ClickHouse рассматривают не как “ускоритель на всё”, а как часть архитектуры хранения.

Сначала думают:

• как сортируются данные • какой будет primary key • по каким условиям чаще фильтруют запросы • где primary index уже не хватает • нужны ли вторичные индексы

Что это даёт:

• меньше лишнего чтения с диска • быстрее BI и витрины • лучше масштабируемость на больших объёмах

⚠️ Риски:

• переносить мышление из PostgreSQL / MySQL один в один • выбирать primary key “на глаз” • ждать от primary index поведения классического b-tree индекса • не понимать, что вторичные индексы нужны только под конкретные сценарии

Самая частая ошибка — думать, что индекс в ClickHouse отвечает за быстрый доступ к каждой строке.

На практике он отвечает за быстрое отсечение ненужных кусков данных.

✅ Вывод

Индекс в ClickHouse — это не “найти строку”, а “не читать лишнее” ⚡️

Именно поэтому он хорошо работает в аналитике, где объёмы огромные, а запросы читают миллионы и миллиарды строк 🚀