Репликация Postgres в ClickHouse за 200 мс

WalShadow решает задачу быстрой доставки изменений из Postgres в ClickHouse без логической репликации. Инструмент читает физический WAL напрямую, декодирует его вне источника и пишет блоки в нативном формате ClickHouse. В результате транзакции становятся видны в аналитической СУБД примерно через 200 мс, а пропускная способность достигает 289 тысяч строк в секунду. Такой подход снимает нагрузку на исходный Postgres и убирает промежуточные очереди. Postgres обычно выступает как транзакционная система для оперативной работы, а ClickHouse — как аналитическая база для отчётов и запросов над большими объёмами. Прямая работа с физическим журналом предзаписи позволяет избежать лишних преобразований и очередей, что важно при ограниченных ресурсах источника.

Как устроена обработка WAL

WalShadow работает в четыре этапа. Сначала он отслеживает схему, воспроизводя записи каталога в теневой экземпляр Postgres. Теневой сервер нужен только для отслеживания структуры таблиц и не участвует в обработке самих данных, что снижает риск влияния на основной экземпляр. Затем heap-записи распределяются по пулу декодеров на Rust, которые работают параллельно и не проходят через теневой сервер. Параллельная работа декодеров позволяет масштабировать скорость разбора журнала предзаписи в зависимости от количества ядер, при этом исходный Postgres не тратит ресурсы на декодирование. Далее батчер собирает строки по таблицам в готовые блоки ClickHouse, сохраняя типы данных без конвертации в JSON или другие форматы. Отказ от промежуточных форматов сокращает накладные расходы на сериализацию и десериализацию, что критично для сохранения высокой пропускной способности. Последний этап — параллельная запись блоков через отдельный пул inserter’ов.

Такой конвейер позволяет масштабировать декодирование и вставку независимо. Поскольку блоки приходят не по порядку, WalShadow добавляет к каждой строке позицию LSN из источника. LSN — это номер позиции в журнале предзаписи, который позволяет ClickHouse оставлять последнюю версию по ключу и тем самым обеспечивать конечную согласованность без строгого порядка доставки. Операции, требующие строгого порядка (изменение схемы, truncate), создают барьеры, которые ждут завершения предыдущих записей. Барьеры помогают избежать рассогласования данных при DDL-операциях, но при частых изменениях структуры могут временно снижать общую скорость. Источник при этом несёт нагрузку, близкую к обычной физической реплике, что упрощает планирование ресурсов.

Сравнение с логической репликацией

Традиционные CDC-решения, включая PeerDB, используют логические слоты и декодирование на стороне Postgres. CDC — это механизм захвата изменений данных, а логические слоты — специальная функция Postgres, которая требует дополнительной обработки на источнике. Это создаёт дополнительную нагрузку на источник и приводит к задержкам в несколько секунд. В тесте на одинаковых инстансах c8i.2xlarge WalShadow показал 200 мс против 10 секунд у PeerDB. При этом пропускная способность почти совпала с максимумом самого Postgres — 289 тысяч строк в секунду против 290 тысяч у источника.

WalShadow не требует логических слотов, поэтому не тратит ресурсы на декодирование внутри Postgres. Это особенно важно, когда продуктивный экземпляр уже работает на пределе. Он поддерживает эволюцию схемы: добавление, переименование и удаление колонок, а также создание таблиц. Начальная загрузка, непрерывная репликация, восстановление после перезапуска и плановые переключения источника тоже реализованы. При выборе решения стоит учитывать, что отсутствие логических слотов снижает риск исчерпания ресурсов источника, но требует прямого доступа к файлам WAL, которого нет в большинстве облачных сервисов.

Что учитывать при внедрении

В российских контурах WalShadow интересен командам, которые уже используют физические реплики Postgres и хотят получить аналитику с минимальной задержкой. Инструмент снижает нагрузку на продуктивный Postgres, что важно при ограниченных мощностях. Однако для работы требуется доступ к физическому WAL, поэтому на большинстве managed-сервисов без специальной интеграции его применить не получится. В полностью контролируемых окружениях, где можно развернуть собственный Postgres, ограничений меньше.

Перед запуском стоит оценить объём WAL и пропускную способность сети между источником и ClickHouse. Большой объём журнала предзаписи требует достаточной пропускной способности канала, иначе задержка вырастет. Параллельная запись блоков требует достаточного количества соединений и памяти на стороне ClickHouse. Настройка барьеров для операций схемы помогает избежать рассогласования, но может временно снижать скорость при частых DDL. Документация по параметрам и архитектуре доступна в репозитории проекта. При принятии решения о внедрении полезно сравнить текущую задержку аналитики с целевыми 200 мс и проверить, хватает ли ресурсов ClickHouse для параллельной вставки без влияния на другие запросы.

Источник

Это краткий разбор материала ClickHouse. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: Репликация Postgres в ClickHouse за 200 мс.

Курс по теме — Построение DWH на ClickHouse