Введение

Набор шаблонов проектирования программного обеспечения в базе данных.

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

Методология

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

Временные метки на строках

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

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

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

Показатели состояния в строках

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

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

Этот подход объединяет три ранее рассмотренных метода. Как отмечалось, часто можно встретить несколько решений CDC, работающих в одной системе, однако сочетание времени, версии и статуса предоставляет особенно эффективный механизм, и программистам следует использовать их в совокупности, когда это возможно. Эти три элемента не дублируют и не являются излишними. Их совместное использование позволяет реализовать такую логику, как: "Извлечь все данные версии 2.1, которые были изменены в период с 00:00 1 июня 2005 года по 00:00 1 июля 2005 года, при условии, что код статуса указывает на готовность к производственному использованию".

Смешивающие факторы

Как часто бывает в сложных областях, окончательное решение проблемы обнаружения изменений (CDC) может потребовать учета множества противоречивых факторов.

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

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

Нажимать против тянуть

Push: исходный процесс создает снимок изменений внутри своего процесса и передает строки дальше по потоку. Последующий процесс использует этот снимок, создает свой собственный набор данных и передает его следующему процессу. Pull: целевой процесс, непосредственно следующий за исходным, формирует запрос данных у исходного процесса. Целевой процесс передает снимок следующему целевому процессу, как и в модели Push.

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

Иногда медленно изменяющаяся размерность используется как альтернативный метод. CDC и SCD схожи в том, что оба метода способны выявлять изменения в наборе данных. Наиболее распространенные формы SCD — тип 1 (перезапись), тип 2 (поддержание истории) или тип 3 (хранение только предыдущего и текущего значения). SCD 2 может быть полезен, если в целевой системе требуется сохранение истории изменений. CDC перезаписывает данные в целевой системе (аналогично SCD1) и оптимален, когда в целевую систему необходимо передавать только измененные данные, то есть набор данных, управляемый дельтами.