Часто ли вы задумывались о том, как надёжно и в реальном времени реплицировать транзакционные данные из PostgreSQL в высокопроизводительный аналитический движок ClickHouse? В своей статье «Reliably Replicating Data Between PostgreSQL and ClickHouse Part 1 – PeerDB Open Source» Бенджамин Вуттон показывает, что это не обязательно боль и страдания, если использовать такой инструмент, как PeerDB.
Сегодня мы поговорим о том, как PeerDB решает задачу репликации данных, почему PostgreSQL и ClickHouse — идеальный дуэт, а также о собственных «граблях», которые могут встретиться на пути.
Почему PostgreSQL + ClickHouse?
🧲 Противоположности сходятся
PostgreSQL (Postgres) отлично чувствует себя в роли OLTP (Онлайн-обработка транзакций - Online Transaction Processing), обеспечивая быстрые транзакции и гибкую работу с данными. ClickHouse, напротив, создан для OLAP (Онлайн-аналитическая обработка - Online Analytical Processing), где важно обрабатывать огромные объёмы данных и делать это со скоростью «молнии».
🔎 Живые аналитические запросы
Все чаще возникают сценарии, где одна и та же команда хочет работать и с транзакциями, и с глубокой аналитикой одновременно. Если положить всю нагрузку на Postgres, он может «захлебнуться», а значит, логично разгрузить его, добавив ClickHouse.
🚀 Зрелая экосистема
Обе СУБД имеют открытый исходный код, большое сообщество и множество инструментов для интеграции — от обычных плагинов и коннекторов до систем ETL. PeerDB — одно из свежих и перспективных решений именно для связки Postgres→ClickHouse.
PeerDB: что это и почему оно интересно
🧰 Узкая специализация
В отличие от крупных ETL-решений (Debezium, AirByte, Fivetran), PeerDB сосредоточена почти исключительно на Postgres в качестве источника данных. Благодаря этому разработчики уделили особое внимание производительности и поддержке сложных случаев (партиционированные таблицы, комплексные типы).
🪜 Приобретение PeerDB ClickHouse Inc.
В середине 2024 года ClickHouse поглотила PeerDB, и теперь интеграция между ними гораздо глубже: часть функционала PeerDB постепенно внедряется в ClickHouse Cloud (там это называется PostgreSQL CDC for ClickPipes). То есть, если вы развёртываете «ClickHouse в облаке», ожидайте, что PeerDB-подход будет встраиваться «из коробки».
🛠️ Самостоятельное хостинг vs Управляемое решение
Если вам нравится держать все под контролем, можно использовать PeerDB в виде самостоятельного управляемого стека (self-managed). Устанавливаете Docker-контейнеры, управляете жизненным циклом самостоятельно, настраиваете соответствующий пайплайн. Но, если вы хотите «минимум хлопот», у ClickHouse Cloud есть сервис ClickPipes (собственно, PeerDB «под капотом»), который берет на себя всю операционную сложность.
Основные понятия PeerDB
🔗 Источники/Приемники (Peers)
«Peers» — это источники и приёмники (PostgreSQL → ClickHouse). Вам нужно объявить их в конфигурации, указав хост, порт, учётные данные.
🔄 Зеркала (Mirrors)
Затем создаются «зеркала» — по сути, процессы репликации. Вы указываете, какие таблицы перегонять, с какой частотой это делать и надо ли применять так называемые «трансформации».
📦 Изначальная загрузка и CDC (Change Data Capture - Отслеживание изменений данных)
Во время первой репликации (snapshot) PeerDB выгрузит все данные целиком. Далее идёт потоковая синхронизация (Change Data Capture, CDC). Проще говоря, каждый insert, update и delete в Postgres отражается в ClickHouse с минимальным отставанием.
⚙️ Трансформации на лету
В PeerDB есть опция обрабатывать данные в процессе передачи (например, скрывать чувствительные поля, разворачивать JSON). Это уменьшает нагрузку на Postgres и ClickHouse, потому что трансформации идут внутри PeerDB, а не в отдельном шаге ETL.
CDC vs SQL Integration
💡 CDC
PeerDB «слушает» WAL (Write-Ahead Log) Postgres и оттуда узнает об изменениях (стриминговый режим). Минимальная задержка, меньше нагрузка на исходную базу.
🔍 Репликация запросов (Query Replication)
Альтернатива: регулярно делать SQL-запросы в исходной базе, получая «пакеты» обновлений. Это гибче (можно применять WHERE, JOIN и др.), но работает батчами и даёт большую нагрузку на Postgres.
Личный взгляд: обычно при интеграции с OLAP лучше CDC, чтобы не замедлять транзакционный сервер и не задерживать данные.
Пошаговая установка (Self-Managed)
🔽 Шаг 1. Загрузка и запуск
Скачиваем репозиторий, запускаем run-peerdb.sh. Docker-compose поднимет нужные контейнеры: minio, temporal, peerdb-server, peerdb-ui и прочие службы.
🗄️ Шаг 2. Источник данных
В Postgres создаём таблицу, например orders, и заполняем тестовыми данными (1 миллион строк). Отличная возможность оценить производительность.
⚙️ Шаг 3. Настройка PeerDB
Есть два варианта: Web UI на порту 3000 или SQL-команды. Часто удобнее хранить настройки в SQL-скриптах, чтобы весь процесс находился под системой контроля версий.
Пример команд:
CREATE PEER postgres_peer FROM POSTGRES
WITH (host = 'YOUR_POSTGRES_HOST', port = '5432', user = 'postgres', password = 'postgres', database = 'postgres');
CREATE PEER clickhouse_peer FROM CLICKHOUSE
WITH (host = 'YOUR_CLICKHOUSE_HOST', port = '9440', user = 'default', password = 'YOUR_CLICKHOUSE_PASSWORD', database = 'default');
CREATE MIRROR cdc_mirror FROM postgres_peer TO clickhouse_peer
WITH TABLE MAPPING (public.orders:orders)
WITH (do_initial_copy = true);
🔗 Шаг 4. Проверяем репликацию
Через 10–20 секунд в ClickHouse появится таблица orders, а в столбцах _peerdb_synced_at и _peerdb_is_deleted видно, когда строчка «переместилась» из Postgres. При новых insert’ах и update’ах изменения дойдут до ClickHouse «почти мгновенно».
Поведение при апдейтах и удалениях
✏️ Update
Таблица по умолчанию создаётся в ClickHouse как ReplacingMergeTree. Старые версии строк остаются «внутри», но на практике при запросе FINAL увидите только актуальное состояние.
🗑️ Delete
Удаления отражаются флагом _peerdb_is_deleted. Если нужно физическое удаление, стоит настроить MergeTree или использовать материализованные представления.
Эволюция схемы
📐 Добавление поля
PeerDB автоматически создаёт новый столбец в ClickHouse при новом инсерте, если его добавили в Postgres. Однако будьте осторожны: с удалением колонок всё сложнее (поле в ClickHouse остаётся, просто становится NULL).
Самые частые «подводные камни»
🐳 MinIO и внешние подключения
PeerDB временно складывает данные в MinIO (высокопроизводительное распределённое объектное хранилище), прежде чем отправить их в ClickHouse. В Docker-compose MinIO по умолчанию работает на http://host.docker.internal:9001, но, вероятно, придётся указать реальный IP адрес или открыть порты, чтобы ClickHouse мог к нему обратиться.
🐧 Docker Snap
На некоторых системах (например, Ubuntu с Docker из Snap) контейнеры могут не видеть друг друга или не писать на внешний диск. Важно корректно настроить Docker-среду, иначе можно долго искать причину падений.
Итоги и рекомендации
ClickHouse и PostgreSQL — две мощные, но разноплановые СУБД: первая для аналитики, вторая для транзакций. Если вам нужна быстрая «прокладка» для передачи данных, PeerDB выглядит логичным выбором:
🧩 Отточена для Postgres
Фокус на одну СУБД как источник даёт высокую производительность и более гибкую поддержку сложных схем.
🔗 Глубокая интеграция с ClickHouse
С момента покупки PeerDB командой ClickHouse, улучшенная совместимость стала очевидным плюсом.
✅ Open source vs Managed
Если нужна гибкость — запускайте PeerDB в своём окружении. Если цените минимальную операционную боль — используйте ClickHouse Cloud с «встроенным» сервисом.
Перспективы
В следующей части статьи (по словам автора) нам обещают показать, как всё это запускается уже «из коробки» в ClickHouse Cloud при помощи ClickPipes (и PeerDB внутри). Для многих команд это ещё проще, особенно если не хочется самостоятельно поддерживать контейнеры и MinIO.
Но даже в self-managed сценарии PeerDB нельзя назвать сложным решением. Главное — немного разобраться с конфигурацией Docker и наладить сетевые взаимодействия. А дальше репликация будет работать стабильно, поддерживая не только новые вставки, но и обновления, удаления и динамическое расширение схемы.
Ссылка на оригинальную статью
Другие упомянутые ссылки
Если вы хотите ближе познакомиться с тем, как с помощью PeerDB можно настроить CDC-процесс, смело обращайтесь к вышеуказанным ресурсам. И помните: автоматизация репликации данных должна быть надёжной, ведь в современных высоконагруженных системах стабильный поток транзакционных данных в аналитику — это ваш ключ к успеху.