Один из основных пунктов при проектировании новой системы — выбор базы данных, которая будет обеспечивать работоспособность. Но на практике часто бывает, что архитекторы и аналитики не учитывают возможные риски, нагрузку и даже задачи системы, не думают о ее развитии. Возможный итог подобного подхода — полный рефакторинг систем на позднем этапе разработки. Или, как меньшее из зол, добавление второй базы (другого типа) под определенные задачи.
Таких затруднений можно избежать, если на этапе проектирования четко определить всю функциональность системы (в том числе и на будущее). А кроме того, понимать различия и особенности типов баз данных, которые будут эту функциональность обеспечивать, чтобы сделать наиболее подходящий архитектурный выбор.
Прежде чем приступать к внедрению базы данных, команда архитекторов наверняка столкнется с сомнениями:
- PostgreSQL начинает тормозить при построении отчетов на 500+ млн строк, с JOIN и агрегацией, а бизнес не готов ждать.
- Раз ClickHouse показал отличную скорость на аналитических данных, давайте «всё туда и положим»?
- Зачем держать две СУБД? Один тип проще в поддержке: меньше DevOps-нагрузки, меньше точек отказа.
Но вот вопрос: действительно ли можно взять ClickHouse и заменить им PostgreSQL?
Архитектурные различия
Чтобы сравнить возможности ClickHouse и PostgreSQL, важно понять их концептуальные различия.
Оценить эту разницу на практике помогут замеры из аналитического проекта с выводом данных на дашборды:
- PostgreSQL тормозит на запросе по таблице логов (около 800 млн строк в Postgre) с фильтрацией по времени и JOIN на пользователей. Время ответа — 40–60 секунд.
- После миграции в ClickHouse с партиционированием по дате и сортировкой по (event_date, user_id) тот же запрос дал результат за 0,6–0,8 секунды.
На основе этих данных можно сделать вывод: формат хранения (строки или колонки) кардинально влияет на производительность анализа, особенно на больших объемах.
Использование PostgreSQL для аналитики
Эффективность применения PostgreSQL в продуктовой аналитике можно увидеть на примере проекта в ecommerce, где база данных использовалась и для транзакций, и для отчетов. Объем заказов — около 100 млн строк.
- Выполнялись сложные запросы: CTE, оконные функции, агрегаты с несколькими JOIN.
- Время формирования отчетов — от 15 до 90 секунд.
- Добавление индексов помогало, но не решало проблему, ломались INSERT/UPDATE производительности (из-за перегрузки индексов).
- Попробовали денормализовать таблицы. В итоге нагрузка на диск выросла, а отчеты всё равно не ускорились.
В результате было принято решение о переносе аналитической части в ClickHouse с дублированием данных через Kafka и Apache Airflow. Отчеты стали формироваться быстрее в 30+ раз.
Использование ClickHouse как OLTP
Проиллюстрировать сильные и слабые стороны такого варианта может построение real-time-системы, где хранятся метрики пользовательской активности. Команда приняла решение использовать ClickHouse вместо PostgreSQL. Однако итогом такого решения стали некоторые трудности:
- У ClickHouse нет нормального UPDATE, нужно либо ждать фоновый мутирующий процесс, либо перезаписывать строку.
- DELETE работает через механизм TTL и может занимать часы.
- Права пользователей, а также связанные сущности (например, связать пользователя с его компанией в отчетах) делать через JOIN неудобно: сильно проседает производительность.
Вывод здесь звучит так: ClickHouse не предназначен для транзакций и хранения полноценных бизнес-данных. Всё, что часто изменяется или требует согласованности, лучше держать в PostgreSQL.
Когда использовать PostgreSQL, когда ClickHouse, а когда — оба?
Используем PostgreSQL, если:
- Нужны полноценные транзакции и консистентность (ACID): CRM, ERP, финансовые системы.
- Часто происходят изменения в данных (UPDATE, DELETE).
- Есть строгие ограничения на целостность данных (FOREIGN KEY, CHECK и т. д.).
- Объем таблицы в пределах десятков миллионов строк и аналитика не основная нагрузка.
В качестве примера здесь можно взять управление подписками и оплатами, где важна точность и атомарность операций. С таким PostgreSQL справляется отлично.
Используем ClickHouse, если:
- Задача — быстро обрабатывать миллиарды строк во временных рядах, логах, метриках или событиях.
- Основной режим — это INSERT и SELECT, почти нет UPDATE и DELETE.
- Нужно масштабироваться горизонтально, обрабатывать сотни тысяч строк в секунду.
- JOIN либо не нужны вовсе, либо нужны, но простые (на компактные справочники).
В этом случае иллюстрацией может выступить хранилище событий пользователей (event storage) в мобильном приложении: миллиарды событий пишутся в ClickHouse и анализируются BI-инструментами.
Используем обе системы вместе, если:
- Важно хранить текущие данные (транзакции, пользователи, бизнес-объекты). Для этого подойдет PostgreSQL.
- Необходимо хранить «исторические»/аналитические данные (логи, события, посещения, clickstream). Здесь лучше использовать ClickHouse.
- Задача — строить дашборды и отчеты. BI-слой может работать с ClickHouse, а веб-приложение — с PostgreSQL.
Как связать их между собой:
- Выгрузки через Kafka + ClickHouse Consumer.
- CDC (Change Data Capture) через Debezium + Kafka.
- Плановые ETL-задания (например, на Airflow).
Например, OLTP-данные храним в PostgreSQL (аккаунты, транзакции, балансы), а агрегаты и отчеты — в ClickHouse. Данные в ClickHouse передаются через стриминг из Kafka.
Краткие итоги
Можно ли заменить PostgreSQL на ClickHouse? В большинстве случаев — нет. Это инструменты для разных задач.
PostgreSQL хорошо справляется с транзакциями, изменяемыми данными, сложными зависимостями. Если попытаться использовать его как OLTP, вы получите боль с UPDATE/DELETE, отсутствие транзакций и риск несогласованных данных.
ClickHouse блестяще решает задачу быстрой аналитики на огромных объемах. Если, наоборот, положить всё в PostgreSQL, получите тормоза на аналитических задачах и проблемы с масштабированием.
Лучшая стратегия, если у вас и транзакции, и аналитика, — это разделение слоев данных: PostgreSQL для оперативного хранения, ClickHouse для анализа. Потери на синхронизацию вполне окупаются скоростью ответа и масштабируемостью.
