В чем различия архитектуры и использования ClickHouse и PostgreSQL

Что проверяют

Понимаете ли вы, почему для аналитики и транзакций берут разные базы и что это меняет в эксплуатации. Следом DevOps-инженера спрашивают про бэкапы, репликацию и то, как данные попадают из PostgreSQL в ClickHouse.

Как отвечать

Главное различие в хранении и профиле нагрузки:

• PostgreSQL: строчное хранение, MVCC, WAL, полноценные ACID-транзакции. Это OLTP: много коротких запросов по отдельным строкам, B-tree индексы, частые UPDATE. Каждое подключение это отдельный процесс, поэтому ставят пулер вроде PgBouncer;
• ClickHouse: колоночное хранение, движки семейства MergeTree, векторное выполнение, сильное сжатие. Это OLAP: агрегации по миллиардам строк с чтением нескольких колонок из сотни. Первичный ключ разреженный, одна метка на гранулу (по умолчанию 8192 строки), и он задаёт порядок данных, а не уникальность.

Отсюда различия в эксплуатации:

• запись: ClickHouse любит редкие большие пачки. Каждая вставка создаёт кусок данных, частые мелкие вставки заканчиваются ошибкой Too many parts. Выручает async_insert или буфер в Kafka;
• изменения: UPDATE и DELETE в ClickHouse это тяжёлые фоновые мутации, дубли убирает ReplacingMergeTree, причём при слияниях, а не сразу;
• репликация: у PostgreSQL потоковая физическая и логическая, у ClickHouse ReplicatedMergeTree через ClickHouse Keeper и шардирование через таблицы Distributed;
• бэкап и мониторинг: pgBackRest или WAL-G с восстановлением на момент времени против BACKUP или clickhouse-backup; pg_stat_* против system.query_log, system.parts, system.merges.

Типичная связка: PostgreSQL остаётся источником истины, изменения через CDC (Debezium и Kafka) уезжают в ClickHouse для отчётов.

Где спотыкаются

Говорят, что ClickHouse «не умеет JOIN». Умеет, алгоритмы соединений сильно развились, но большие соединения требуют памяти и продуманного порядка таблиц.

Делают ClickHouse основной базой приложения с построчными обновлениями и получают мутации, которые идут часами.

Ставят PostgreSQL под аналитику на сотнях миллионов строк и лечат это индексами, хотя упираются в строчное хранение.