ClickHouse — рушій аналітики в реальному часі зі стеку платформи
Стек 4buildsite включає ClickHouse — колонкову базу даних, створену спеціально для аналізу великих обсягів. На ній ми будуємо модуль статистики трафіку та продажів платформи (у розробці): дані залишаються вашими, а звіти обчислюються окремо від сайту — так спроєктована архітектура.
Що таке ClickHouse і чому ми його використовуємо
ClickHouse — це колонкова база даних типу OLAP (онлайн-аналіз), створена в Yandex для Yandex.Metrica — однієї з найбільших у світі систем веб-аналітики — і опублікована як open source у 2016 році за ліцензією Apache 2.0. Вона побудована для однієї речі, яку виконує винятково: швидких агрегацій на величезних обсягах даних. В архітектурі 4buildsite ClickHouse — рушій, обраний для шару статистики: кожен візит, клік і замовлення стає подією, яку можна проаналізувати.
Секрет — у зберіганні за колонками: замість того щоб читати кожен «рядок» повністю, ClickHouse читає лише колонки, потрібні звіту, і обробляє їх векторизовано, великими блоками. Саме тому запитання на кшталт «скільки відвідувачів було вчора, на кожній сторінці, з кожного джерела» може виконуватися над великими обсягами подій — те, з чим класична рядкова база даних справляється значно важче.
Це не нішева технологія: Cloudflare використовує її для аналізу HTTP-трафіку в глобальному масштабі, а Uber, eBay і Spotify — для аналітики та обробки логів у величезних обсягах. На 4buildsite той самий рушій входить до стеку платформи — без потреби наймати команду інженерів даних.
Статистика в реальному часі — як спроєктовано модуль
Модуль статистики платформи перебуває в розробці, а його архітектура проста: події трафіку збираються асинхронно й записуються в ClickHouse, цілком окремо від серверів, що віддають сторінки. Звіти виконуються в окремій системі, тож аналітика не конкурує з сайтом за його ресурси. Немає важкого стороннього скрипта відстеження — збір мінімальний і first-party.
Звіти в panel.4buildsite.net обчислюватимуться безпосередньо в ClickHouse: трафік за сторінками, джерела відвідувачів, конверсії, продажі за товарами. Часті агрегації попередньо обчислюються через materialized views при кожному записі, тож важкий розрахунок не запускається щоразу, коли ви відкриваєте дашборд.
- Трафік наживо: візити, сторінки, джерела та пристрої — доступні для запитів після збору
- Продажі за товарами, замовлення та конверсії вашого магазину, агреговані на великих обсягах подій
- Історія за місяці й роки за низької вартості — колонкове стиснення зменшує обсяг зберігання в кілька разів порівняно із сирими даними
- Збір асинхронний, звітність працює в іншій системі
PostgreSQL + ClickHouse: чому ми використовуємо обидві
Стек платформи поєднує дві бази даних, бо вони виконують принципово різні завдання. PostgreSQL — це реєстр транзакцій (OLTP): замовлення, платежі, залишки, облікові записи користувачів — операції, що мають бути бездоганно коректними одна за одною, з транзакційними гарантіями. ClickHouse — це аналітичний зал (OLAP): мільйони подій, які зчитуються одночасно, щоб відповісти на ваші запитання про трафік і продажі.
Якби важкі звіти виконувалися на тій самій базі даних, що обробляє замовлення, кожен звіт конкурував би з клієнтами, які платять у цей момент. Розділення OLTP/OLAP усуває цей конфлікт: звіт і замовлення працюють у різних системах і не конкурують за одні й ті самі ресурси. Кожен рушій робить саме те, для чого його створено.
- PostgreSQL: замовлення, платежі Stripe, залишки, клієнти — транзакційна коректність
- ClickHouse: події трафіку, звіти, статистика — агрегація на великих обсягах
- Дизайн передбачає, що відповідні транзакційні дані потрапляють у ClickHouse як події, тож звіти про продажі ніколи не торкаються бази, що обслуговує магазин
Власна аналітика, дружня до приватності — замість Google Analytics
Принцип модуля статистики: дані вашого сайту залишаються в інфраструктурі платформи. Їх не надсилають до Google чи інших рекламних мереж, не продають і не поєднують із зовнішніми профілями користувачів. Це first-party аналітика в прямому сенсі: дані про ваших відвідувачів належать вам.
Оскільки підхід не використовує сторонніх cookie відстеження, відповідність GDPR стає значно простішою. Контекст важливий: у 2022 році органи із захисту даних Австрії, Франції та Італії визнали використання Google Analytics таким, що не відповідає GDPR через передання даних до США. З власною аналітикою, розміщеною в Європі, ця категорія ризику зникає з самого початку.
Є й безпосередня практична користь: звіти, обчислені в ClickHouse, не є вибірковими й не з'являються із запізненням на години, як це буває зі стандартними звітами безкоштовних інструментів аналітики. Повні цифри.
Звіти магазину й маркетплейсу — що надасть модуль
Для інтернет-магазину ClickHouse означатиме відповіді на важливі запитання: які товари продаються, з яких джерел приходять клієнти, що купують, де покидають кошики. Для маркетплейсу з багатьма продавцями ті самі агрегації виконуватимуться на всіх замовленнях: обсяг за продавцями, комісії, топ-товари за категоріями — без ручних експортів і таблиць.
І в масштабі все залишається дешевим. Колонкове стиснення зменшує дані в кілька разів порівняно із сирим форматом, тож ви зберігаєте історію за роки за невеликої вартості зберігання. А коли трафік зростає з тисяч до мільйонів подій, агрегації залишаються керованими — рушій від початку проєктувався для мільярдів рядків, а не адаптувався пізніше.
Переваги та обмеження
Переваги
- Агрегації на великих обсягах подій — колонкове зберігання та векторизована обробка.
- Аналітика працює в системі, відокремленій від тієї, що віддає сторінки.
- Дані трафіку залишаються вашими, в інфраструктурі платформи — без передання до Google чи рекламних мереж.
- Без сторонніх cookie відстеження — простіша відповідність GDPR.
- Потужне колонкове стиснення — історія за роки за низької вартості зберігання.
- Відкритий код (Apache 2.0), без ліцензій за обсяг — вартість не вибухає, коли зростає трафік.
Обмеження
- Це не транзакційна база даних — зміна чи видалення окремих рядків є важкою операцією; тому замовлення й платежі зберігаються в PostgreSQL.
- Оптимізована для запису великими пакетами; багато дрібних частих вставок потребують батчингу — платформа це обробляє, але це реальне обмеження рушія.
- Складні JOIN менш гнучкі, ніж у PostgreSQL — схему подій треба проєктувати під аналіз із самого початку.
- Пошук одного рядка (point lookup) повільніший, ніж в індексованій OLTP-базі, — вона не замінює основну базу магазину.
Короткий висновок
ClickHouse — правильний вибір для аналітики на великих обсягах: статистика трафіку та продажів у реальному часі, з вашими даними, окремо від сторінок сайту. Для замовлень, платежів і залишків лишається PostgreSQL — тому стек 4buildsite поєднує обидві, кожну там, де вона найкраща. Модуль статистики на базі ClickHouse перебуває в розробці.
Таблиця специфікацій
| Можливість | Обмеження / поріг | Типове використання | |
|---|---|---|---|
| Аналітичні агрегації | Колонкове зберігання та векторизована обробка великих обсягів подій | Повільний пошук одного рядка — не для OLTP-запитів | Звіти про трафік і продажі (модуль статистики, у розробці) |
| Приймання подій | Великі обсяги, запис пакетами | Дрібні й часті вставки потребують батчингу / async insert | Збір переглядів сторінок, кліків, замовлень |
| Зберігання й стиснення | Колонкове стиснення (LZ4/ZSTD), у кілька разів менше за сирий обсяг | Дуже випадкові дані стискаються гірше | Історія подій за місяці й роки за низької вартості |
| Оновлення й видалення | Асинхронні mutations для поодиноких виправлень | Непридатний для частих UPDATE окремих рядків | Видалення за GDPR (дані користувача на запит) |
| Materialized views | Попередньо обчислені агрегати при кожному записі | Агрегати треба визначати заздалегідь, для кожного звіту | Дашборди: продажі за днями, товарами, джерелами |
| Реальний час | Події стають доступними для запитів після їх появи | Не є системою потокової обробки на рівні мілісекунд | Статистика трафіку та конверсій наживо |
ClickHouse проти PostgreSQL проти Google Analytics / BigQuery — для аналітики
| Критерій | ClickHouse (4buildsite) | PostgreSQL (для аналітики) | Google Analytics / BigQuery |
|---|---|---|---|
| Швидкість агрегацій на великих обсягах | Колонкове зберігання на великій кількості рядків | Помітно падає на десятках мільйонів рядків (рядкове зберігання) | BigQuery працює з великими наборами даних; GA4 має стандартні попередньо агреговані звіти, без довільних запитів |
| Власність на дані / GDPR | Ваші дані, в інфраструктурі платформи, в Європі | Ваші дані, на ваших серверах | Дані в Google; передання даних GA до США визнано таким, що не відповідає GDPR, органами ЄС у 2022 |
| Cookie та згода | Без сторонніх cookie відстеження | Залежить від власної реалізації | Потребує банера згоди для відстеження |
| Реальний час | Дані доступні для запитів після збору | Можливо, але важкі звіти навантажують транзакційну базу | Стандартні звіти GA4 можуть з'являтися із запізненням на години; потокова передача в BigQuery коштує додатково |
| Вартість на великих обсягах | Відкритий код — вартість лише інфраструктури, що входить у підписку | Зростає з індексами, vacuum і обладнанням на великих обсягах | BigQuery тарифікує за обсяг запитів; enterprise-варіант GA дорогий |
| Вплив на швидкість сайту | Асинхронний збір, звітність в окремій системі | Звіти можуть конкурувати із замовленнями на тій самій базі | Сторонній скрипт (gtag.js) на сторінці — додатковий JavaScript і зовнішні запити |
Поширені запитання
Чи сповільнює ClickHouse мій сайт або магазин?
Ні. ClickHouse працює в системі, відокремленій від тієї, що віддає сторінки, — так спроєктовано архітектуру. Події трафіку надсилаються асинхронно, а звіти ніколи не торкаються бази даних магазину. Статистика не змінює того, як віддаються сторінки.
Чому ви просто не використовуєте Google Analytics?
Три причини. Дані залишаються вашими, в інфраструктурі платформи, а не в Google. Вам не потрібні сторонні cookie відстеження, тож відповідність GDPR простіша — у 2022 році органи Австрії, Франції та Італії визнали GA таким, що не відповідає GDPR. А звіти повні, а не вибіркові чи із запізненням на години.
У чому різниця між ClickHouse і PostgreSQL — навіщо обидві?
PostgreSQL — транзакційна база (OLTP): обробляє замовлення, платежі та залишки по одному, з гарантіями коректності. ClickHouse — аналітична база (OLAP): зчитує мільйони подій одночасно для звітів. Розділення означає, що важкий звіт не виконується в тій самій базі, що й замовлення ваших клієнтів.
Чи безпечні мої дані трафіку та чи відповідають вони GDPR?
Так — за дизайном. Статистика first-party: вона зберігається в інфраструктурі платформи, в Європі, не продається й не передається рекламним мережам. Підхід не використовує сторонніх cookie відстеження, а дані користувача можна видалити на запит відповідно до GDPR.
Наскільки «в реальному часі» працює статистика?
Подія — візит, клік, замовлення — стає видимою у звітах після того, як відбулася. Агрегації за великі періоди (місяці, роки) також підходять, бо ClickHouse створено саме для таких запитів.
Чи потрібно мені щось налаштовувати, щоб мати статистику на сайті?
Не знадобиться. Модуль статистики перебуває в розробці й будується як частина платформи: коли він стане активним в адмін-панелі, збір автоматично запуститься для опублікованих сайтів — без скриптів для встановлення та зовнішніх облікових записів.