ClickHouse — аналитичният двигател в реално време в стека на платформата
Стекът на 4buildsite включва ClickHouse — колонна база данни, създадена специално за анализ на големи обеми. Върху нея изграждаме модула за статистика на трафика и продажбите на платформата (в разработка): данните остават твои, а събирането е отделено от сървърите, които доставят страниците — така е проектирана архитектурата.
Какво е ClickHouse и защо го използваме
ClickHouse е колонна база данни от тип OLAP (онлайн анализ), създадена в Yandex за Yandex.Metrica — една от най-големите системи за уеб анализ в света — и публикувана като open-source през 2016 г. под лиценз Apache 2.0. Изградена е за едно-единствено нещо, което върши изключително добре: бързи агрегации върху огромни обеми данни. В архитектурата на 4buildsite ClickHouse е избраният engine за слоя статистика: всяко посещение, клик и поръчка се превръща в събитие, което може да бъде анализирано веднага.
Тайната е в съхранението по колони: вместо да чете всеки „ред“ изцяло, ClickHouse чете само колоните, нужни на отчета, и ги обработва векторизирано, на големи блокове. Затова въпрос като „колко посетители имахме вчера, на всяка страница, от всеки източник“ получава отговор за под секунда дори върху милиони събития — нещо, което класическата ориентирана към редове база данни решава много по-трудно.
Не е нишова технология: Cloudflare я използва за анализ на HTTP трафика в глобален мащаб, а Uber, eBay и Spotify — за анализи и обработка на логове при огромни обеми. В 4buildsite същият engine е част от стека на платформата — без да наемаш екип от инженери по данни.
Статистика в реално време — как е проектиран модулът
Модулът за статистика на платформата е в разработка, а архитектурата му е проста: събитията за трафика се събират асинхронно и се записват в ClickHouse, напълно отделно от сървърите, които доставят страниците. Няма тежък външен tracking скрипт в страницата — събирането е минимално и first-party.
Отчетите в panel.4buildsite.net ще се изчисляват директно в ClickHouse: трафик по страници, източници на посетители, конверсии, продажби по продукт. Често използваните агрегации се изчисляват предварително чрез materialized views при всеки запис, така че таблото не стартира тежко изчисление всеки път, когато го погледнеш.
- Трафик на живо: посещения, страници, източници и устройства — достъпни за заявки след събирането
- Продажби по продукт, поръчки и конверсии за магазина ти, агрегирани
- История за месеци и години на ниска цена — колонната компресия намалява съхранението многократно спрямо суровите данни
- Събирането е асинхронно, отчитането върви на друга система
PostgreSQL + ClickHouse: защо използваме и двете
Стекът на платформата съчетава две бази данни, защото те вършат фундаментално различни неща. PostgreSQL е регистърът на транзакциите (OLTP): поръчки, плащания, наличности, потребителски акаунти — операции, които трябва да са безупречно коректни една по една, с транзакционни гаранции. ClickHouse е залата за анализ (OLAP): милиони събития, прочетени наведнъж, за да отговорят на въпроси за трафика и продажбите.
Ако тежките отчети се изпълняваха върху същата база, която обработва поръчките, всеки отчет би се състезавал с клиентите, които плащат в този момент. Разделянето OLTP/OLAP премахва този конфликт: поръчката на клиента и твоят отчет са в отделни системи. Всеки engine прави точно това, за което е създаден.
- PostgreSQL: поръчки, плащания през Stripe, наличности, клиенти — транзакционна коректност
- ClickHouse: събития за трафика, отчети, статистика — агрегиране при голям обем
- Дизайнът предвижда съответните транзакционни данни да стигат до ClickHouse като събития, така че отчетите за продажби никога да не докосват базата, която обслужва магазина
Собствен, съобразен с поверителността analytics — вместо Google Analytics
Принципът на модула за статистика: данните на сайта ти остават на инфраструктурата на платформата. Не се изпращат към Google или други рекламни мрежи, не се продават и не се комбинират с външни потребителски профили. Това е analytics first-party в точния смисъл: данните за твоите посетители са твои.
Тъй като подходът не използва външни tracking бисквитки, съответствието с GDPR става много по-просто. Контекстът има значение: през 2022 г. органите за защита на данните в Австрия, Франция и Италия обявиха използването на Google Analytics за несъответстващо на GDPR заради трансфера на данни към САЩ. При собствен analytics, хостван в Европа, тази категория риск изчезва още от старта.
Има и директна практическа полза: отчетите, изчислени в ClickHouse, не са извадкови, за разлика от стандартните отчети в безплатните инструменти за analytics. Пълни цифри.
Отчети за магазин и marketplace — какво ще предостави модулът
За онлайн магазин ClickHouse ще означава отговори на въпросите, които имат значение: кои продукти се продават, от кои източници идват купуващите клиенти, къде се изоставят количките. За multi-vendor marketplace същите агрегации ще се изпълняват върху всички поръчки: обем по продавач, комисионни, топ продукти по категория — без ръчни експорти и без електронни таблици.
И в голям мащаб нещата остават евтини и бързи. Колонната компресия намалява данните многократно спрямо суровия формат, така че пазиш история за години при ниска цена за съхранение. А когато трафикът расте от хиляди до милиони събития, агрегациите остават в зоната на под секундата — engine-ът е проектиран от самото начало за милиарди редове, а не адаптиран впоследствие.
Предимства и ограничения
Предимства
- Агрегации върху милиони събития — отчети с агрегирани данни.
- Analytics върви на система, отделна от тази, която доставя страниците.
- Данните за трафика остават твои, на инфраструктурата на платформата — без трансфер към Google или рекламни мрежи.
- Без външни tracking бисквитки — по-просто съответствие с GDPR.
- Силна колонна компресия — история за години при ниска цена за съхранение.
- Open-source (Apache 2.0), без лицензи на обем — цената не експлодира с растежа на трафика.
Ограничения
- Не е транзакционна база данни — промяната или изтриването на отделни редове е тежка операция; затова поръчките и плащанията стоят в PostgreSQL.
- Оптимизирана за запис на големи пакети; множество дребни и чести insert-и изискват batching — платформата се грижи за това, но е реално ограничение на engine-а.
- Сложните JOIN-и са по-малко гъвкави, отколкото в PostgreSQL — схемата на събитията трябва да се проектира за анализ от самото начало.
- Търсенето на единичен ред (point lookup) е по-бавно, отколкото в индексирана OLTP база — не замества основната база на магазина.
Кратко заключение
ClickHouse е правилният избор за анализи при голям обем: статистика на трафика и продажбите в реално време, с твоите данни, без да засяга скоростта на сайта. За поръчки, плащания и наличности остава PostgreSQL — затова стекът на 4buildsite съчетава и двете, всяка в най-силната си област. Модулът за статистика, изграден върху ClickHouse, е в разработка.
Таблица със спецификации
| Възможност | Ограничение / праг | Типично приложение | |
|---|---|---|---|
| Аналитични агрегации | Под секунда върху милиони събития (колонно + векторизирано) | Бавно при търсене на единичен ред — не е за OLTP lookups | Отчети за трафик и продажби (модулът за статистика, в разработка) |
| Приемане на събития | Големи обеми, записвани на пакети | Дребните и чести insert-и изискват batching / async insert | Събиране на pageview-та, кликове, поръчки |
| Съхранение и компресия | Колонна компресия (LZ4/ZSTD), многократно под суровия обем | Силно случайните данни се компресират по-малко | История на събития за месеци и години, на ниска цена |
| Актуализации и изтривания | Асинхронни mutations за инцидентни корекции | Неподходящо за чести UPDATE върху отделни редове | Изтривания по GDPR (данните на потребител, при поискване) |
| Materialized views | Предварително изчислени агрегати при всеки запис | Агрегатите трябва да се дефинират предварително, за всеки отчет | Табла: продажби по ден, продукт, източник |
| Реално време | Събитията стават достъпни за заявки, след като настъпят | Не е streaming система на милисекундно ниво | Статистика на живо за трафик и конверсии |
ClickHouse срещу PostgreSQL срещу Google Analytics / BigQuery — за анализи
| Критерий | ClickHouse (4buildsite) | PostgreSQL (за анализи) | Google Analytics / BigQuery |
|---|---|---|---|
| Скорост на агрегациите при голям обем | Под секунда върху милиони редове | Забележимо спада при десетки милиони редове (съхранение по редове) | BigQuery е бърз; GA4 има стандартни предварително агрегирани отчети, без свободни заявки |
| Собственост на данните / GDPR | Твоите данни, на инфраструктурата на платформата, в Европа | Твоите данни, на твоите сървъри | Данните са при Google; трансферите на GA към САЩ обявени за несъответстващи на GDPR от органи на ЕС през 2022 г. |
| Бисквитки и съгласие | Без външни tracking бисквитки | Зависи от собствената имплементация | Изисква банер за съгласие за проследяване |
| Реално време | Данни, достъпни за заявки | Възможно, но тежките отчети натоварват транзакционната база | Стандартните отчети на GA4 могат да се появят със закъснение от часове; streaming към BigQuery струва допълнително |
| Цена при голям обем | Open-source — цената е само инфраструктурата, включена в абонамента | Расте с индексите, vacuum и хардуера при големи обеми | BigQuery таксува на обем на заявените данни; enterprise вариантът на GA е скъп |
| Влияние върху скоростта на сайта | Асинхронно събиране, отчитане на отделна система | Отчетите могат да се състезават с поръчките в една и съща база | Външен скрипт (gtag.js) в страницата — допълнителен JavaScript и външни заявки |
Често задавани въпроси
Забавя ли ClickHouse сайта или магазина ми?
Не. ClickHouse върви на система, отделна от тази, която доставя страниците — така е проектирана архитектурата. Събитията за трафика се изпращат асинхронно, а отчетите никога не докосват базата данни на магазина. Сайтът се зарежда също толкова бързо със или без отворена статистика.
Защо просто не използвате Google Analytics?
Три причини. Данните остават твои, на инфраструктурата на платформата, а не при Google. Не са ти нужни външни tracking бисквитки, така че съответствието с GDPR е по-просто — през 2022 г. органи от Австрия, Франция и Италия обявиха GA за несъответстващ на GDPR. И отчетите са пълни, не извадкови.
Каква е разликата между ClickHouse и PostgreSQL — защо и двете?
PostgreSQL е транзакционната база (OLTP): обработва поръчки, плащания и наличности една по една, с гаранции за коректност. ClickHouse е аналитичната база (OLAP): чете милиони събития наведнъж за отчети. Разделянето означава, че тежък отчет е в отделна система от поръчките на клиентите ти.
Данните ми за трафика в безопасност ли са и съответстват ли на GDPR?
Да — по дизайн. Статистиката е first-party: стои на инфраструктурата на платформата, в Европа, не се продава и не се споделя с рекламни мрежи. Подходът не използва външни tracking бисквитки, а данните на потребител могат да бъдат изтрити при поискване, съгласно GDPR.
Колко „в реално време“ е статистиката?
Дадено събитие — посещение, клик, поръчка — става видимо в отчетите след като настъпи. Агрегациите за големи периоди (месеци, години) отговарят също за под секунда, защото ClickHouse е създаден точно за този тип заявки.
Трябва ли да настройвам нещо, за да имам статистика на сайта си?
Няма да е необходимо. Модулът за статистика е в разработка и е изграден като част от платформата: когато стане активен в административния панел, събирането стартира автоматично за публикуваните сайтове — без скриптове за инсталиране и без външни акаунти.