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

Зміст:

• Що таке 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: агрегація наперед, а не «на льоту»

Окрема сильна сторона ClickHouse — інкрементальні 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) по ній відповідає майже миттєво, незалежно від того, скільки сирих рядків накопичилося в metrics за весь час. Для потоку метрик і подій, описаного вище, це один із головних практичних виграшів 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