Событий в веб‑приложении становится больше 100 миллионов, и PostgreSQL начинает выдавать результат за минуты. Мы сталкивались с этим не раз: клиент просит отчёт по DAU за 90 дней с разбивкой по источникам, а запрос зависает на 40 секунд. ClickHouse — колоночная СУБД, разработанная Яндексом для аналитических нагрузок. Она обрабатывает миллиарды строк за секунды. Наш опыт внедрения ClickHouse в 10+ проектах за 5 лет показывает стабильное ускорение в 10–100x. ClickHouse не заменяет транзакционную базу — это дополнение: PostgreSQL для операционных данных, ClickHouse для аналитики. Мы гарантируем: после настройки вы забудете о тайм-аутах.
ClickHouse даёт экономию бюджета на серверах в 5–10 раз.
Преимущества ClickHouse для аналитики веб-приложений
ClickHouse использует колоночное хранение: данные каждой колонки лежат отдельно — запрос читает только нужные столбцы. Векторизованная обработка позволяет CPU выполнять операции над пачками значений, а не над отдельными строками. Однотипные данные сжимаются в 5–10 раз эффективнее, чем в PostgreSQL. ClickHouse предлагает специализированные движки таблиц, такие как MergeTree, которые оптимизируют хранение и запросы для аналитических сценариев.
MergeTree: устройство и оптимизация
MergeTree — основной движок ClickHouse. Он сортирует данные по ключу ORDER BY и разбивает на гранулы по 8192 строки. При запросе ClickHouse отсекает целые гранулы на основе первичного индекса и дополнительных индексов, таких как bloom_filter. Это даёт pruning на уровне блоков, что значительно сокращает объём сканируемых данных.
Как проектировать схему таблиц?
CREATE TABLE events (
event_date Date,
event_time DateTime,
event_type LowCardinality(String),
user_id UInt64,
session_id String,
tenant_id UInt32,
page_url String,
referrer String,
country LowCardinality(String),
device_type LowCardinality(String),
properties String
) ENGINE = MergeTree()
ORDER BY (tenant_id, event_date, event_type, user_id)
PARTITION BY toYYYYMM(event_date);
ALTER TABLE events ADD INDEX idx_session session_id TYPE bloom_filter(0.01) GRANULARITY 4;
ORDER BY — ключ сортировки, по которому ClickHouse хранит данные. Запросы с фильтрами по tenant_id и event_date используют его для pruning. LowCardinality — оптимизация для колонок с малым количеством уникальных значений (~10k), хранит как dictionary encoding.
Эффективная вставка данных в ClickHouse
ClickHouse оптимизирован под пакетную вставку. Используйте буферизацию, как в примере ниже.
import { createClient } from '@clickhouse/client';
const client = createClient({
host: process.env.CLICKHOUSE_HOST,
username: process.env.CLICKHOUSE_USER,
password: process.env.CLICKHOUSE_PASSWORD,
database: 'analytics',
});
class EventBuffer {
private buffer: EventRow[] = [];
private flushTimer: NodeJS.Timeout;
async push(event: EventRow) {
this.buffer.push(event);
if (this.buffer.length >= 1000) await this.flush();
}
async flush() {
if (!this.buffer.length) return;
const rows = [...this.buffer];
this.buffer = [];
await client.insert({
table: 'events',
values: rows,
format: 'JSONEachRow',
});
}
}
Никогда не вставляйте по одной строке — для высоких нагрузок используйте Kafka Engine.
Как ускорить запросы?
Вот пример аналитических запросов, которые выполняются за секунды на 100M строк.
-- DAU за 90 дней
SELECT event_date, uniqExact(user_id) AS dau
FROM events
WHERE tenant_id = 42 AND event_date >= today() - 90 AND event_type = 'pageview'
GROUP BY event_date
ORDER BY event_date;
-- Воронка конверсии
SELECT
countIf(event_type = 'product_view') AS views,
countIf(event_type = 'add_to_cart') AS cart,
countIf(event_type = 'checkout_start') AS checkout,
countIf(event_type = 'purchase') AS purchases,
round(100.0 * purchases / views, 2) AS conversion_pct
FROM events
WHERE tenant_id = 42 AND event_date BETWEEN '2024-01-01' AND '2024-01-31';
uniqExact — точный подсчёт уникальных. uniq — приближённый (~2% погрешность), на порядок быстрее.
Сравнение скорости: PostgreSQL vs ClickHouse
| Запрос | PostgreSQL (100M строк) | ClickHouse (100M строк) | Ускорение |
|---|---|---|---|
| DAU за 90 дней | 42 сек | 0.4 сек | ~100x |
| Воронка конверсии за квартал | 18 сек | 0.2 сек | ~90x |
| Когортный анализ | 35 сек | 0.6 сек | ~58x |
Materialized Views: автоматическая предагрегация
CREATE MATERIALIZED VIEW daily_metrics
ENGINE = SummingMergeTree()
ORDER BY (tenant_id, event_date, country, device_type)
AS SELECT
tenant_id,
event_date,
country,
device_type,
count() AS events_count,
uniqState(user_id) AS unique_users_state,
uniqState(session_id) AS unique_sessions_state
FROM events
GROUP BY tenant_id, event_date, country, device_type;
SELECT
event_date,
sum(events_count) AS total_events,
uniqMerge(unique_users_state) AS unique_users
FROM daily_metrics
WHERE tenant_id = 42 AND event_date >= today() - 7
GROUP BY event_date;
Материализованные представления автоматически обновляются при вставке и хранят предагрегированные метрики. Это ускоряет типовые отчёты в десятки раз.
Интеграция и эксплуатация
Интеграция с Laravel и Node.js
Для Laravel используйте пакет sanchov/laravel-clickhouse. Добавьте соединение clickhouse в config/database.php и выполняйте запросы как: DB::connection('clickhouse')->select(..., [$tenantId]). Для Node.js — официальный @clickhouse/client, пример вставки выше.
Репликация и TTL
CREATE TABLE events ON CLUSTER analytics_cluster (
...
) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/events', '{replica}')
ORDER BY (tenant_id, event_date, event_type, user_id)
PARTITION BY toYYYYMM(event_date)
TTL event_date + INTERVAL 2 YEAR DELETE;
TTL автоматически удаляет данные старше двух лет. Для compliance можно настроить перемещение в холодное хранилище.
Типичные ошибки и процесс работы
Типичные ошибки
Самая частая ошибка — попытка вставлять данные по одной строке. ClickHouse не предназначен для транзакционных вставок. Вторая — неправильный выбор ключа сортировки ORDER BY. Если фильтр по user_id и event_date, то порядок в ORDER BY должен соответствовать частоте фильтрации. Третья — забыть про Materialized Views для типовых отчётов, что приводит к полному сканированию таблицы.
Что входит в работу
- Анализ текущей модели данных и метрик
- Проектирование схемы events + Materialized Views
- Настройка репликации и TTL
- Код интеграции с Laravel или Node.js
- Документация схемы и запросов
- Обучение команды (1–2 часа)
- Поддержка 1 месяц после внедрения
Этапы и сроки
| Этап | Срок | Стоимость |
|---|---|---|
| Схема events + Materialized Views + интеграция с Laravel | 1–2 недели | индивидуально |
| Когортный анализ, retention, репликация, Kafka Engine | 2–4 недели | индивидуально |
Закажите бесплатный аудит вашей текущей аналитической схемы — наш инженер с 10-летним опытом проанализирует узкие места. Чтобы обсудить детали, свяжитесь с нами через форму на сайте. Окупаемость проекта — 3–6 месяцев за счёт снижения затрат на инфраструктуру.