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

«У нас отчёты в BI грузятся по 15 минут, что делать?!» — этот вопрос я, Евгений Семёнов, директор ITFresh, слышу постоянно. Каждые три-четыре месяца кто-то приходит с такой проблемой. И знаете, волшебной таблетки здесь нет. Порой достаточно добавить пару индексов в PostgreSQL. В других случаях придётся разбивать таблицы на части — это называется партишенинг. А иногда, чего уж там, без колоночной базы данных просто никуда. Вот сегодня и поговорим: когда стоит присмотреться к ClickHouse, какие реальные плюсы он даёт и как это подтверждают цифры из нашей инфраструктуры.

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

PostgreSQL — это такой классический «строчно-ориентированный» зверь среди СУБД. Представьте: данные на диске хранятся по строкам. Вот все поля первой записи, тут же следом — все поля второй. Для OLTP-задач это просто идеально! Нужно найти покупателя №12345 и изменить его адрес? База быстро находит всю строку целиком, мгновенно считывает её, обновляет, и готово. Никаких лишних телодвижений.

А вот ClickHouse — это совсем другая история, он «колоночно-ориентированный». Что это значит? Каждая колонка хранится отдельно от остальных. Допустим, вам нужно посчитать общую сумму всех продаж (SUM(price)) за целый год. ClickHouse просто возьмёт и прочитает только одну эту колонку с ценами, начисто игнорируя остальные, может быть, 40 полей вашей таблицы. Понимаете? Для аналитики это даёт просто сумасшедший прирост производительности — в сотни, а то и тысячи раз!

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

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

Мы решили не быть голословными и устроили тест-драйв. В нашем дата-центре МТС Москва установили два идентичных сервера: оба Dell с Xeon Platinum 8280, по 256 ГБ RAM и четырьмя NVMe дисками на 7.68 ТБ каждый. Затем загрузили на них гигантскую таблицу веб-логов за два года — это 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;

Разница в скорости агрегаций? Сотни раз, и ClickHouse там просто король. А вот если нужно точечно что-то обновить, тут PostgreSQL вне конкуренции. Именно поэтому в реальной жизни их часто используют в связке — каждый делает то, что умеет лучше всего.

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

Для компаний среднего размера, на мой взгляд, идеальная схема выглядит так: PostgreSQL прекрасно подходит для всех транзакционных данных — это и заказы, и профили пользователей, и, конечно, платежи. А вот ClickHouse берёт на себя роль мощного аналитического склада, где хранятся все данные для ваших дашбордов и крутых ML-систем. Спрашиваете, как данные перемещаются между этими базами? Как правило, либо через CDC-механизмы, например, Debezium, который отправляет всё в Kafka, а оттуда уже в ClickHouse. Либо же мы используем батчевые загрузки, часто через специальную функцию `postgresql()` в самом ClickHouse.

-- В 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 тысяч в секунду? PostgreSQL уже не вывезет.
• BI-отчёты за целый год считаются дольше минуты? Вот тут уже стоит задуматься.
• Ваш PostgreSQL «ест» дисковое пространство со скоростью больше 100 ГБ в месяц? Это уже серьёзно.
• Используете оконные функции типа COUNT OVER или SUM OVER на огромных объёмах данных? Обычные базы тут быстро сдаются.
• Работаете с тайм-сериями: собираете показания IoT-датчиков, метрики инфраструктуры или биржевые котировки? ClickHouse создан для этого.

Когда хватит 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 для основных таблиц: `orders`, `order_items`, `users`, `products`. Схема простая: Debezium отправляет данные в Kafka, а оттуда их забирает ClickHouse Kafka Engine.
• Для стандартных дашбордов в Metabase мы создали 4 materialized view. Теперь они открываются моментально, а данные всегда актуальны.
• У нас был объёмный проект: перевели 23 отчёта с PostgreSQL на ClickHouse. Сделали это через Query Rewrite прямо в Metabase. Экономия времени колоссальная, представляете?
• Куда же без надёжных бэкапов? Мы настроили ежедневный автоматический дамп. Он выгружается на S3 с помощью `clickhouse-backup`. Удобно и без лишних хлопот.

Результаты, честно говоря, нас самих впечатлили! Дашборды, на которые раньше уходило по 40-50 минут ожидания, теперь готовы всего за 2-6 секунд. PostgreSQL прямо-таки вздохнул с облегчением: его CPU разгрузился на целых 70%, ведь мы перенесли с него все эти тяжёлые отчётные запросы. И это ещё не всё! Места на продакшн-серверах теперь требуется всего 3 ГБ в месяц вместо прежних 35 ГБ, потому что вся огромная историческая информация переехала в ClickHouse. Весь проект под ключ — включая лицензии на наше «железо» и три месяца нашей поддержки — обошёлся клиенту в 265 000 рублей.

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

• Важный момент: не пытайтесь мигрировать всё сразу! Это типичная ошибка. Начните с одного, самого тяжёлого отчёта. Перенесите, протестируйте производительность, и только потом двигайтесь дальше.
• Используйте `LowCardinality` для строковых полей с низкой кардинальностью. Это работает как магия: экономит от 50 до 80% дискового пространства. Проверено на практике!
• Хотите легко удалять устаревшие данные? Мы рекомендуем `PARTITION BY toYYYYMM(date)`. Это позволяет простым `DROP PARTITION` быстро очистить место. Без лишних сложностей.
• Для MergeTree-таблиц выбор `ORDER BY` — это ключевой фактор. Он напрямую влияет на скорость запросов, так что подойдите к нему внимательно. И запомните: колонки с высокой кардинальностью всегда ставьте в конец.
• Забудьте про аналоги `pg_dump` для ClickHouse. Наш выбор — `clickhouse-backup`. Почему? Потому что он из коробки умеет делать инкрементальные бэкапы и сразу заливать их на S3. Это же так удобно и надёжно!
• Мы всегда советуем мониторить `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.