⚙️ Сегодня поговорим о ClickHouse - современной колоночной бд
Эта СУБД была создана в Яндексе, чтобы быстро обрабатывать огромные объёмы аналитических данных.
Она идеально подходит для метрик, логов, аналитики поведения пользователей и realtime-дашбордов.
❓ Почему ClickHouse стал необходим?
Обычные реляционные базы (PostgreSQL, MySQL) хранят данные построчно.
Это удобно для транзакций (добавить заказ, обновить статус),
но неэффективно, когда нужно просканировать миллиарды строк и посчитать среднее.
ClickHouse решает эту задачу:
🔘 У него колоночное хранение — данные читаются по колонкам, а не по строкам.
Если запрос использует 3 столбца из 100, остальные даже не читаются.
🔘 Векторная обработка данных— операции в Clickhouse выполняются сразу на блоках строк (по 65 000 штук), а не по одной.
🔘Используется сжатие ZSTD/LZ4 из-за чего хранит данные в 5–10 раз компактнее.
🖥 Какие основные Архитектурные компоненты Clickhouse:
🟣У него есть Block — единица работы в памяти.
ClickHouse всегда работает блоками, чтобы максимально использовать CPU-векторизацию.
🟣Данные хранятся на диске Part'ами — кусками данных, создающимися при каждом INSERT и уже отсортированными по ORDER BY.
Старые парты не изменяются, а фоновые потоки их потом объединяют (merge).
🟣 MergeTree — сердце ClickHouse
Это семейство движков, которое обеспечивает сортировку, дедупликацию и индексацию.
Например: ReplacingMergeTree, SummingMergeTree, AggregatingMergeTree — варианты под разные задачи.
🟣 Primary Key ≠ уникальный ключ.
В ClickHouse он нужен для сортировки и ускорения диапазонных запросов.
🟣Skip-индексы и minmax-индексы
Хранят диапазоны значений по каждому парту —
чтобы быстро «пропускать» ненужные куски данных при чтении.
🎹 Как масштабируется ClickHouse?
🟡Sharding (шардирование) — данные делятся на части по ключу, чтобы разные узлы обрабатывали свои диапазоны.
🟡Replication (репликация) — каждая часть дублируется на другом сервере для отказоустойчивости.
🟡Distributed-таблицы — объединяют шарды и позволяют выполнять запросы «как по одной большой таблице».
И всё это работает параллельно и прозрачно для пользователя.
ClickHouse — это философия «читать быстро и много».
Он не заменяет PostgreSQL или OLTP-базы —
он решает другую задачу: аналитику на огромных данных, где важна скорость чтения, а не запись.
🧱 Каждая таблица — part, каждый запрос — блоки, каждая секунда — миллионы строк.
Вот почему ClickHouse стал стандартом де-факто для аналитических систем.
Эта СУБД была создана в Яндексе, чтобы быстро обрабатывать огромные объёмы аналитических данных.
Она идеально подходит для метрик, логов, аналитики поведения пользователей и realtime-дашбордов.
❓ Почему ClickHouse стал необходим?
Обычные реляционные базы (PostgreSQL, MySQL) хранят данные построчно.
Это удобно для транзакций (добавить заказ, обновить статус),
но неэффективно, когда нужно просканировать миллиарды строк и посчитать среднее.
ClickHouse решает эту задачу:
🔘 У него колоночное хранение — данные читаются по колонкам, а не по строкам.
Если запрос использует 3 столбца из 100, остальные даже не читаются.
🔘 Векторная обработка данных— операции в Clickhouse выполняются сразу на блоках строк (по 65 000 штук), а не по одной.
🔘Используется сжатие ZSTD/LZ4 из-за чего хранит данные в 5–10 раз компактнее.
🖥 Какие основные Архитектурные компоненты Clickhouse:
🟣У него есть Block — единица работы в памяти.
ClickHouse всегда работает блоками, чтобы максимально использовать CPU-векторизацию.
🟣Данные хранятся на диске Part'ами — кусками данных, создающимися при каждом INSERT и уже отсортированными по ORDER BY.
Старые парты не изменяются, а фоновые потоки их потом объединяют (merge).
🟣 MergeTree — сердце ClickHouse
Это семейство движков, которое обеспечивает сортировку, дедупликацию и индексацию.
Например: ReplacingMergeTree, SummingMergeTree, AggregatingMergeTree — варианты под разные задачи.
🟣 Primary Key ≠ уникальный ключ.
В ClickHouse он нужен для сортировки и ускорения диапазонных запросов.
🟣Skip-индексы и minmax-индексы
Хранят диапазоны значений по каждому парту —
чтобы быстро «пропускать» ненужные куски данных при чтении.
🎹 Как масштабируется ClickHouse?
🟡Sharding (шардирование) — данные делятся на части по ключу, чтобы разные узлы обрабатывали свои диапазоны.
🟡Replication (репликация) — каждая часть дублируется на другом сервере для отказоустойчивости.
🟡Distributed-таблицы — объединяют шарды и позволяют выполнять запросы «как по одной большой таблице».
И всё это работает параллельно и прозрачно для пользователя.
ClickHouse — это философия «читать быстро и много».
Он не заменяет PostgreSQL или OLTP-базы —
он решает другую задачу: аналитику на огромных данных, где важна скорость чтения, а не запись.
🧱 Каждая таблица — part, каждый запрос — блоки, каждая секунда — миллионы строк.
Вот почему ClickHouse стал стандартом де-факто для аналитических систем.