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

В базах данных захват изменения данных (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]