Доцент кафедры Стратегического и инновационного развития Финансового Университета Михаил Хачатурян рассказал о самых популярных на рынке решениях по репликации данных

Репликация данных – это механизм синхронизации содержимого нескольких копий объекта (например, содержимого базы данных). Иными словами – процесс, под которым понимается копирование данных из одного источника в один или несколько приемников. Наиболее частым сценарием использования решений для репликации данных является переход компании с одного IT-решения на другое, например в рамках импортозамещения. Change Data Capture (CDC): захват изменений данных, подход к интеграции данных, основанный̆ на идентификации, регистрации и доставке изменений, внесенных в источники данных, во внешние системы. Наиболее распространенной является технология, основанная на захвате изменений из журналов баз данных источников.
На рынке представлены как коммерческие, так и open source решения для репликации данных, использующие в основе технологии CDC. Одним из наиболее популярных на рынке коммерческих решений CDC долгое время являлось решение Oracle GoldenGate. Однако, в настоящее время необходимость решения задач импортозамещения выводит на первый план российские разработки и open source решения. В тесте участвовали доступные в РФ решения: российская разработка Датафлот Репликация и open source платформа Debezium.
«Датафлот Репликация» – российское коммерческое решение для репликации транзакционных данных, использующее в основе захват изменений данных в журналах баз данных источников (Change Data Capture) и осуществляющее доставку изменений в гетерогенные системы-приемники. Решение зарегистрировано в едином реестре российского ПО. Мастером-дистрибьютором решения – компанией DIS Group – предоставляется техническая поддержка 24x7 на русском языке. Документация и пользовательские интерфейсы доступны на русском языке.
Платформа Debezium: open source проект, по сути, представляет собой набор совместимых с Apache Kafka Connect специализированных коннекторов, осуществляющих чтение изменений журналов БД различных типов и передающих данные об изменениях в топики Apache Kafka. Требует для работы развертывания инфраструктуры Kafka. Техническая поддержка отсутствует. Документация существует только на английском языке. Пользовательские интерфейсы – практически отсутствуют, управление осуществляется из консоли, скриптами или из внешних приложений.

Сценарии использования репликации

Существует несколько наиболее распространенных сценариев использования решений для репликации данных:
• Предоставление актуальных данных для оперативной отчетности: данные из транзакционных систем реплицируются в хранилища данных или в другие системы для получения близкой к реальному времени оперативной отчетности.
• Снижение нагрузки на исходную информационную систему: данные реплицируются из высоконагруженных исходных систем в режиме близком к реальному времени в другие, менее дорогостоящие системы, на которые также переносятся тяжелые запросы пользователей. Таким образом снизив интенсивность запросов на исходной системе возможно обеспечить на ней значительное снижение нагрузки.
• Аудит. С помощью репликации данных вы можете выполнять аудит базы данных в режиме реального времени, например, получать информацию кто и как менял данные в БД. Информация аудита может включать информацию об изменении данных (состояния до и после выполнения операции изменения), время, в которое данные были изменены, тип операции изменения, данные о пользователе, который выполнил изменения данных. Возможно использовать информацию аудита, например для в выполнения регулятивных или внутренних требований, выявления закономерностей активности пользователей, разработки систем обнаружения нелегитимной деятельности или мошенничества и т.п.
• Проекты миграции с минимальным временем простоя. Репликация данных может эффективно использоваться в качестве решения для миграции баз данных и приложений. Использование репликации может обеспечить синхронизацию систем источников и приемников различных типов в режиме близком к реальному времени, и соответственно, обеспечить быстрый переход от старых критически важных систем к новым без простоев или с минимальным временем простоя. При необходимости вы также можете реплицировать данные из новой системы обратно в более старую систему для целей резервирования.

Тестирование

В ходе тестирования были использованы следующие конфигурации репликации: источник СУБД Postgres 15, приемник СУБД Postgres 15, источник СУБД Oracle 21, приемник СУБД Postgres 15. При тестировании для каждого источника использовался набор из трех таблиц (customers, products и orders) и соответствующие им таблицы приемники.
При тестировании репликации в Debezium коннекторы к источникам ставились на паузу, выполнялась генерация изменений в источниках, выполнялся resume коннектора и отслеживалось время с момента старта коннектора до времени появления последнего изменения в таблице БД.
При тестировании репликации в Датафлот Репликации выполнялась генерация изменений в источниках, затем производился запуск задачи, включающей последовательное выполнение задач Парсера, обработки Буфера и Загрузчика и отслеживалось время с момента старта Парсера до
При тестировании использовались следующие сервера: сервер Postgres: 4 Core CPU Intel Xeon CPU X5690 @ 3.47GHz, 8 GB RAM; сервер Oracle: Intel(R) Xeon(R) CPU X5690 @ 3.47GHz, 16 GB RAM; сервер «Датафлот Репликация»/Debezium: 4 Core CPU Intel Xeon Gold 6130 CPU @ 2.10GHz, 32 GB RAM.

Результат

При первоначальной синхронизации PG-PG отставание решения Debezium от «Датафлот Репликация» составляло от 11 раз до 343 раз в зависимости от количества записей в таблице. Также были проведены замеры на время обработки 1 млн и 5 млн инсертов в таблице orders. Время работы коннектора Debezium до момента попадания всех записей в топик кафка при одном миллионе инсертов составило 153 секунд, у «Датафлот Репликация» в аналогичных условиях - 14 секунд. При пяти миллионах инсертов аналогичный показатель составил 397 минут у Debezium и 60 минут у «Датафлот».