Захват изменения данных

В базах данных захват изменения данных (change data capture — CDC) представляет собой набор шаблонов разработки программного обеспечения, используемых для определения и отслеживания данных, которые изменились, чтобы можно было предпринять действия с использованием изменённых данных.

CDC — это подход к интеграции данных, основанный на идентификации, регистрации и доставке изменений, внесенных в корпоративные источники данных, во внешние системы.

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

Методология

Разработчики системы могут настроить механизмы CDC несколькими способами на одном или нескольких системных уровнях от уровня логики приложения до уровня физического хранилища.

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

Отметки времени в строках

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

Номера версий в строках

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

Существует несколько методов для выполнения CDC с номерами версий.

Использование в оптимистичной блокировке

Номера версий могут быть полезны как в реляционных систем управления базами данных (СУБД), так и с оптимистическими блокировками в системах управления c ACID транзакциями. Например, в сценариях «чтение-затем-обновление» для приложений CRUD в системах управления реляционными базами данных сначала читается строка вместе с состоянием номера её версии; в отдельной транзакции выполняется оператор SQL UPDATE вместе с дополнительным предложением WHERE, которое включает номер версии, найденный при первоначальном чтении. Если никакая запись не была обновлена, это обычно означает, что номера версий не совпадают, потому что какое-то другое действие / транзакция уже обновило строку и, следовательно, её номер версии. Несколько инструментов реляционного сопоставления объектов используют этот метод для обнаружения сценариев оптимистической блокировки (включая Hibernate).

Индикаторы состояния в строках

Этот метод может дополнять временные метки и управление версиями. Он может настроить альтернативу, если, например, в строке таблицы установлен столбец состояния, указывающий, что строка изменилась (например, логический столбец, который, если задано значение true, указывает, что строка изменилась). В противном случае он может выступать в качестве дополнения к предыдущим методам, указывая на то, что строка, несмотря на наличие нового номера версии или более поздней даты, по-прежнему не должна обновляться в целевой системе (например, данные могут требовать проверки человеком).

Время / Версия / Статус в строках

Этот подход объединяет три ранее приведённых метода. Как уже отмечалось, нередко можно увидеть несколько решений CDC, работающих в одной системе, однако сочетание времени, версии и состояния обеспечивает особенно мощный механизм. Эти три элемента не являются лишними или избыточными. Их совместное использование позволяет использовать такую логику, как «Захват всех данных для версии 2.1, которые изменились в период с 01.06.2005 с 12:00 до 01.07.2005 в 12:00, когда код состояния указывает, что они готовы».

Триггеры на таблицах

Могут включать шаблон публикации / подписки для передачи изменённых данных в несколько целевых систем. При таком подходе события журнала, которые происходят с транзакционной таблицей, записываются в другую таблицу очередей, которые впоследствии могут быть воспроизведены. Например, представьте таблицу «Счета», с которой выполняются транзакции, запускаются триггеры, которые затем сохраняют историю события или изменения в отдельной таблице очереди. Таблица очередей может иметь следующие поля: Id, TableName, RowId, TimeStamp, Operation. Данные, вставленные в таблицу «Счета», могут быть следующими: <1, Аккаунты, 76, 02.11.2008 12:15, Обновление>. Более сложные проекты могут регистрировать фактические данные, которые изменились. Затем эту таблицу очередей можно «воспроизвести», чтобы реплицировать данные из исходной системы в целевую.

Примером этого метода является шаблон, известный как триггер журнала .

Обработка событий

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

Сканеры логов

Большинство систем управления базами данных управляют журналом транзакций, в котором записываются изменения, внесённые в содержимое базы данных и в метаданные . Сканируя и обрабатывая содержимое журнала транзакций базы данных, можно фиксировать изменения, внесённые в базу данных.

Использование журналов транзакций для сбора данных об изменениях сопряжено с трудностями, заключающимися в том, что структура, содержание и использование журнала транзакций являются специфическими для системы управления базами данных. В отличие от доступа к данным, не существует стандарта для журналов транзакций. Большинство систем управления базами данных не документируют внутренний формат своих журналов транзакций, хотя некоторые предоставляют программные интерфейсы для своих журналов транзакций (например: Oracle, DB2, SQL/MP, SQL/MX и SQL Server 2008).

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

Координацию чтения журналов транзакций и архивирования файлов журналов (программное обеспечение для управления базами данных обычно архивирует файлы журналов в автономном режиме на регулярной основе).
Трансляцию между физическими форматами хранения, которые записаны в журналах транзакций, и логическими форматами, обычно ожидаемыми пользователями базы данных (например, некоторые журналы транзакций сохраняют только минимальные различия в буфере, которые непосредственно не полезны для потребителей изменений).
Работу с изменениями формата журналов транзакций между версиями системы управления базами данных.
Устранение незафиксированных изменений, которые база данных записала в журнал транзакций, а затем откатила.
Работу с изменениями метаданных таблиц в базе данных.

Решения CDC, основанные на файлах журналов транзакций, имеют определённые преимущества, которые включают:

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

Смешанные факторы

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

Неподходящие исходные системы

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

Отслеживание захвата

На самом деле отслеживание изменений зависит от источника данных. Если данные сохраняются в современной базе данных, то захват изменений данных — это просто вопрос разрешений. Обычно используются две техники:

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

Если данные не находятся в современной базе данных, то CDC становится проблемой программирования.

Push против pull

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

Альтернативы

Пример модели медленно меняющегося измерения (SDC)

Иногда в качестве метода используется медленно меняющееся измерение .^[1]

См. также

Примечания

↑ Eroe, Erit. 4ggg. — Rty, 2015.

Ссылки

[1] Eroe, Erit. 4ggg. — Rty, 2015.

[1]