Коли ClickHouse дійсно потрібен, а коли — ні

Часто можна зустріти твердження, що ClickHouse — це «дуже швидка база даних», здатна обробляти величезні обсяги інформації. Це правда, але з важливим застереженням: ClickHouse підходить не для всіх сценаріїв. Його висока продуктивність не завжди є достатнім аргументом, щоб повністю відмовитися від звичних реляційних СУБД.

Якщо розглянути MySQL, то при роботі з великими обсягами даних досить швидко проявляються обмеження. У міру зростання таблиць запити починають виконуватися все повільніше, а спроби оптимізації — створення індексів, парціонування, розбиття даних на окремі таблиці — лише частково вирішують проблему. В результаті доводиться витрачати значний час розробників на складні і не завжди надійні обхідні рішення, які не усувають корінь проблеми.

Практичний приклад

У компанії Хостинг Україна ми зіткнулися із завданням пошуку аномалій у трафіку. Для цього необхідно збирати та аналізувати всі HTTP-запити, що надходять на сайти клієнтів. За добу обробляється близько 1,3 мільярда запитів, які надходять з безлічі серверів.

Щоб MySQL справлявся з таким навантаженням, довелося застосовувати цілий набір оптимізацій:

• обмежити термін зберігання даних трьома добами;
• розбити дані на окремі таблиці, щоб видаляти їх повністю, а не виконувати DELETE WHERE date < CURRENT_DATE - INTERVAL 3 DAY;
• сегментувати таблиці для прискорення пошуку за IP-адресами;
• агрегувати IPv6-адреси до мережі /64, оскільки боти часто змінюють IPv6 і відправляють кожен запит з нової адреси;
• мінімізувати кількість полів в індексах, оскільки індекси займають місце і уповільнюють вставку даних;
• реалізувати чергу на вставку даних, оскільки запити надходили більш ніж зі ста серверів кожні п'ять хвилин.

Навіть при всіх цих заходах запити на формування статистики виконувалися повільно і вимагали значного часу очікування.

Перехід на ClickHouse

Після перенесення даних в ClickHouse ситуація змінилася кардинально:

• швидкість вибірки за різними колонками значно зросла навіть без використання індексів;
• для таблиць було налаштовано час життя даних (TTL), і ClickHouse автоматично видаляє застарілі записи;
• обсяг зайнятого дискового простору скоротився за рахунок ефективного стиснення даних;
• відпала необхідність агрегувати IPv6-адреси в /64, оскільки ClickHouse підтримує аналітику по мережах «з коробки»;
• дані тепер вставляються безпосередньо з кожного сервера, без проміжних черг — ClickHouse приймає їх швидко і виконує злиття даних у фоновому режимі.

Для порівняння: хоча MySQL пропонує Archive Storage Engine та InnoDB зі стисненням, перший не підтримує індекси і є вкрай повільним для аналітики, а другий показує посередні результати при OLAP-навантаженнях і великих обсягах даних.

Підсумки

Цей приклад наочно показує, що ClickHouse без зусиль справляється з навантаженням у мільярди записів на добу. При цьому його не варто розглядати виключно як рішення «для дуже великих даних». ClickHouse чудово підходить для зберігання:

• статистики
• логов
• даних про події
• інформації, яку не потрібно оновлювати або вибірково видаляти.

Якщо статистичні запити в MySQL працюють повільно і не піддаються розумній оптимізації — індекси, сегментування і поділ даних по таблицях перестають допомагати — такі дані майже напевно варто перенести в ClickHouse.