Малые изменения
- 1 year ago
- 0
- 0
В базах данных захват изменения данных ( 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 становится проблемой программирования.
Иногда в качестве метода используется медленно меняющееся измерение .