Руководство по сбору измененных данных (CDC) для PostgreSQL

Эта статья представляет собой подробное руководство по изменение сбора данных (CDC) в PostgreSQL, также известном как Postgres. Он познакомит вас с различными способами реализации Postgres CDC, включая плюсы и минусы, а также автоматическую альтернативу всем ручным методам. 

Также будет затронута важность PostgreSQL CDC. Прежде чем мы начнем, давайте разберемся с некоторыми основами. 

Что такое PostgreSQL? 

PostgreSQL - это открытые источники реляционная база данных система управления (СУБД). Универсальность позволяет использовать его как в качестве базу данных и в качестве хранилища данных, когда это необходимо. 

PostgreSQL также полностью бесплатен, и его пользователи постоянно пользуются обширной разработкой с открытым исходным кодом и надежной поддержкой. Это некоторые из основных причин его впечатляющего долголетия: PostgreSQL существует уже более двух десятилетий и продолжает оставаться одной из наиболее широко используемых реляционных баз данных. для управления данными прямо сейчас 

Возможности и приложения PostgreSQL 

• Помимо своей бесплатности, PostgreSQL также заслужил отличную репутацию благодаря своей адаптивности и расширяемости. Он легко интегрируется с существующими системами и соответствует стандартам SQL, поэтому вы знаете, чего ожидать.
  
• Благодаря встроенной поддержке сбора данных об изменениях Postgres приводит надежный механизм отслеживания и фиксации изменений в базе данных.
• Это Совместимость с ACID, высокая безопасность и возможность обработки ошибок обработки, поэтому вы можете рассчитывать на достоверность данных.
  
• Он поддерживает запросы JSON и SQL.
  
• Будучи реляционной базой данных, PostgreSQL хранит элементы данных в виде таблиц, строки которых также называются кортежами, и каждый кортеж идентифицируется уникальным ключом. В столбцах хранятся атрибуты для каждого соответствующего элемента данных. 

Эти функции делают PostgreSQL правильным выбором для многих приложений. несколько из них включают: 

• Транзакционная база данных: Если вам часто требуется быстрый доступ к информации для использования в продукте или приложении, PostgreSQL — правильный выбор базы данных, поскольку ее реляционная структура извлекает соответствующие данные с высокой скоростью.
• Хранилище данных: База данных хорошо подходит для транзакционных операций с данными, но не для анализа, а для хранилища данных верно обратное. Эти двое дополняют друг друга так что вы можете рычаг ваши данные легче. Совместимость PostgreSQL с инструментами бизнес-аналитики делает его практичным. вариант для выполнения ваших требований к интеллектуальному анализу данных, аналитике и бизнес-аналитике.
• Геолокационные сервисы: Посмотрите на график PostGIS расширение, вы можете используйте PostgreSQL для хранения, индексирования и запроса геопространственных данных по мере необходимости. Это делает это разумный выбор для геолокационных услуг и географических информационных систем (ГИС).
• OLTP-транзакции: PostgreSQL — это обычно используется для транзакций онлайн-обработки транзакций (OLTP) во многих отраслях, в том числе электронная коммерция (онлайн-покупки и обновления акций), банковское дело (переводы средств, снятие наличных в банкоматах)., и проверки баланса), продажи (розничные транзакции, формирование счетов и баллы лояльности), и услуги (бронирование встреч, обновлений услуг, и платежи за услуги оказываемых). 

почему Тебе нужно Postgres CDC? 

Допустим, вам нужны самые актуальные данные для целей отчетности. прямо сейчас, но вы пока не можете его получить, так как следующая синхронизация запланирована на часов отныне. Ручная синхронизация — один из вариантов, но если у вас крупное предприятие, работающее с огромными объемами данных, пакетная обработка может быстро стать препятствием. Это может привести к ошибкам, использованию устаревшей информации и неправильной отчетности.

В конечном итоге это повлияет на ваше принятие решений, поскольку у вас не будет обновленных данных, необходимых для принятия необходимых мер. 

Это именно тот сценарий, которого можно избежать с помощью Postgres CDC. 

Postgres Методы CDC помогают отслеживать и обрабатывать изменения в ваших базах данных. Наиболее частым действием в таких случаях является репликация изменений источника в целевое хранилище данных. Эта позволяет синхронизировать данные между несколькими базами данных. 

Каким Работа PostgreSQL CDC и что она делает? 

Postgres CDC гарантирует, что все системы имеют постоянный доступ к самой последней версии ваших данных, поэтому Вы всегда работаем с актуальной информацией. Постгрес cзависание сбора данных также имеет некоторые дополнительный преимущества, такие как: 

• Postgres CDC может помочь вам снизить надежная затраты на использование сети, поскольку во время каждой синхронизации будут обрабатываться только последние изменения, а не весь набор данных.
• Aаналитика и подобные задачи требуется больше ресурсов выполнить, поэтому частая пакетная обработка влияет производительность базы данных Postgres с течением времени и нарушает ее функциональность. Postgres CDC сначала создает копии базы данных, а затем постепенно обновляет их измененными данными. Этот процесс намного проще чем пакетная обработка, делая вашу базу данных более быстрой и эффективной.
• ВАШЕ Управление основными данными (MDM) Система будет работать более гладко с Postgres CDC в результате. Поскольку измененные данные из разрозненных источников постоянно обновляются в системе MDM, все ваши команды будут использование те же обновленные данные. Это может улучшить сотрудничество и координацию, а также ускорить принятие более эффективных бизнес-решений.
• Вы даже можете использовать изменить сбор данных с помощью Postgres как механизм аварийного восстановления ваших данных. CDC в реальном времени помогает создавать резервные копии критически важных баз данных и создавать резервы, которые могут быть полезны в случаи сбоя системы, атаки вредоносных программ, человеческие ошибки и другие подобные ситуации.    

Meметоды реализации ПостгреSQL Cвисящий Dата Cзахват 

Как обсуждалось выше, Postgres CDC будет отслеживать и реплицировать любые изменения данных в нескольких базах данных. Выбранный вами метод CDC может быть либо пакетным, либо в режиме реального времени, поскольку CDC не есть какие-либо требования, связанные со временем.  

Вы можете реализовать Postgres CDC за несколько дней.чистый способы, основанные на ваших эксплуатационных требованиях, и мы будем взгляните на них поближе ниже: 

Tмонтажники 

Postgres CDC на основе триггеров также известен как «источник событий».". В этом методе создается специальный журнал событий, который служит основным источником информации. Как следует из названия, этот метод в значительной степени опирается на триггеры, которые решающее значение в каждой транзакции базы данных и фиксировать события в реального времени. 

Триггер программирует базу данных на определенное поведение при каждом конкретном событии происходит. Этим событием может быть введение новых данных, обновление существующих данных или удаление существующих данных из базы данных. 

Триггеры Postgres CDC имеют широкие возможности настройки. Вы можете настроить их на запуск до или после упомянутых выше событий, на запуск для каждого отдельного изменения или на запуск один раз для группы изменений. Вы даже можете наложить условия работы на триггеры — они будут запускаться только тогда, когда конкретный кортеж модифицировало или запускаться только в ответ на определенные действия. 

Триггеры в Postgres CDC хорошо работают для отслеживания изменений в таблицах, записи их в другую таблицу и создания журнала каждого изменения. Для реализации Postgres на основе триггеров изменение сбора данныхвы можете создать триггеры аудита в своей базе данных Postgres, которые будут отслеживать все события, связанные с такими действиями, как INSERT, UPDATE и DELETE. 

Поскольку этот метод работает на уровне SQL вы можете обратиться к таблице отслеживания измененных данных и определения все изменения. Вот пример триггерной функции: 

Этот код создаст таблицу с именем 'пользователи_cdc' для хранения информации об изменении данных, сбора информации, такой как идентификатор пользователя, операциитип иона (INSERT, UPDATE, DELETE), временная метка изменения и пользовательские данные. до и после изменений информация. 

Этот код определяет PL/pgSQL функция ('capture_changes«) срабатывает после операций INSERT, UPDATE или DELETE в таблице «пользователи». Ассоциация 'СЛУЧАЙ' заявление определяет тип операции, основанный на Значение of  "TG_OP' (триггерная операция). 

Этот код создает триггер с именем 'пользователи_триггер' в таблице 'users', которая будет срабатывать после любых операций INSERT, UPDATE или DELETE.

В выше Постгрес CDC Например, каждый раз, когда происходит изменение в таблице «пользователи», соответствующий триггер активируетcapture_changes' функция, которая будет регистрировать изменения в 'пользователи_CDC' стол. Таблица CDC будет фиксировать тип операции, временную метку и соответствующие данные до и после изменения.

Вместе эти элементы помогут вам отслеживать все изменения в исходной таблице с течением времени. 

Плюсы Postgres CDC на основе триггеров 

• Postgres CDC на основе триггеров является надежным и всеобъемлющим.
• Сбор всех измененийs и ведение записей происходит в системе SQL.
• Мгновенный захват изменений позволяет обрабатывать события в реальном времени.
• Вы можете создавать триггеры для различных типов событий. 

Минусы Postgres CDC на основе триггеров:

• Поскольку любые создаваемые вами триггеры запускаются в вашей основной базе данных Postgres, они могут замедлить работу базы данных. Как и любая другая операция, выполнение Postgres CDC через триггеры также требуют ресурсов и увеличивают нагрузку на базу данных.
• Минимизация воздействия на ресурсы базы данных предполагает создание еще одной таблицы, зеркально отражающей основную таблицу, и использование этой вторичной таблицы для реализации триггера. Однако вам также потребуется создать отдельный конвейер для отражения любых изменений в любом месте назначения, которое находится за пределами соответствующего экземпляра Postgres триггера.

Запросы 

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

Любой запрос, который вы делаете к базе данных Postgres, будет использовать этот столбец временной метки для получения всех модифицировало учет с момента вашего последнего запроса, а затем отобразить эти зафиксированные изменения.  

Вы также можете использовать скрипты для монитор вашу базу данных Postgres для изменений и записывайте их в целевую базу данных, но это вариант является даже более трудоемким, чем простой запрос к базе данных. 

Продолжение Postgres изменение сбора данных пример выше, здесь как вы будете запрашивать таблицу «пользователи»: 

Этот запрос извлекает все записи из the 'пользователи' стол где "последнее обновление" временная метка больше, чем «2024-01-01». Он используется для получения записей пользователей, которые были обновлены с указанной даты.

Thэто код создаст таблицу 'пользователи_изменения' с участием информация о каждом изменении, например тип операции (INSERT, UPDATE или DELETE), ее временная метка и соответствующие данные до и после изменения.

Плюсы Postgres CDC на основе запросов 

• Это проще, чем настроить Сбор данных об изменениях Postgres с помощью триггеры.
• Это дает у вас больше контроля над процессом CDC.
• Вам не нужны никакие внешние инструменты для CDC на основе запросов. 

Минусы Postgres CDC на основе запросов

• Требуется более активный подход, чем триггерный подход «установил и забыл». Postgres CDC. Вам необходимо будет регулярно запрашивать базу данных, чтобы обеспечить точное и своевременное отслеживание изменений.
• Уровень запросов имеет решающее значение для извлечения данных в этом методе, что может создать дополнительную нагрузку на базу данных Postgres. 

PostgreSQL Логическая репликация 

Postgres CDC с логической репликацией также называется логическим декодированием. Думайте об этом как о потоковом представлении журнала упреждающей записи (WAL). С WAL фиксирует и записывает все изменения данных в базе данных Postgres, эти изменения считаются потоками логического декодирования и классифицируются как логический слот репликации на уровне базы данных. 

Другими словами, слот репликации — это не что иное, как поток изменений, происходящих в базе данных. Каждая база данных может иметь несколько слотов или потоков изменений.  

Реализация PostgreSQL для логической репликации требуется плагин логического декодирования. В Postgres версии 10 и более поздних версиях по умолчанию используется 'pgoutput' плагин. Это позволяет обрабатывать изменения базы данных Postgres как потоки. Однако, если вы используете версию старше 10, вам нужно будет вручную установить плагин, например «декодербуфы' или 'wal2json». 

'pgoutput' Плагин полезен для репликации данных между двумя или более экземплярами PostgreSQL.. Тем не менее, это может быть трудный для передачи данных потока изменений Postgres в другой платформа или база данных. 

Если вы хотите переместить данные потока изменений на платформу, отличную от Postgres, вы можете использовать 'wal2json' плагин для преобразования данных потока изменений в JSON. Это позволит вашим целевым платформам читать его в формате JSON, что проще. чем читать pgoutput's двоичный выход. 

Помимо плагина, еще одного жизненно важного компонента в CDC через логическую реплику PostgreSQLция это модель подписки с издателями и подписчиками. Эта модель подписки позволяет одному или нескольким подписчикам подписаться на одну (или несколько) публикаций с помощью узла издателя. Подписчики извлекают данные из публикаций и могут повторно публиковать их для репликации или дальнейшей реконфигурации. 

Выполните следующие шаги для реализации Postgres CDC с логической репликацией из исходной базы данных (мы будем использовать «пользователи» таблицу из предыдущих примеров) в целевую базу данных, которую мы назовем 'users_changes' таблице.

Не забудьте заменить заполнители, такие как 'source_db' и 'replication_user' с вашей фактической информацией о базе данных. 

Сначала включите логическое представление в файле конфигурации Postgres 'postgresql.conf'. Используйте указанные выше настройки и перезапустите Postgres после внесения этих изменений. 

В этом разделе будет создана таблица с именем «пользователи» и издание под названием «мой_паб" для 'пользователей' стол. Эта публикация является источником изменений, подлежащих тиражированию. 

В этом разделе будет создана таблица с именем "пользователи_изменения" в целевой базе данных для хранения изменений из источника.

Этот код будет установить подписка 'мой_суб", который подключится к исходной базе данных и подпишется на "мой_суб" публикация. 

Этот код определяет функцию триггера 'capture_changes', чтобы зафиксировать изменения в 'пользователей стол. Это явставляет соответствующую информацию в 'пользователей_изменения' стол в зависимости от типа операции (ВСТАВКА, ОБНОВЛЕНИЕ, УДАЛЕНИЕ). Это также создает триггер 'пользователи_триггер', чтобы выполнить эту функцию после каждой строки-файлаизменение скорости 'пользователей таблице. 

Это оператор SQL для мониторинга изменений в логическом слоте репликации с именем 'мой_суб' а также доставая их. Заменять 'мой_суб' с вашим конкретным именем подписки. 

Плюсы Postgres CDC с логической репликацией: 

• CDC на основе журналов позволяет фиксировать изменения данных в реальном времени с использованием механизма, управляемого событиями. Это позволяет последующим приложениям постоянно получать доступ к обновленным данным из базы данных Postgres.
• Этот метод CDC может идентифицировать все виды событий изменений в базе данных Postgres.
• Поскольку этот метод обращается напрямую к файловой системе, он снижает нагрузку на базу данных. 

Минусы Postgres CDC с логической репликацией: 

• Логическая репликация недоступна для версий PostgreSQL старше 9.4.
• В зависимости от варианта использования сложная логика, необходимая для обработки этих событий и их возможного преобразования в операторы для целевой базы данных, потенциально может повлиять на завершение проекта. 

Postgres CDC с использованием журнала упреждающей записи (WAL) 

Postgres CDC как на основе триггеров, так и на основе запросов может создавать задержки и со временем влиять на производительность вашей базы данных. Если, вы бы скорее рычаг встроенные функции Postgres и переназначить их для процессов CDC вместо использования методов, описанных выше, вы можете использовать ВАЛ. 

WAL — это журнал транзакций, в котором отмечаются все изменения в базе данных. Его основная цель — восстановление и обеспечение целостности данных., Что делает это полезно для CDC на основе событий. Поскольку это встроенная функция, вам придется в основном работать с собственными настройками базы данных Postgres, чтобы настроить ее для CDC. 

Ниже приведены шаги, которые необходимо предпринять, чтобы осуществлять Постгрес чансбор данных ge с использованием журнала транзакций: 

Сначала включите WAL в конфигурации Postgres. Хотя обычно это настройка по умолчанию, проверьте 'postgresql.conf' файл для подтверждения. Postgres позволяет пользователям просматривать содержимое WAL. В качестве примера мы будем использовать 'pg_waldump' инструмент. Rзаменить заполнитель 'путь_к_wal_файлу> ' с фактическим путем к вашему файлу WAL при использовании этого кода.

Далее, qПроверьте содержимое WAL с помощью SQL-запросов. "пглогический' пакет расширения включает 'pg_decode', которое является наиболее часто используемым расширением для этой цели.

• 'CREATE EXTENSION' создаст и установит 'пглогический' расширение, которое обеспечивает возможности логической репликации для Postgres.
• Оператор SQL «SELECT» создает логический слот репликации с именем 'мой_слот" с использованием 'pg_create_ological_representation_slot'функция.
  
• "pgoutput' указывает выходной плагин, который будет использоваться для расшифровка изменений и здесь это встроенный плагин вывода для логической репликации.
• 'pg_ological_slot_peek_changes' используется для проверки изменений, зафиксированных в слоте логической репликации.
• "мой_слот' — это запрашиваемый логический слот репликации. Это имя является заполнителем, и вам следует заменить его именем фактического слота, который вы хотите запросить.
• "НОЛЬ НОЛЬ' — здесь вы можете разместить параметры, определяющие диапазон изменений, которые необходимо получить. С использованием 'НОЛЬ НОЛЬ' здесь означает получение всех доступных изменений без какого-либо определенного диапазона. 

Обратите внимание, что вам может потребоваться некоторое кодирование, особенно если Вы планирует автоматизировать извлечение и обработку изменений. 

Плюсы использования WAL для Postgres CDC

• В то время как некоторое кодирование все еще участвует в использовании WAL, в целом он требует меньше кода, чем другие методы Postgres CDC, которые мы обсуждали.
• Сторонние решения и платформы, такие как 'пглогический' доступны для упрощения более сложных этапов процесса. 

Минусы использования WAL для Postgres CDC

• Данные, которые вы извлекаете из WAL, могут быть в необработанном формате. Преобразование его для соответствия структуре данных вашего приложения. требуется Дополнительная работа.
• Мониторинг изменений в WAL может потребовать дополнительных сценариев или автоматизации.
• Понимание и интерпретация записей WAL требуют глубокого понимания внутренней работы вашей базы данных Postgres. 

Automating Postgres CDC сй Astera 

Следующий пример объясняет, как ты можешь автоматизировать вызвать–основанный Постгрес CDC через Astera. Let's предполагать Вы работа с PostgreSQL базу данных и настроили Источник таблицы базы данных для чтения информации из этой базы данных.  

Первое вы будете включить CDC для этих данныхaувидеть по выбор Включить отслеживание измененных данных в таблице. 

Затем выберите, в каких полях вы хотите включить CDC, с помощью Выберите столбцы диалоговое окно. 

В то время как you можно выбрать одно или все поля в базе данных, обязательно выбрать первичный ключ. В этом случае вы можете выбрать СотрудникID. 
 

Как только вы имеете выбрали поля, нажмите «ОК». Вы будете см. диалоговое окно указывая, что вы успешно включили CDC в этой базе данных. 

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

Настройте целевой объект, открыв его свойства. в Определить входные порты для Maпинг ., выберите Upsert установите флажок с источником CDC, поскольку входящие данные будут Вероятно содержать как новые, так и обновленные записи. В Выберите поля для сопоставления базы данных Reшнур, укажите СотрудникID с это первичный ключ, уникальный для каждой записи в исходной базе данных. 

Далее, используйте перетаскивание, чтобы сопоставьте все поля из исходного объекта базы данных с целевым объектом. Поток данных в реализация Postgres CDC завершена. 

Когда вы запускаете поток данных и проверяете окно хода выполнения задания, вы будете Найди это Astera прочитал и написал домен записи из исходную таблицу в таблицу назначения. 

Инкрементный Postgres CDC

Это легко настроить инкрементный CDC в базе данных PostgreSQL, используя Astera, что позволяет загрузить данные от таблица вашей базы данных постепенно вместо полные нагрузки при каждом пробеге.

Давайте Предположим, что мы работа с данными судоходных компаний в этом варианте использования и хотите сохранить эти данные в новом база данных таблице. Мы хотим, чтобы иметь возможность обновить новую таблицу в любое время есть изменение источника без необходимости полной загрузки исходной таблицы.

Что ж используйте предварительно настроенный источник таблицы базы данных с соответствующей информацией. 

Получите доступ к свойствам исходного объекта с помощью щелкнув правой кнопкой мыши его заголовок и выбрав Свойства.

Подключитесь к базе данных и нажмите «Далее», чтобы продолжить. 

На следующем экране вы будете см. Опции добавочного чтения .  

Выберите Дополнительная нагрузка на основе полей аудита as домен Читать стратегию который отобразит дополнительные параметры. 

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

• Добавьте путь к файлу для Информационный файл добавочной передачи, который Astera создает для хранения информации о последней записи таблицы базы данных. Он будет сравнивать этот файл с таблицей базы данных при каждом запуске, чтобы проверить наличие новых записей.
   
• Настройте целевую таблицу путем перетаскивания Назначение таблицы базы данных из Панели инструментов. 

• После настройки сопоставьте источник таблицы с целевым объектом таблицы.  

• Вы будете увидеть, что таблица назначения пуста. Вы можете проверить его содержимое, как показано ниже, и откроется SQL-запрос. для просмотра данных таблицы. 

• При выполнении потока данных проверьте Ход работы окно и ты увидишь это домен записи из исходной таблицы , чему есть доказательства, письменный в таблицу назначения. 

 

• Вы можете проверить это, просмотрев таблицу назначения. 

 

Выбор правильного метода PostgreSQL CDC для вашего случая использования 

Существует несколько методов реализации CDC в базе данных PostgreSQL, и при принятии решения о том, какой метод выбрать, необходимо учитывать несколько факторов. У каждого метода есть свои плюсы и минусы, о которых мы кратко расскажем. изложенные выше. Кроме того, вот еще несколько моментов, о которых стоит подумать: 

Объем данных и частота изменений: 

• В средах с умеренными изменениями данных, требующими отслеживания в реальном времени, лучшим выбором будет CDC на основе триггеров.
  
• Логическая репликация подходит для сценариев высокая скорость изменения данных, поскольку обеспечивает возможности репликации в реальном времени.
• Если в ваших рабочих процессах извлечение изменений данных происходит нечасто, выберите Postgres CDC на основе запросов. 

Производительность и накладные расходы: 

• Postgres CDC на основе триггеров может добавить дополнительные накладные расходы, особенно если задействованы высокие скорости транзакций.
• Логическая репликация не оказывает большого воздействия на исходную систему и проста в использовании, что делает ее правильным выбором для сценариев с высокой производительностью.
• CDC на основе запросов обычно не потребляет слишком много ресурсов, но это может повлиять на производительность при интенсивных запросах. 

Сложность варианта использования: 

• CDC на основе триггеров полезен в сложных случаях, требующих настройки и детального отслеживания изменений.
• Логическая репликация подходит для случаев, когда требуется простота и репликация в реальном времени.
• CDC на основе запросов — это простой вариант для простых случаев использования, не требующих сложных триггеров. 

Интеграция и совместимость: 

• CDC на основе триггеров может легко интегрироваться с вашими текущими приложениями и базами данных.
  
• Логическая репликация идеально подходит для сценариев, где требуется совместимость между различными экземплярами Postgres.
• CDC на основе запросов включает в себя пользовательские запросы. Таким образом, это правильный вариант для удовлетворения индивидуальных потребностей в интеграции. 

Простота и функциональность: 

• CDC на основе триггеров — это надежное решение, предлагающее детальное отслеживание изменений, но это усложняет его. Подходит для сред с большим количеством настроек.
• Логическая репликация обеспечивает здесь правильный баланс, что делает ее практическим выбором для различных сценариев и идеальной для удовлетворения требований репликации в реальном времени.
• CDC на основе запросов довольно прост и гибок, но это означает, что потенциально может потребоваться больше ручного вмешательства. Это правильный метод для случайного извлечения изменений. 

Заключение 

В этом блоге мы подробно рассмотрели различные варианты реализации CDC в PostgreSQL. Мы также обсудили преимущества и недостатки каждого метода и выделили факторы, которые вам следует учитывать. считать прежде чем выбирать метод CDC для вашего предприятия. 

В то время как здесь нет универсальное решение когда дело доходит до перемен Сбор данных, автоматизация процесса должна быть в вашем списке главных приоритетов. В конце концов, как вы реализация Postgres CDC зависит от вашего требования к производительности, настройки настройки и индивидуальный вариант использования. 

At Astera, мы верим в предоставление упрощенного комплексного решения для управления данными. Наш интуитивно понятный интерфейс с возможностью перетаскивания со встроенным–в коннекторах и трансформациях исключает необходимость кодирования и демократизирует операции с данными, делая их одинаково доступными и информативными как для нетехнических, так и для технических заинтересованных сторон. 

Наш пакет позволяет вам упростить Интеграция данных Процессы, построить прочный хранилища данныхи оптимизируйте EDI и Управление API, и все это без написания единой строчки кода. 

Опыт Astera разница. Начинать ваша бесплатная пробная версия сегодня или отправить заявку чтобы начать работу.