ClickHouse vs PostgreSQL для аналитики: где чья сила и как совмещать

Семёнов Евгений Сергеевич, директор АйТи Фреш. «У нас отчёты в BI грузятся по 15 минут, надо что-то делать» — типовой запрос, с которым ко мне приходят раз в три-четыре месяца. Ответ не универсален: иногда хватит индекса в PostgreSQL, иногда нужен партишенинг, а иногда — отдельная колоночная база. Разберу, когда пора ставить ClickHouse и что это даст, на примере реальных чисел из нашей инфраструктуры.

Главное различие: строки против колонок

PostgreSQL — классическая row-oriented СУБД. На диске строки таблицы лежат подряд: все поля первой записи, потом все поля второй. Это оптимально для OLTP: «найди покупателя №12345 и обнови его адрес» — один seek, считал всю строку, обновил.

ClickHouse — column-oriented. Каждая колонка хранится отдельно. Чтобы посчитать SUM(price) за год, ClickHouse читает только колонку price — игнорируя остальные 40 полей. На аналитике это даёт скачок производительности на порядки.

Таблица отличий

Бенчмарк на 2.4 млрд строк

Поставил у нас в дата-центре МТС Москва два одинаковых сервера Dell Xeon Platinum 8280, 256 ГБ RAM, 4 × NVMe 7.68 ТБ. Загрузили таблицу веб-логов за 2 года (2.4 млрд записей, 45 полей). Одинаковые запросы:

-- Агрегация количества запросов по URL за год
SELECT url, COUNT(*) as cnt
FROM weblogs
WHERE event_date >= '2024-01-01' AND event_date < '2025-01-01'
GROUP BY url
ORDER BY cnt DESC
LIMIT 100;

Разница на агрегациях — сотни раз. На точечных апдейтах PostgreSQL выигрывает. Именно поэтому их часто используют вместе.

Гибридная архитектура: OLTP + OLAP

Правильный pattern для среднего бизнеса: PostgreSQL держит транзакционные данные (заказы, пользователи, платежи), ClickHouse — аналитическое хранилище для дашбордов и ML. Данные переливаются через CDC (Debezium → Kafka → ClickHouse) или батчами через postgresql() table function.

-- В ClickHouse
CREATE TABLE orders_analytics (
    order_id UInt64,
    user_id UInt64,
    amount Decimal(12, 2),
    status LowCardinality(String),
    created_at DateTime,
    region LowCardinality(String)
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(created_at)
ORDER BY (region, created_at, user_id)
SETTINGS index_granularity = 8192;

-- Первоначальная загрузка
INSERT INTO orders_analytics
SELECT * FROM postgresql('10.0.0.10:5432', 'shop', 'orders',
  'analytics_reader', 'password');

Когда ClickHouse точно нужен

• Аналитическая таблица больше 100 млн строк с агрегациями.
• Запись метрик, логов, событий со скоростью >50 тыс/сек.
• Отчёты в BI за годовой период выполняются больше минуты.
• Дисковое пространство в PostgreSQL расходуется со скоростью больше 100 ГБ/месяц.
• Нужны оконные функции на больших объёмах (COUNT OVER, SUM OVER).
• Time-series: показания IoT-датчиков, метрики инфраструктуры, биржевые котировки.

Когда хватит PostgreSQL

• Таблицы до 50 млн строк с грамотным индексированием.
• Смешанная нагрузка OLTP+лёгкая аналитика.
• Нужна строгая консистентность, внешние ключи, триггеры.
• Команда не хочет осваивать новую СУБД.
• Можно вынести тяжёлые отчёты в реплику с materialized views.

Базовая установка ClickHouse

# Debian 12
apt install -y apt-transport-https ca-certificates dirmngr
GNUPGHOME=$(mktemp -d) \
gpg --no-default-keyring --keyring /usr/share/keyrings/clickhouse-keyring.gpg \
  --keyserver hkp://keyserver.ubuntu.com:80 \
  --recv-keys 8919F6BD2B48D754

echo "deb [signed-by=/usr/share/keyrings/clickhouse-keyring.gpg] \
  https://packages.clickhouse.com/deb stable main" \
  > /etc/apt/sources.list.d/clickhouse.list

apt update
apt install -y clickhouse-server clickhouse-client
systemctl enable --now clickhouse-server

Движки таблиц

Реальный кейс: e-commerce на 80 млн заказов

В феврале 2025 пришёл клиент — маркетплейс товаров для дома. В PostgreSQL накопилось 80 млн заказов, 900 млн строк детализации, ежедневные дашборды для руководства собирались 40-50 минут. Команда уже думала про Snowflake, но хотела сначала оценить on-premise вариант.

Что сделали за 10 рабочих дней:

• Поставили ClickHouse 24.3 на одном сервере Dell Xeon Platinum 8280 (96 ядер, 256 ГБ RAM, 4 × NVMe 7.68 ТБ) в нашем дата-центре.
• Настроили CDC через Debezium → Kafka → ClickHouse Kafka Engine для orders, order_items, users, products.
• Создали 4 materialized view для типовых дашбордов Metabase.
• Перевели 23 отчёта с PostgreSQL на ClickHouse через Query Rewrite в Metabase.
• Настроили ежедневный резервный dump на S3 через clickhouse-backup.

Результат: дашборды грузятся за 2-6 секунд вместо 40-50 минут, PostgreSQL разгрузился на 70% по CPU (нет больше тяжёлых reporting-запросов), место в продакшене стало увеличиваться на 3 ГБ/мес вместо 35 ГБ/мес (исторические данные переехали в ClickHouse). Стоимость проекта — 265 000 руб. с лицензией нашего железа и сопровождением 3 мес.

Советы из практики

• Не пытайтесь мигрировать всё сразу. Сначала выносите один тяжёлый отчёт и тестируйте производительность.
• LowCardinality для строк с низкой кардинальностью — экономит 50-80% места.
• PARTITION BY toYYYYMM(date) даёт легкое удаление старых данных через DROP PARTITION.
• ORDER BY для MergeTree — ключевой выбор, определяет скорость запросов. Колонки с высокой кардинальностью в конце.
• Бэкап через clickhouse-backup, не через pg_dump-аналог: инкрементальные бэкапы и S3-upload из коробки.
• Мониторинг query_log — видно все запросы, их длительность, потреблённую память.

FAQ — вопросы по ClickHouse и PostgreSQL

Можно ли заменить PostgreSQL на ClickHouse полностью?

Нет. ClickHouse — OLAP-база, не для транзакций. Используйте как дополнение к OLTP-хранилищу.

Какой порядок ускорения даёт ClickHouse на аналитике?

На агрегациях по миллиардам строк обычно в 50-500 раз быстрее PostgreSQL.

Сколько места занимает ClickHouse по сравнению с PostgreSQL?

В 5-10 раз меньше благодаря колоночному сжатию LZ4/ZSTD.

Как переливать данные из PostgreSQL в ClickHouse?

MaterializedPostgreSQL-движок, Debezium+Kafka или прямой INSERT через postgresql() table function.

Когда нужен кластер ClickHouse?

При объёмах больше 10 ТБ или скорости вставки >100 тыс. строк/сек, а также для отказоустойчивости через ReplicatedMergeTree.