PostgreSQL vs ClickHouse для событий

Сравнение PostgreSQL и ClickHouse для хранения и аналитики событий — на примере нагрузки 100M событий в день. Ключевой инсайт: выбор зависит от паттернов записи (batch vs single-row), требований к агрегациям и допустимых затрат на хранение.

ClickHouse — колоночная СУБД, ориентированная на OLAP и высокоскоростные batch-вставки. Официальная документация ClickHouse (2024–2026) указывает, что оптимальный сценарий — буферизация и вставка большими пакетами через INSERT ... VALUES или формат JSONEachRow с буферами; MergeTree-движки компрессируют и сшивают сегменты асинхронно (ClickHouse docs). При той же нагрузке 100M событий/день ClickHouse позволяет хранить данные в сжатом виде; реальный коэффициент сжатия зависит от набора столбцов, но часто достигает 5–10× для текстовых логов (примеры развернутых кейсов в блоге Altinity, 2023–2025).

Use-case: 100M событий в день

100M событий/день = 100 000 000 / 86 400 ≈ 1 157 событий/сек в среднем; пиковая нагрузка ночью/время акции может превышать среднее в 5–10×. При проектировании важно учитывать как среднюю, так и пиковую скорость и паттерн (равномерный поток или бурстовые spikes).

Примерные сценарии и расчёты (датированные 2025):

• Если событие в среднем 400 байт (JSON с минимумом полей), необработанный объём = 100M × 0.4 KB = 40 000 MB ≈ 39 ГБ/день.
• Сжатие в ClickHouse 5× → хранение ≈ 8 ГБ/день (пример из кейсов Altinity/ClickHouse, 2023–2025).
• PostgreSQL (row storage + TOAST + индексирование) даёт больший overhead: 1.5–3× на хранение по сравнению с raw JSON в примерах из описаний PostgreSQL и практик 2022–2025; для наших 39 ГБ это 58–117 ГБ/день.

Скорость вставки

Ключевые факторы: одиночные вставки vs батчи, наличие транзакций/WAL, индексирование, сеть. Все числа далее — приближённые оценки и расчёты по состоянию на 2025–2026.

• PostgreSQL (single-row INSERT внутри транзакций): типичная скорость на одном CPU-ядре 200–2 000 INSERT/s в зависимости от размера строки и числа индексов; профильный пример: на сервере Intel Xeon 8 ядер, NVMe, можно достичь ~10–40k INSERT/s при использовании COPY/пакетной загрузки (источники: PostgreSQL docs & практики DBA, 2022–2025).
• ClickHouse (batch INSERT): при пакетной вставке 10k–1M строк/запрос легко достигаются сотни тысяч строк в секунду на узел при конфигурации с NVMe и 16–32 ядрами; в публичных бенчмарках от вендоров ClickHouse демонстрировал throughput от десятков до сотен тысяч строк/сек в зависимости от размера пакета и схемы (Altinity/ClickHouse blog, 2023–2025).

Практическая интерпретация для 100M/день (~1.2k/s):

• Если события приходят по 1–2 штуки за раз (ручные транзакции, пользователи), PostgreSQL упрощает гарантию ACID и упрощает схему — достаточно одного сервера/кластерной репликации при оптимальной настройке WAL и без большого количества индексов; пример: 1.2k INSERT/s = 1.2k транзакций/с — это легко для PostgreSQL при правильной конфигурации (2025 практики DBA: tune wal_buffers, max_wal_size, synchronous_commit off для латентности).
• Если события приходят батчами (Kafka => consumers буферят 10k записей и шлют пакет), ClickHouse выигрывает: при пакетах 10k записей один узел может принять все данные и выполнить сжатие, гарантирующее меньший I/O. Для 100M/день с пакетами 10k потребуется 10k INSERT-операций в сутки → 1–2 INSERT/с на уровне пиков — компактно для ClickHouse.

-- Пример пакетной вставки в ClickHouse (2026)
INSERT INTO events FORMAT JSONEachRow
{ "ts": "2026-04-01 12:00:00", "user_id": 123, "event": "click" }
{ "ts": "2026-04-01 12:00:00", "user_id": 124, "event": "view" }
-- эффективнее отправлять файлы по 10k+ строк

-- Пример пакетной загрузки в PostgreSQL (COPY, 2026)
COPY events (ts, user_id, event) FROM STDIN WITH (FORMAT csv);
2026-04-01 12:00:00,123,click
2026-04-01 12:00:00,124,view
\.

Скорость чтения и агрегаций

Для аналитики ключевой фактор — сколько данных нужно просканировать. Колонка vs строка даёт количественную разницу.

• Если агрегация использует 2–3 поля из 20 в строке: ClickHouse читает только нужные столбцы — экономия I/O приблизительно равна отношению полного размера строки к сумме нужных столбцов. Пример: строка 1 000 байт, нужные столбцы 100 байт → меньше данных на сканирование в 10× (подтверждение через модель колоночного хранения, ClickHouse docs, 2025).
• PostgreSQL при seq scan считывает полные строки; индексные сканы сокращают объём, но для агрегирования больших срезов индексы не помогают. На реальных задачах агрегации по времени/ключу ClickHouse показывает время ответа в 5–50× лучше для больших наборов (10M+ строк) по публичным кейсам 2023–2025 (Altinity customer stories, блоги вендора).

Конкретный пример: агрегировать 30 дней логов (100M записей) по часу и подсчитать count(user_id). Предположим, мы выбираем только ts и user_id (100 bytes/row):

• PostgreSQL: seq scan 100M × 100 B = 10 GB прочитанных данных; с индексом по ts можно частично ускорить, но всё равно будет чтение большой части таблицы.
• ClickHouse: чтение только двух колонок (например, total 1.6 GB после сжатия при 5×) — итоговая операция займёт значительно меньше времени и памяти (публичные кейсы 2024–2025 показывают ускорение в десятки раз при схожих условиях).

Стоимость хранения

Стоимость — сумма HDD/SSD, репликации, резервного копирования и архивирования в облако. Приведённые цифры датированы 2026 и основаны на типичной облачной цене хранения S3 и оценках требуемого объёма.

• Сырой объём исходных данных: 100M × 400 B = 40 ГБ/день → ~12 ТБ/год (без сжатия).
• ClickHouse: при коэффициенте сжатия 5× (реальные кейсы 2023–2025) → ≈2.4 ТБ/год. Стоимость S3 Glacier/Archive дешевле, но для hot-данных используйте S3 Standard ($0.023/GB/месяц, 2026 цены AWS) → 2.4 TB ≈ $55/месяц за сырые данные на S3; если хранить в ClickHouse на SSD при собственном кластере, стоимость диска + репликация ×3 → CAPEX зависит от провайдера, но относительно S3 часто дороже при масштабах с репликацией.
• PostgreSQL: overhead 1.5–3× → 12 TB/год × 1.5 = 18 TB/год → стоимость S3 примерно $414/месяц при хранении в облаке (но PostgreSQL обычно хранится на блочных дисках, что увеличивает CAPEX/OPEX). Конкретные примеры: крупные компании переходят на ClickHouse для снижения оперативных затрат на хранение логов (кейсы 2022–2025).

Итого: ClickHouse чаще экономичнее по дисковому пространству и облачным расходам для аналитических данных при условии хорошего сжатия; PostgreSQL дешевле для маленьких активных наборов и когда важна транзакционная целостность (ссылки: ClickHouse docs, AWS pricing page 2026).

Какой выбрать для логов?

Логи — это типичный пример: много строк, относительно небольшое число колонок, частые агрегации и фильтры по времени/ключам. Аналитические запросы и ретеншн делают ClickHouse предпочтительным в большинстве случаев.

• Если ваш сценарий: хранение логов от сервисов/микросервисов, агрегации по времени, retention 30–365 дней, и события можно буферить — ClickHouse: при компрессии 5× снижает расходы на диск и сокращает время агрегаций в 5–50× в реальных кейсах (Altinity/ClickHouse 2023–2025).
• Если логи нужны в транзакционном виде для дальнейшей корреляции и редактирования, требуется ACID и сложные join'ы с транзакционными таблицами — PostgreSQL или TimescaleDB (расширение для временных рядов) будет уместнее. Пример: поддерживать audit-логи с возможностью удаления/исправления записей — такие операции сложнее в ClickHouse (ClickHouse 2025: поддержка мутабельности ограничена, есть ReplacingMergeTree, но он даёт ограничения по семантике).

А для BI?

BI-отчёты ориентированы на агрегации, многопользовательские запросы и ad-hoc анализ. Здесь ClickHouse обычно выигрывает по стоимости и скорости, но экосистема и инструменты имеют значение.

• ClickHouse: оптимален для OLAP-дашбордов, fast aggregations, поддерживает SQL и интеграции с Metabase, Superset, Tableau (через драйверы). В публичных примерах 2024–2025 дашборды на ClickHouse возвращают результаты за миллисекунды при объёмах >100M строк.
• PostgreSQL: хорошо подходит для небольших BI-наборов, когда требуется транзакционная логика в том же хранилище, или когда BI-инструмент напрямую работает с реляционной БД. Для больших аналитических нагрузок PostgreSQL обычно требует агрегационных витрин или materialized views (пример: создать отдельный data mart или использовать Citus/Vertica).

Экосистема и поддержка

Экоcистема влияет на интеграции, мониторинг, бэкап и навыки команды.

• PostgreSQL: зрелая экосистема, тысячи библиотек и GUI, поддержка cloud-managed сервисов (RDS/Aurora/Cloud SQL) и расширений (TimescaleDB, Citus). Уровень комьюнити и коммерческой поддержки стабилен с 1997 по 2026 (официальные репозитории и providers).
• ClickHouse: активный рост community и коммерческих провайдеров (Altinity, ClickHouse Inc., cloud-managed ClickHouse). С 2016 по 2026 ClickHouse стал стандартом для OLAP-логов и telemetry; инструменты для ETL/Kafka интеграции также развиты (2023–2025 заметный рост интеграций: Kafka-процессоры, Spark-коннекторы).

Порог входа

Оценка по времени и сложности внедрения:

• PostgreSQL: низкий порог входа для команд с опытом SQL/ACID. Развернуть managed service можно за несколько часов. Документация и администрирование — известные процессы (PostgreSQL docs, 2025).
• ClickHouse: требует понимания колонковой модели, настройки MergeTree, partitioning и буферизации insert'ов. В типичном проекте подготовка схемы/репликации/ретеншн-политики и настройка прометей/фертиляции занимает от нескольких дней до недель у команды с базовыми навыками DBA/DevOps (опыт коммерческих внедрений 2022–2025).

Поддержка и операции

Операционные расходы включают мониторинг, репликацию, бэкапы и ресторы.

• PostgreSQL: строгие инструменты бэкапа (pg_basebackup, pgBackRest), проверенные схемы репликации. Восстановление точки-время (PITR) — стандарт (PostgreSQL docs 2025). Это упрощает соблюдение RTO/RPO для transactional workloads.
• ClickHouse: репликация на уровне таблиц (ReplicatedMergeTree), snapshot/backup механизмы зависят от версии и провайдера; для крупных кластеров обычно применяют бэкап в S3 и инкремен-тальные стратегии. В 2024–2026 ClickHouse улучшил утилиты для бэкапа, но операционные команды отмечают необходимость более сложной orchestration по сравнению с managed PostgreSQL.

Когда выбрать PostgreSQL

Выберите PostgreSQL, если ваши требования включают: много мелких транзакций с жёсткими ACID-ограничениями, сложные транзакции и joins между событиями и торговой/операционной БД, частые обновления/удаления отдельных записей. Конкретный пример: система учёта финансовых событий с потребностью в строгой консистентности и откатах — PostgreSQL (реальные требования банков и финтеха в 2023–2025).

• Требование ACID и транзакции: PostgreSQL гарантирует atomicity/consistency (документация 2025).
• Паттерн: единичные INSERT/UPDATE/DELETE на запись в реальном времени; частые JOIN'ы с реляционными сущностями; малые объёмы (<<1 TB/год).
• Пример настройки для 100M/день в PostgreSQL: sharding по времени + периодические partition exchange, использование COPY для bulk-операций (практики DBA 2024–2025).

Когда выбрать ClickHouse

Выберите ClickHouse, если основной сценарий — хранение и аналитика больших объёмов событий с частыми агрегациями и ретеншном. ClickHouse уменьшит расходы на хранение за счёт сжатия и ускорит аналитические запросы, особенно при выборке ограниченного числа колонок.

• Паттерн: высокая скорость записи батчами или ingestion через Kafka; активное чтение-агрегация по времени/фильтру.
• Ограничения: ClickHouse менее удобен для сценариев с частыми point-updates; его модель предполагает append-only и асинхронную мутацию (ReplacingMergeTree и др.), что влияет на семантику обновлений (ClickHouse docs, 2025).
• Пример: лог-платформа, 100M/день, retention 90 дней → ClickHouse уменьшает storage и ускоряет отчёты (кейсы публичных внедрений 2022–2025).

Сравнительная таблица

1. Архитектура:
   • PostgreSQL — row-based, ACID, WAL (PostgreSQL docs, 2025).
   • ClickHouse — columnar, OLAP-ориентирован, MergeTree (ClickHouse docs, 2025).
2. Вставка:
   • PostgreSQL — лучше для одиночных транзакций; COPY для bulk (пример: COPY достигает десятков тысяч rows/s на NVMe, практики 2023–2025).
   • ClickHouse — оптимален для батчей; высокие throughput при пакетах 10k+ (бенчмарки вендора, 2024–2025).
3. Чтение/Агрегации:
   • PostgreSQL — эффективен для OLTP и небольших выборок; для больших агрегаций требуется витрина/индексы.
   • ClickHouse — Columnar экономит I/O; ускорения 5–50× для больших срезов по кейсам 2023–2025.
4. Стоимость хранения:
   • PostgreSQL — больше overhead из-за row storage и индексов (оценка 1.5–3× выше по сравнению с сырыми данными, 2025).
   • ClickHouse — сжатие 3–10× в зависимости от данных; экономия на облачном хранении при hot-данных (кейсы 2023–2025).
5. Операции и администрация:
   • PostgreSQL — зрелые инструменты для бэкапа и PITR.
   • ClickHouse — требует настройки репликации и бэкапа, но растёт количество managed-сервисов (Altinity Cloud, ClickHouse Cloud, 2024–2026).

Частые вопросы

Какой из вариантов дешевле при хранении 100M событий в год?

Если считать исходный объём 100M × 400 B = ~40 ГБ/день ≈ 14.6 ТБ/год, то разница зависит от сжатия. ClickHouse при сжатии 5× уменьшит объём до ≈2.9 ТБ/год, тогда годовая стоимость хранения в S3 Standard (~$0.023/GB/мес, 2026) ≈ $66/мес; PostgreSQL с overhead 1.5–3× даст 22–44 ТБ/год → $506–$1,012/мес. Эти оценки упрощены и не учитывают репликацию/IOPs/compute.

Что будет с задержками при вставке одиночных событий в ClickHouse?

ClickHouse оптимизирован под батчи. При одиночных INSERT задержка может быть выше, особенно если используется репликация и синхронные fsync. Рекомендуемая практика — агрегировать в небольшие буферы (например, 1–10k событий) и отправлять пакетно. Это снижает latency-penalty и повышает throughput (опыт внедрений 2022–2025).

Почему PostgreSQL использует больше дискового пространства?

PostgreSQL хранит полную строку, индексы и WAL; TOAST хранит большие поля отдельно. Суммарный overhead зависит от числа индексов и типов полей: практические отчёты DBA (2023–2025) показывают 1.5–3× рост по сравнению с raw json. Это объясняется row-based форматом и дополнительными метаданными для MVCC (multi-version concurrency control).

Сколько серверов нужно для ClickHouse при 100M/день?

Количество узлов зависит от SLA, ретеншн-периода и требуемой репликации. Практическое правило: для production-кластера с высокой доступностью — минимум 3 реплики + 3 шарда (итого 6 узлов) для распределения нагрузки и сохранности данных; многие проекты начинают с 3 узлов (sharded не требуются, если скорость на узел достаточна). Конкретные ресурсы CPU/SSD зависят от профиля данных; в 2024–2026 рекомендованы NVMe и 16+ ядер для heavy-OLAP.

Какие инструменты для ETL лучше использовать с ClickHouse и PostgreSQL?

Для ClickHouse часто используют Kafka + ClickHouse Kafka Engine или ingestion через Hashicorp/Vector/Fluentd/Fluent Bit; для PostgreSQL — логические репликации или Debezium для CDC. Обе платформы интегрируются с Airflow/DBT для трансформаций. Выбор зависит от пропускной способности и задержки: Kafka+buffering для больших потоков (кейсы 2020–2025); COPY/pg_bulkload для PostgreSQL при пакетных импорт-операциях.

Для сопутствующих материалов см. также Базы данных и Аналитика.

Итог: PostgreSQL — выбор для транзакционной целостности и простых схем с небольшими объёмами; ClickHouse — для масштабной аналитики и экономии на хранении при batch-ингесте (основано на документации и практических кейсах 2022–2026).