Примечание: Все тесты в этой статье проводились с использованием WalShadow в рамках закрытого превью в сентябре и октябре 2026 года, и все показатели отражают состояние среды на тот момент. Значения по умолчанию и поведение могут измениться до общего релиза.
Примечание: Все тесты в этой статье проводились с использованием WalShadow в рамках закрытого превью в сентябре и октябре 2026 года, и все показатели отражают состояние среды на тот момент. Значения по умолчанию и поведение могут измениться до общего релиза.
- При анализе изменений из Postgres в ClickHouse ключевым фактором проектирования является то, насколько малую задержку репликации удается поддерживать.
- Батчинг (пакетная обработка) записей с фиксированным интервалом позволяет находить баланс между задержкой репликации и частотой записи путем настройки этого интервала — вплоть до пропускной способности конвейера. Прямое чтение WAL, ставшее возможным благодаря тому, что ClickHouse управляет обеими сторонами стека, позволило удерживать задержку практически на постоянном уровне при увеличении интенсивности записи.
- Приложение производило запись исключительно в Postgres, а репликация продолжалась во время изменений схемы и операционных событий без какого-либо вмешательства вручную. Использование целевых таблиц имеет несколько нюансов, обусловленных принципом работы WalShadow.
- Проблемы, о которых я сообщал в ходе закрытого превью, были исправлены, и я смог подтвердить каждое исправление, используя те же шаги.
Некоторое время назад я самостоятельно развернул проект с открытым исходным кодом walshadow на EC2 и использовал его для репликации из Postgres в ClickHouse Cloud. Один из участников команды ClickHouse заметил это и связался со мной, после чего у меня появилась возможность опробовать встроенный в ClickHouse Managed Postgres управляемый WalShadow в рамках закрытого превью.
Страница "Sync to ClickHouse" в Managed Postgres предлагает два метода репликации: ClickPipes (существующий вариант) и недавно добавленный WalShadow.
Рисунок 1: Выбор между ClickPipes и WalShadow на первом этапе мастера "Sync to ClickHouse"
ClickPipes — это полностью управляемый конвейер данных, который получает изменения посредством логической репликации Postgres. Источником необязательно должен быть Managed Postgres; также подходят Postgres на Amazon RDS, Google Cloud SQL и другие.
WalShadow не использует логическую репликацию. Он получает тот же физический WAL, который получала бы реплика, декодирует его за пределами Postgres и записывает результат напрямую в ClickHouse в виде блоков. Такой подход возможен потому, что ClickHouse управляет обеими сторонами стека — источником Postgres и назначением ClickHouse, что обеспечивает нативный путь от WAL к ClickHouse. Большинство управляемых сервисов Postgres не предоставляют клиентам доступ к физическому WAL. В документации WalShadow рекомендуется выбирать этот метод, когда требуются минимальная задержка и наименьшие накладные расходы на репликацию.
В течение месяца тестирования я проверял, насколько сильно различаются эти два метода при одинаковых источнике и назначении, остаются ли агрегаты в целевой базе данных корректными, когда приложение пишет только в Postgres, и требуют ли операционные события каких-либо действий от пользователя.
Для сравнения я использовал конфигурацию с 16 vCPU — размер, который также рекомендовала команда разработки WalShadow, чтобы CPU источника не стал узким местом.
Сначала я одновременно настроил WalShadow и ClickPipes на одном и том же источнике, выполняя репликацию в две базы данных в рамках одного сервиса ClickHouse Cloud. Поскольку оба метода реплицируют одни и те же записи в один и тот же момент времени, различия в времени суток или состоянии источника не влияют на сравнение.
Рисунок 2: Настройка теста. Один источник, два метода, две базы данных в одном сервисе ClickHouse Cloud
У ClickPipes есть две настройки синхронизации: интервал синхронизации (Sync interval), определяющий частоту записи в целевую базу, и размер пакета выборки (Pull batch size) — количество строк, считываемых за один раз (по умолчанию 100 000). Запись начинается при достижении любого из этих порогов. У WalShadow есть настройка тайм-аута сброса (Flush timeout) — максимальное время ожидания перед записью в целевую базу. В процессе измерений команда разработчиков изменила тайм-аут сброса WalShadow до 200 мс. Значения в таблице приведены для периода после этого изменения.
Я измерял задержку от «момента вставки и фиксации строки на источнике» до «момента появления строки в целевой базе данных», используя те же часы на том же ноутбуке. Я опрашивал целевую базу каждые 0,1 секунды. В таблице ниже приведены три захода по 120 строк в каждом при скорости 1 строка в секунду. Я установил интервал синхронизации ClickPipes на 60 секунд (по умолчанию), 10 секунд и 1 секунду, и одновременно измерял показатели WalShadow для каждого запуска. Документация рекомендует поддерживать интервал синхронизации выше 10 секунд; 1 секунду я использовал только для того, чтобы посмотреть на поведение системы.
Рисунок 3: Распределение задержек для ClickPipes и WalShadow при низкой скорости записи (1 строка в секунду, 360 строк на настройку; черные вертикальные линии отмечают медианы)
Задержка ClickPipes определяется выбранным вами интервалом синхронизации (Sync interval). Максимальное значение практически точно соответствовало интервалу синхронизации. При увеличении объема записей ClickPipes начинает запись при достижении 100 000 строк, не дожидаясь истечения полного 60-секундного интервала, поэтому задержка падает еще сильнее, чем при 1 строке в секунду. Если задержка в десятки секунд вас устраивает, настройки по умолчанию подходят как есть, а если вам нужны более свежие данные, интервал можно уменьшить, при условии, что скорость записи не превышает пропускную способность конвейера (см. ниже).
Медианная задержка WalShadow составляла около 0,4 секунды в каждом запуске. Максимальное значение один раз достигло 1,42 секунды. Затем я пошагово увеличивал скорость записи с 1 000 до 200 000 строк в секунду (по 3 минуты на каждый шаг). Медиана WalShadow оставалась в диапазоне от 0,37 до 0,41 секунды на каждом шаге, а максимальная задержка при 200 000 строк в секунду составила 1,71 секунды. Загрузка CPU на источнике (16 vCPU) в этот момент составляла около 10%.
Для ClickPipes я измерил те же шаги одновременно с WalShadow при значении интервала синхронизации по умолчанию в 60 секунд, а позже повторил их на свежем источнике того же размера (16 vCPU) с интервалом синхронизации, установленным на 1 секунду. Во время запуска с 1 секундой WalShadow не был подключен, а остальные параметры, такие как размер пакета выборки (Pull batch size) в 100 000 строк, были оставлены по умолчанию. На каждом шаге производилось ожидание догоняния целевой базой данных перед началом следующего шага.
Рисунок 4: Зависимость задержки от роста интенсивности записи (3 минуты на шаг, медиана и максимум, логарифмическая шкала)
При скорости до 50 000 строк в секунду задержка ClickPipes соответствовала настройкам: от 1 до 1,5 секунд при интервале в 1 секунду и составляла всего несколько секунд даже при интервале в 60 секунд, поскольку сначала заполняется пакет размером 100 000 строк. Начиная с 75 000 строк в секунду, задержка продолжала расти в рамках шага при любом значении настройки. При скорости 75 000 строк в секунду и интервале в 1 секунду медианное значение задержки составляло 15 секунд в первую минуту и 74 секунды в последнюю минуту. Судя по тому, сколько времени требовалось целевой базе данных для наверстывания отставания после каждого шага, ClickPipes обрабатывала около 50 000 строк в секунду на каждом шаге, что составляет 180 миллионов строк в час. Более короткий интервал синхронизации сокращает время ожидания строк перед их записью, но не меняет пропускную способность конвейера. Загрузка CPU источника здесь также оставалась на уровне около 10%, поэтому у источника был запас производительности. Я также увеличил вычислительные ресурсы самого ClickPipe с 2 до 8 vCPU в настройках и повторил тесты для 75 000, 100 000 и 200 000 строк в секунду с интервалом в 1 секунду. Медианная задержка составила 34,7, 72,5 и 224,6 секунды, что является улучшением на 10–20 процентов. Исходя из времени устранения отставания, конвейер обрабатывал около 55 000 строк в секунду, а загрузка его CPU оставалась на уровне примерно 2 из 8 доступных ядер.
Помимо задержки, я также проверил, что оба метода реплицируют одинаковые данные. На каждой контрольной точке — всего девять раз — я сравнивал количество строк, суммы и MD5-хеши между источником и двумя целевыми базами данных, и все они совпадали. В ходе последней проверки все 85 618 571 строка в таблице нагрузки совпали во всех трех местах. В последующем запуске ClickPipes 108 178 569 строк на источнике и в целевой базе данных также совпали после завершения всех шагов.
С этого момента я использовал только WalShadow для тестирования шаблона, при котором приложение выполняет запись только в Postgres, а агрегаты считываются из ClickHouse. В качестве источника использовался экземпляр с 2 vCPU.
Я запустил приложение для работы с заказами на 30 минут. Каждые 30 секунд я агрегировал количество заказов и выручку в целевой базе данных для 5-минутного окна, заканчивающегося на 1 минуту раньше, и сравнивал результаты с Postgres в тот же момент времени. Все 61 сравнение совпали. По ходу дела я добавил столбец в таблицу заказов, создал новую таблицу, в которую приложение начало производить запись, и создал индекс. Во всех трех случаях репликация продолжалась без каких-либо действий с моей стороны. Добавленный столбец появился в целевой базе данных сразу же, а новая таблица уже была там, когда я проверил ее примерно через 11 секунд после создания. После остановки нагрузки полное сравнение также дало совпадение вплоть до количества, сумм и разбивки по статусам.
Новые таблицы подхватываются автоматически, если вы выбираете «Выбрать все таблицы» для схемы на шаге выбора таблиц в мастере настройки WalShadow. Если вы выбираете таблицы по отдельности, созданные позже таблицы не включаются. Для приложения, которое постоянно добавляет новые таблицы, выбор варианта «Выбрать все таблицы» избавляет вас от необходимости добавлять их вручную позже.
WalShadow добавляет три столбца в целевые таблицы: _is_deleted для операций удаления, _commit_ts для времени фиксации и _lsn для позиции в WAL. Ниже приведены важные замечания по использованию целевых таблиц. Ни одно из них не является багом; они проистекают из особенностей работы WalShadow.
- Когда одна транзакция производит запись в две таблицы, в целевой базе данные могут ненадолго отобразить изменения только в одной из них. Это происходит потому, что WalShadow формирует блоки для каждой таблицы и записывает их параллельно, и в документации по открытому исходному коду это указано как ограничение. В конечном счете состояние совпало
- Если вы создаете материализованное представление на основе целевой таблицы, строки, поступающие через CDC, также попадают в это представление. Новые версии обновленных строк и строки с _is_deleted = 1 передаются в исходном виде, поэтому вам нужно самостоятельно определить, как представление обрабатывает версии строк и операции удаления
- Для строк, загруженных из резервной копии во время первоначальной загрузки, столбцы _commit_ts и _lsn содержат одинаковое фиксированное значение для каждой строки, а не значения для каждой отдельной транзакции фиксации. Когда я добавил TTL на основе _commit_ts, все эти строки были удалены сразу после добавления TTL. Если вы используете эти столбцы для расчетов прошедшего времени или настройки TTL, применяйте их только к строкам, поступившим через CDC
- Добавление столбцов, TTL или проекции в целевую таблицу не останавливало репликацию (мне удалось добавить проекцию после установки параметра deduplicate_merge_projection_mode в режим rebuild). Если вы удаляете (DROP) целевую таблицу, она создается заново пустой при следующем изменении в таблице-источнике, а предыдущие строки не восстанавливаются
Репликация выполняется в порядке фиксации (commit order). Если имеется одна крупная транзакция, такая как закрытие месяца, следующие за ней более мелкие операции записи должны ждать, пока крупная транзакция не дойдет до целевой базы данных. На источнике с 2 vCPU при вставке 2 миллионов строк в рамках одной транзакции строки, зафиксированные в промежутке, появлялись в целевой базе данных через несколько минут. Таково поведение репликации с упорядочиванием по фиксации. Во время крупных обновлений планируйте увеличение задержки в целевой базе.
При использовании управляемого сервиса перезагрузки источника, изменение его конфигурации и остановка целевой базы данных происходят в результате действий пользователя или регламентного обслуживания. Я протестировал каждый сценарий по одному разу, чтобы посмотреть, что происходит с репликацией.
Рисунок 5: WalShadow после изменения размера источника с 2 до 4 vCPU. Статус остался Running (Работает), а время непрерывной работы (Uptime) не сбросилось
Тайм-аут сброса по умолчанию (Flush timeout) в мастере настройки составляет 500 мс. Даже при значении по умолчанию задержка оставалась ниже 1 секунды, а снижение тайм-аута до 200 мс позволило еще больше уменьшить задержку.
Время от создания WalShadow до начала репликации составляло от 2 до 7 минут по результатам 7 установок в октябре. В период с конца сентября по 1 октября для некоторых установок потребовалось около 15–20 минут. Судя по моим наблюдениям, начальная загрузка формируется из ежедневной резервной копии и последующего WAL.
Одно пожелание по функционалу: в настоящее время единственный способ узнать, что репликация WalShadow остановилась, — проверить статус в консоли. ClickPipes предлагает функции паузы и возобновления, а также страницу журналов (Logs). Кроме того, система прислала мне уведомление по электронной почте, когда целевая база данных остановилась. Согласно документации, «операции и более подробные метрики» находятся в разработке. Аналогичное уведомление для WalShadow облегчило бы его эксплуатацию.
Я общался с командой разработки через общий канал в Slack. Я сообщал о найденных проблемах, прикладывая шаги для воспроизведения и временные метки, а после выпуска исправления проверял его заново, выполняя те же шаги. Ниже приведены основные проблемы в порядке подтверждения их исправления.
Исправления поступали в течение нескольких дней или недель после каждого отчета. Некоторые из них также публиковались в виде изменений в репозитории walshadow с открытым исходным кодом, поэтому я мог впоследствии увидеть первопричину. Например, проблема, из-за которой WalShadow не удавалось запустить даже при пересоздании после изменения размера, возникала потому, что WalShadow пыталась возобновить работу со старой шкалы времени (timeline), хотя шкала источника продвигается вперед при переключении источника на новый узел. То, о чем я сообщил, вошло в продукт, и я смог подтвердить каждое исправление, используя те же шаги. Будучи участником программы предварительного тестирования, я получил удовольствие от этого опыта.
Выбор между этими двумя вариантами начинается с того, где работает ваш Postgres.
- ClickPipes — это надежный инструмент для Postgres, работающего вне ClickHouse Managed Postgres, например на Amazon RDS или Google Cloud SQL. В этом тесте он обрабатывал около 50 000 строк в секунду, а данные полностью совпадали с исходными. Вы можете настраивать задержку с помощью интервала синхронизации (Sync interval), пока скорость записи не превышает возможности пайпа. Инструмент также обладает такими эксплуатационными функциями, как приостановка и возобновление (pause and resume), а также страница логов (Logs page).
- Если ваша база данных Postgres работает на базе ClickHouse Managed Postgres, лучшим выбором для работы с аналитикой в реальном времени является WalShadow. Преимущество в производительности достигается за счет того, что ClickHouse управляет обеими сторонами стека, что обеспечивает нативный путь передачи данных из WAL в ClickHouse. Медианная задержка оставалась на уровне около 0,4 секунды при любой протестированной мной скорости записи, поэтому я бы не стал ограничивать его применение только особыми сценариями с низкими задержками.
Используя WalShadow, я заметил особое внимание разработчиков как к задержкам, так и к пользовательскому опыту. Когда я открывал дашборд на стороне ClickHouse сразу после записи в Postgres, данные уже были на месте. То самое мучительное ожидание «появились данные или нет?», столь характерное для репликации в аналитических системах, просто исчезло, что сделало работу с WalShadow очень приятной.
С помощью WalShadow мне удалось настроить систему, в которой приложение пишет данные только в Postgres, а агрегаты на стороне ClickHouse обновляются автоматически, без каких-либо дополнительных усилий. При задержке около 0,4 секунды аналитика может стать частью самого приложения, отображая только что записанные данные. Это делает приложение по-настоящему работающим в реальном времени, а не с небольшой задержкой. Ограничения касаются выбора таблиц, особенностей использования целевых таблиц и крупных транзакций — все это подробно рассмотрено в предыдущих разделах.
- Медианная задержка WalShadow составляла около 0,4 секунды при любой скорости записи от 1000 до 200 000 строк в секунду. Задержка ClickPipes следовала настройке интервала синхронизации (Sync interval) примерно до 50 000 строк в секунду, а при превышении этого значения возрастала независимо от выбранных настроек или вычислительной мощности пайпа. Оба метода обеспечивали репликацию данных без расхождений с источником.
- В условиях записи из приложений, изменений схемы, перезапусков и изменения размера источника, а также остановки получателя и его перехода в режим автоматического простоя (auto-idle), репликация продолжалась стабильно и без какого-либо ручного вмешательства.
- Все проблемы, о которых сообщалось во время закрытого предварительного просмотра (Private Preview), были успешно устранены, и я смог лично подтвердить каждое исправление, выполнив те же действия.
- ClickPipes для Postgres (документация по ClickPipes Postgres CDC, включая список поддерживаемых источников)
- Представляем WalShadow (блог ClickHouse. Как WalShadow читает физический WAL и записывает блоки по таблицам параллельно)
- Синхронизация с ClickHouse с помощью WalShadow (документация по Managed Postgres. Когда стоит выбирать WalShadow и ограничения периода Private Preview)
- Управление синхронизацией Postgres ClickPipe (значения по умолчанию для интервала синхронизации и размера пакета выборки (Pull batch size), запись при достижении любого из лимитов, а также рекомендация устанавливать интервал не менее 10 секунд)
- Команда не раскрыла предыдущее значение. До внесенных изменений медианная задержка составляла около 1,1 секунды. Команда разработчиков заявила о планах сделать 200 мс новым значением по умолчанию. Позднее, в начале октября, в мастере настройки появилась возможность для пользователей самостоятельно задавать тайм-аут сброса данных (Flush timeout, значение по умолчанию — 500 мс; см. раздел об операционных событиях)
- walshadow: Limitations (Документация по открытому исходному коду. Изменения в разных таблицах в рамках одной транзакции могут становиться видимыми в ClickHouse в разные моменты времени)
