CLICKHOUSE: ЧТО ВАЖНО ЗНАТЬ
Записал курс по ClickHouse и собрал самое важное в один пост. Если хотите работать с кликхаусом или собираетесь на собес - очень рекомендую🔥
Получилось 15 уроков, всё максимально структурировано и по делу. Ниже - ключевые моменты, чтобы за пару минут понять суть. А в конце - ссылка на бесплатный курс ⬇️
Что такое ClickHouse 🏠
Колоночная аналитическая СУБД - данные хранятся по столбцам, а не по строкам. Это упрощает сжатие и аналитические запросы, так что Clickhouse считает агрегаты по миллиардам строк за секунды.
Это не замена PostgreSQL, скорее его партнёр - транзакции приходят в OLTP-базу, аналитика собирается в ClickHouse, а между ними работает CDC или ETL-пайплайн.
Почему кликхаус такой быстрый🏄
Он берёт только нужные столбцы, ничего лишнего. Читает не построчно, а гранулами по 8192 строки, считает данные блоками и обрабатывает несколько значений за 1 такт процессора. Однотипные значения в столбце жмутся в 5–20 раз.
Структура хранения 📖
Внутри ClickHouse выстроен так: таблица - партиция - кусок - гранула (8192 строки). Вставки могут происходить и небольшими кусками, но фоновые слияния укрупняют мелкие куски.
Базовый движок хранения - MergeTree, на движках семейства MergeTree обычно хранят основные данные. Есть варианты - ReplacingMergeTree, CollapsingMergeTree и AggregatingMergeTree. На таких движках данные автоматически подменяются, удаляются или агрегируются в фоновом режиме. Для просмотра итогового вида таблицы в запросах используют слово FINAL.
Как правильно делать 🔥
● При создании таблицы задаём ключ сортировки - задаётся по частым фильтрам, от низкой кардинальности к высокой. Это даёт ускорение запросов в разы.
● Партиционирование делают по месяцу, при большом потоке - по дню. Лучше иметь десятки партиций, чем десятки тысяч. Таблицы меньше 10 ГБ можно не партиционировать.
● Данные вставляют батчами по 10–100 тысяч строк, не чаще раза в секунду. Если клиент не умеет вставлять батчами - включаем асинхронную вставку.
● ClickHouse не любит точечные правки. Есть лёгкий UPDATE, но для потока изменений стандарт такой: ReplacingMergeTree и вставка новой версии строки. Дубли схлопнутся при фоновом слиянии, а до него таблицу читают через FINAL.
● Денормализация при вставке, а не соединения при чтении. Справочник до 10 миллионов строк помещается в словарь, его значения подтягиваются в материализованном представлении через dictGet.
● EXPLAIN indexes = 1 SELECT ... показывает, сколько кусков и гранул будет прочитано запросом - сразу понятно надо ли менять ORDER BY.
● system.query_log - журнал выполненных запросов с временем, объёмом чтения и памятью, отдельно проверяем частые запросы.
Как лучше не делать🫣
1) Вставлять часто и по одной строке. Тысяча INSERT за минуту - тысяча кусков и ошибка "too many parts".
2) Менять строки по одной, как в OLTP. Мутация переписывает затронутые столбцы целиком, лёгкий UPDATE дешевле, но тоже не бесплатен.
3) Соединять две большие таблицы: правая целиком собирается в хеш-таблицу в памяти и если она большая - памяти может не хватить.
4) Ставить Nullable без нужды - лишний байт на строку и проверки. Если нет смысла в пустоте - выставляйте значение по умолчанию.
5) Ждать от ClickHouse транзакций, внешних ключей и быстрых точечных запросов по id, особенно если id нет в ключе сортировки. Это не его работа.
Что путают чаще всего🙄
Словарь - справочник в памяти, обращение по ключу за наносекунды, обновляется сам по времени жизни. Лучшая альтернатива JOIN.
Материализованное представление - обычно это триггер на вставку: считает агрегаты на входящем блоке и пишет в целевую таблицу.
PRIMARY KEY - не уникальный столбец, а разреженный индекс: одна отметка на гранулу, поэтому он указывает лишь диапазон, где искать.
Ключевое правило 🧠
ClickHouse блестяще решает задачу «прочитать много данных быстро» и плохо - «изменить одну строку быстро». Это ключевой момент при выборе СУБД и дальнейшей архитектуры таблиц.
Полное погружение в ClickHouse тут: https://directprobi.ru/platform/clickhouse-teoriya/
Записал курс по ClickHouse и собрал самое важное в один пост. Если хотите работать с кликхаусом или собираетесь на собес - очень рекомендую🔥
Получилось 15 уроков, всё максимально структурировано и по делу. Ниже - ключевые моменты, чтобы за пару минут понять суть. А в конце - ссылка на бесплатный курс ⬇️
Что такое ClickHouse 🏠
Колоночная аналитическая СУБД - данные хранятся по столбцам, а не по строкам. Это упрощает сжатие и аналитические запросы, так что Clickhouse считает агрегаты по миллиардам строк за секунды.
Это не замена PostgreSQL, скорее его партнёр - транзакции приходят в OLTP-базу, аналитика собирается в ClickHouse, а между ними работает CDC или ETL-пайплайн.
Почему кликхаус такой быстрый🏄
Он берёт только нужные столбцы, ничего лишнего. Читает не построчно, а гранулами по 8192 строки, считает данные блоками и обрабатывает несколько значений за 1 такт процессора. Однотипные значения в столбце жмутся в 5–20 раз.
Структура хранения 📖
Внутри ClickHouse выстроен так: таблица - партиция - кусок - гранула (8192 строки). Вставки могут происходить и небольшими кусками, но фоновые слияния укрупняют мелкие куски.
Базовый движок хранения - MergeTree, на движках семейства MergeTree обычно хранят основные данные. Есть варианты - ReplacingMergeTree, CollapsingMergeTree и AggregatingMergeTree. На таких движках данные автоматически подменяются, удаляются или агрегируются в фоновом режиме. Для просмотра итогового вида таблицы в запросах используют слово FINAL.
Как правильно делать 🔥
● При создании таблицы задаём ключ сортировки - задаётся по частым фильтрам, от низкой кардинальности к высокой. Это даёт ускорение запросов в разы.
● Партиционирование делают по месяцу, при большом потоке - по дню. Лучше иметь десятки партиций, чем десятки тысяч. Таблицы меньше 10 ГБ можно не партиционировать.
● Данные вставляют батчами по 10–100 тысяч строк, не чаще раза в секунду. Если клиент не умеет вставлять батчами - включаем асинхронную вставку.
● ClickHouse не любит точечные правки. Есть лёгкий UPDATE, но для потока изменений стандарт такой: ReplacingMergeTree и вставка новой версии строки. Дубли схлопнутся при фоновом слиянии, а до него таблицу читают через FINAL.
● Денормализация при вставке, а не соединения при чтении. Справочник до 10 миллионов строк помещается в словарь, его значения подтягиваются в материализованном представлении через dictGet.
● EXPLAIN indexes = 1 SELECT ... показывает, сколько кусков и гранул будет прочитано запросом - сразу понятно надо ли менять ORDER BY.
● system.query_log - журнал выполненных запросов с временем, объёмом чтения и памятью, отдельно проверяем частые запросы.
Как лучше не делать🫣
1) Вставлять часто и по одной строке. Тысяча INSERT за минуту - тысяча кусков и ошибка "too many parts".
2) Менять строки по одной, как в OLTP. Мутация переписывает затронутые столбцы целиком, лёгкий UPDATE дешевле, но тоже не бесплатен.
3) Соединять две большие таблицы: правая целиком собирается в хеш-таблицу в памяти и если она большая - памяти может не хватить.
4) Ставить Nullable без нужды - лишний байт на строку и проверки. Если нет смысла в пустоте - выставляйте значение по умолчанию.
5) Ждать от ClickHouse транзакций, внешних ключей и быстрых точечных запросов по id, особенно если id нет в ключе сортировки. Это не его работа.
Что путают чаще всего🙄
Словарь - справочник в памяти, обращение по ключу за наносекунды, обновляется сам по времени жизни. Лучшая альтернатива JOIN.
Материализованное представление - обычно это триггер на вставку: считает агрегаты на входящем блоке и пишет в целевую таблицу.
PRIMARY KEY - не уникальный столбец, а разреженный индекс: одна отметка на гранулу, поэтому он указывает лишь диапазон, где искать.
Ключевое правило 🧠
ClickHouse блестяще решает задачу «прочитать много данных быстро» и плохо - «изменить одну строку быстро». Это ключевой момент при выборе СУБД и дальнейшей архитектуры таблиц.
Полное погружение в ClickHouse тут: https://directprobi.ru/platform/clickhouse-teoriya/