Автор оригинала: Vlad Mihalcea.
Вступление
В этой статье я собираюсь объяснить, что такое CDC (Сбор данных об изменениях) и почему вы должны использовать его для извлечения изменений на уровне строк базы данных.
В системах OLTP (Онлайн-обработка транзакций) доступ к данным и их изменение осуществляются одновременно несколькими транзакциями, и база данных переходит из одного согласованного состояния в другое. Система OLTP всегда показывает последнее состояние наших данных, что облегчает разработку интерфейсных приложений, для которых требуются гарантии согласованности данных почти в реальном времени.
Однако система OLTP не является островом, являясь лишь небольшой частью более крупной системы, которая инкапсулирует все потребности в преобразовании данных, требуемые данным предприятием. При интеграции системы OLTP с кэшем, хранилищем данных или Сеткой данных в памяти нам необходим процесс ETL для сбора списка событий, которые изменили данные системы OLTP за определенный период времени.
В этой статье мы рассмотрим различные методы, используемые для захвата событий и их распространения на другие системы обработки данных.
CDC на основе триггеров (Сбор данных об изменениях)
Традиционно наиболее распространенным методом, используемым для записи событий, было использование триггеров на уровне базы данных или приложений. Причина, по которой эта техника все еще очень широко распространена, заключается в ее простоте и знакомстве.
Журнал аудита представляет собой отдельную структуру, в которой записывается каждое действие вставки, обновления или удаления, выполняемое для каждой строки.
Триггеры базы данных
Каждая СУБД поддерживает триггеры, хотя и с несколько иным синтаксисом и возможностями.
PostgreSQL предлагает специальную страницу для реализации журнала аудита на основе триггеров .
Триггеры на уровне приложений
Существуют фреймворки, такие как Hibernate Envers , которые эмулируют триггеры базы данных на уровне приложения. Преимущество заключается в том, что вам не нужно обращать внимание на синтаксис триггеров, специфичный для базы данных, поскольку события в любом случае фиксируются контекстом сохранения. Недостатком является то, что вы не можете регистрировать события изменения данных, которые не проходят через приложение (например, изменения, поступающие из консоли базы данных или из других систем, использующих одну и ту же СУБД).
CDC на основе журнала транзакций (Сбор данных об изменениях)
Хотя триггеры на уровне базы данных или приложений являются очень распространенным выбором для CDC, есть лучший способ. Журнал аудита-это просто дубликат журнала транзакций базы данных (он же журнал повтора или журнал предварительной записи), в котором уже хранятся изменения на основе строк.
Таким образом, на самом деле вам не нужно создавать новую структуру журнала аудита с использованием триггеров базы данных или уровня приложения, вам просто нужно просмотреть журнал транзакций и извлечь из него события CDC.
Исторически сложилось так, что каждая СУБД использовала свой собственный способ декодирования базового журнала транзакций:
- Предложения Oracle Золотые ворота
- SQL Server предлагает встроенную поддержку CDC
- MySQL, так широко используемый для веб-приложений, позволяет вам фиксировать события CDC с помощью различных сторонних решений, таких как База данных LinkedIn
Но в городе появился новый парень! Debezium -это новый проект с открытым исходным кодом, разработанный Red Hat, который предлагает соединители для Oracle, MySQL, PostgreSQL и даже MongoDB.
Мало того, что вы можете извлекать события CDC , но вы можете распространять их в Apache Kafka , который служит основой для всех сообщений, необходимых для обмена между различными модулями крупной корпоративной системы.
Вывод
Если вы используете приложение OLTP, CDC пригодится, когда дело доходит до интеграции с другими модулями в текущей корпоративной системе. Некоторые могут возразить, что использование источника событий лучше и даже может полностью заменить системы OLTP, поскольку вы регистрируете каждое событие заранее и затем получаете последний снимок.
Хотя источник событий имеет большое значение, существует множество приложений, которые могут извлечь выгоду из модели данных OLTP, поскольку события проверяются перед сохранением, что означает, что аномалии устраняются механизмами управления параллелизмом базы данных.
В противном случае Google, который стал пионером MapReduce для BigData с помощью своего хранилища данных Bigtable , не вложил бы столько усилий в создание глобально распределенной системы баз данных , совместимой с ACID, такой как Spanner , которая была разработана для создания критически важных приложений для обработки онлайн-транзакций (OLTP).