Статья также доступна на украинском (перейти к просмотру).

Содержание:

• Что такое ClickHouse
• Главное отличие: строки против колонок
• Практический кейс: сбор метрик
• Почему ClickHouse хорошо подходит для такого случая
• MergeTree – основа большинства таблиц ClickHouse
• Сжатие данных на практике
• ClickHouse против MySQL и PostgreSQL
• Когда ClickHouse использовать не нужно
• MySQL/PostgreSQL + ClickHouse
• Что нужно учесть перед установкой ClickHouse
• Заключение

Первоначально приложение сохраняет метрики в обычной MySQL или PostgreSQL. Это работает нормально: несколько тысяч или даже миллионов записей база обрабатывает без проблем. Но количество источников данных растет, метрики поступают ежесекундно, и таблица уже содержит сотни миллионов строк. Запись данных все еще работает быстро, но отчеты по виду «среднее значение в сутки», «максимум за месяц» или «статистика по тысячам устройств» начинают выполняться все дольше.

Именно для таких задач существуют специализированные аналитические СУБД, одна из самых известных среди которых – ClickHouse. Важно сразу сказать: MySQL и PostgreSQL в этой ситуации не «плохие» и не «медленные». Они просто оптимизированы под другой класс перегрузки. Ниже разберем, чем ClickHouse для аналитики отличается от привычных реляционных систем при работе с большими объемами данных, на каком реальном примере это видно и когда подключать вторую базу данных действительно стоит, а когда нет. Примеры ниже выполнены на рабочем сервере VPS-хостинга Freehost.

Что такое ClickHouse

ClickHouse – это реляционная колонковая СУБД с открытым кодом, которая поддерживает привычный SQL, но заточена прежде всего под OLAP-нагрузку: большие объемы данных в виде событий, метрик и данных временных рядов. Ее основная задача – быстро агрегировать огромные объемы информации, а не обрабатывать отдельные транзакции.

Чтобы не углубляться в теорию, разницу удобно показать на двух типах задач:

• OLTP - работа приложения: создать заказ, изменить пользователя, найти товар, произвести платеж. Здесь MySQL и PostgreSQL чувствуют себя прекрасно, ведь именно во OLTP они и проектировались.

• OLAP — аналитика: сосчитать 500 млн событий, сгруппировать их по периоду, найти средние или максимальные значения, построить статистику за месяц или год. Это уже сценарий, для которого проектировалась аналитическая СУБД ClickHouse.

ClickHouse база данных не претендует на роль универсальной замены MySQL или PostgreSQL – она решает другой класс задач и работает с большими объемами данных там, где реляционные системы начинают тормозить.

Главное отличие: строки против колонок

Представим таблицу телеметрии с полями time, device_id, temperature, humidity, voltage, current, status, location. MySQL и PostgreSQL используют построчное хранение данных: все поля одной строчки лежат на диске последовательно. ClickHouse устроен иначе: как колонковая СУБД, он реализует колоночное хранение, где значения каждого столбца физически размещены по отдельности.

Если выполнить следующий запрос:

SELECT
    device_id,
    avg(temperature)
FROM metrics
WHERE time >= now() - INTERVAL 7 DAY
GROUP BY device_id;

для него нужны только time, device_id и temperature. Строчная база все равно вынуждена поднять с диска всю строчку вместе с humidity, voltage, status и другими полями, которые не нужны. Колонковая СУБД читает только файлы трех нужных столбцов — остальной диск вообще не трогается.

Отсюда практические преимущества колонкового формата:

• сильное сжатие данных, так как в пределах одной колонки значения однотипны;

• векторизованная обработка  – данные считаются не по одному значению, а блоками;

• параллельная обработка одного запроса на всех ядрах CPU.

Практический кейс: сбор метрик

Типичная ситуация с практикой хостинг-провайдера, где работает связка ClickHouse MySQL: система телеметрии, в которой несколько тысяч устройств или экземпляров приложения регулярно посылают метрики в формате timestamp, source_id, metric, value.

Например:

2026-08-18 12:00:01 | device-1024 | temperature | 26.4
2026-08-18 12:00:01 | device-1024 | voltage     | 228.3
2026-08-18 12:00:01 | device-1025 | temperature | 25.9

Сначала все значения писались в MySQL, и пока данных было немного, проблем не возникало. Затем система выросла. Условные цифры: 5000 устройств, каждый посылает около 10 метрик раз в 10 секунд:

5000 × 10/10 = 5 000 записей в секунду

В сутки: 5000 × 60 × 60 × 24 ≈ 432 млн записей

За 30 дней: ≈ 13 млрд записей

Эти числа нужны не как benchmark, а чтобы ощутить масштаб. MySQL и дальше нормально выполнял роль основной базы приложения - таблицы users, devices, settings, billing работали без сбоев. Проблемой стала именно аналитика по накопленным метрикам: чем больше истории, тем дороже становились агрегации за месяц, графики за долгие периоды, поиск min/max и статистика сразу по тысячам устройств.

Решение – разделить задачи. MySQL остался транзакционной базой, а поток метрик начали писать в ClickHouse для метрик, созданного именно для такого сканирования:

Application пишет в обе базы: MySQL отвечает за users, settings и billing, ClickHouse – за metrics, events и history, а Grafana строит дашборды поверх ClickHouse.

Для визуализации метрик удобно подключить Grafana на хостинге — она выполняет SQL-запросы напрямую в ClickHouse и строит дашборды без дополнительной прослойки. В проектах на PostgreSQL связка ClickHouse PostgreSQL собирается по тому же принципу. ClickHouse тут не поменял MySQL: любая база начала делать ту задачку, для которой она лучше приспособлена. После уноса телеметрии аналитические запросы перестали создавать нагрузку на основную MySQL-базу, а работа с большими временными диапазонами стала заметно более удобной.

Почему ClickHouse хорошо подходит для такого случая

Большое количество INSERT

Метрики в основном добавляются, почти никогда не меняются через UPDATE и читаются позже для аналитики – именно такой сценарий хорошо ложится на ClickHouse. Пакетная вставка (batch insert) блоками, а не отдельный INSERT на каждое значение – базовое практическое правило.

Данные временных рядов

Практически каждая запись имеет timestamp, а типовые запросы фильтруют данные временных рядов за последний час, сутки, месяц, конкретное устройство или конкретную метрику. ClickHouse хорошо подходит именно к таким выборкам.

Агрегатные функции

Чаще всего нужна не конкретная строка, а результат агрегатных функций. count(), avg(), min(), max(), sum(), quantile() — по миллионам записей сразу. Ниже реальный запуск такого запроса на сервере с тестовой таблицей телеметрии на 5 млн строк:

SSH-терминал: группировка и агрегация 1,29 млн строк занимает 0.042 секунды. avg(), max(), count() по колонке temperature.

Компрессия повторяющихся значений

В колонке metric значение вроде temperature повторяются миллионы раз, равно как идентификаторы устройств в device_id. Колонковое хранение позволяет эффективно сжимать именно такие повторяющиеся данные.

MergeTree – основа большинства таблиц ClickHouse

Не стоит углубляться во все table engines ClickHouse – достаточно знать о MergeTree, на котором построено большинство практических таблиц. Именно благодаря MergeTree база данных ClickHouse выдерживает большие объемы данных без потери скорости на вставке:

CREATE TABLE metrics
(
    timestamp DateTime,
    device_id UInt32,
    metric LowCardinality(String),
    value Float64
)
ENGINE = MergeTree
ORDER BY (metric, device_id, timestamp);

SSH-терминал: DROP TABLE и CREATE TABLE ... ENGINE = MergeTree — реальный исполненный запрос на тестовом сервере.

ORDER BY в ClickHouse – это не обычная сортировка в SELECT, а указание, в каком порядке физически сохранять данные на диске. По этим полям строится разреженный первичный индекс: он фиксирует позицию каждой гранулы (типично 8192 строки) и позволяет системе сразу пропускать блоки, где нужных значений нет. Выбирать порядок колонок лучше под типовые запросы приложения.

Materialized view: агрегация вперед, а не «на лету»

Отдельная сильная сторона. инкрементальные materialized view. В отличие от PostgreSQL, где материализированное представление нужно периодически обновлять вручную командой REFRESH MATERIALIZED VIEW, в ClickHouse все происходит иначе: view прикрепляется к исходной таблице и автоматически считает агрегацию только для только что вставленного блока данных — сразу во время каждого INSERT. Результат сразу ложится в готовую таблицу.

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

CREATE TABLE metrics_hourly
(
    hour DateTime,
    device_id UInt32,
    metric LowCardinality(String),
    avg_value AggregateFunction(avg, Float64)
)
ENGINE = AggregatingMergeTree
ORDER BY (metric, device_id, hour);
 
CREATE MATERIALIZED VIEW metrics_hourly_mv TO metrics_hourly AS
SELECT
    toStartOfHour(timestamp) AS hour,
    device_id,
    metric,
    avgState(value) AS avg_value
FROM metrics
GROUP BY hour, device_id, metric;

После этого новые строки, поступающие в metrics, автоматически и небольшими порциями пополняют metrics_hourly. Дашборд в Grafana читает уже готовую агрегированную таблицу — avgMerge(avg_value) по ней отвечает почти мгновенно, независимо от того, сколько сырых строк накопилось в metric за все время. Для потока метрик и событий, описанного выше, это один из главных практических выигрышей ClickHouse: агрегаты не пересчитываются каждый раз заново, а уже готовы к моменту запроса.

Сжатие данных на практике

Эффективное сжатие данных – одна из причин, почему колонковые СУБД экономят место на диске. Но степень сжатия сильно зависит от самих данных: однотипные, повторяющиеся значения сжимаются в разы лучше, чем случайные числа. Вот как это выглядит на реальной тестовой таблице телеметрии:

SSH-терминал: system.columns показывает компрессию по каждому столбцу отдельно. device_id сжался в 178 раз, metric  в 212 раз, а случайные значения value только вдвое.

Это наглядно показывает главный принцип: колонки с небольшим количеством уникальных значений (идентификатор устройства, название метрики) сжимаются в десятки и сотни раз, поэтому для таких полей следует использовать тип LowCardinality. А вот «шумные» числовые показатели сжимаются гораздо скромнее – и это нормально, компрессия здесь не самоцель, а побочный эффект колоночного хранения.

ClickHouse против MySQL и PostgreSQL

ClickHouse можно сравнивать с MySQL и PostgreSQL по типу нагрузки и задачам. Основные различия удобно представить в одной таблице: 

Некорректно говорить, что PostgreSQL или MySQL «не могут» работать с большими таблицами. Вернее: архитектура колоночной СУБД лучше приспособлена именно к аналитическому сканированию больших наборов данных, тогда как связка ClickHouse и MySQL или ClickHouse и PostgreSQL закрывает оба класса нагрузки одновременно.

Когда ClickHouse использовать не нужно

Не стоит ставить ClickHouse только потому, что он «быстрый». Для сайта из 100 000 пользователей, 50 000 заказов и 1 000 000 товаров обычный MySQL или PostgreSQL – гораздо проще и логичнее решение.

ClickHouse вряд ли нужен, если:

• основная нагрузка – CRUD;

• отдельные записи часто изменяются;

• требуются сложные транзакции;

• таблицы небольшие;

• нет тяжелых аналитических запросов;

• данных недостаточно, чтобы преимущества ClickHouse были заметны.

MySQL/PostgreSQL + ClickHouse

Связка ClickHouse и MySQL или ClickHouse и PostgreSQL – очень распространенная архитектура, а не исключение. Транзакционный контур (OLTP) на MySQL или PostgreSQL обычно отвечает за users, orders, payments и devices, то есть актуальное состояние приложения. Аналитический контур (OLAP) на ClickHouse в настоящее время принимает поток events, metrics, analytics и statistics — все, что нужно считать и агрегировать в больших объемах. Одна база не заменяет другую – каждая выполняет ту роль, для которой лучше приспособлена.

Интернет-магазин может хранить заказы в PostgreSQL, а события пользователей — product_view, search, add_to_cart, checkout — писать в ClickHouse для аналитики: так product analytics и observability строятся без погрузки на основную базу. IoT-система держит device, owner, configuration у MySQL, а показатели temperature, voltage, pressure, state  – в ClickHouse, где телеметрия накапливается миллионами событий в сутки.

Что нужно учесть перед установкой ClickHouse

Любая аналитическая СУБД любит много RAM, свободный CPU под параллельную обработку и быстрый диск, а данные лучше писать пакетным способом. При больших объемах дополнительно следует спланировать:

• retention и TTL для автоматического удаления устаревших данных;

• резервное копирование;

• мониторинг свободного места на диске;

• репликацию для отказоустойчивости;

• ориентировочный объем данных за месяц и год вперед.

Для старта такого проекта вполне подойдет сбалансированный VPS-сервер, а для терабайтных объемов имеет смысл выделенный сервер с запасом по диску и памяти.

Заключение

ClickHouse – это не более быстрый MySQL. MySQL, PostgreSQL и ClickHouse решают разные задачи. Если приложение работает с пользователями, платежами, заказами или другими сущностями, реляционная база данных остается типичным выбором. Если же нужно непрерывно собирать миллионы или миллиарды событий и быстро строить по ним отчеты – стоит рассмотреть аналитическую СУБД ClickHouse. Особенно это касается IoT, application metrics, observability, product analytics, телеметрии и других сценариев с большим объемом данных, где ClickHouse и MySQL или ClickHouse и PostgreSQL работают в паре, а не заменяют друг друга.

Подписывайтесь на наш Telegram-канал https://t.me/freehostua, чтобы быть в курсе новых полезных материалов

Смотрите наш канал YouTube на https://www.youtube.com/freehostua.

Мы в чем ошиблись, или что-то пропустили?

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

Дата: 26.08.2026 Автор: Илья Пигович #grafana#linux#mysql

Голосование 1 2 3 4 5