Захват изменений данных
Автор: Потапов Евгений Николаевич
Дата публикации: 16 Июня 2011
CDC (changed data capture)
Хранилище данных хранит всю историю изменения данных, поэтому требуется на вход подавать только изменившиеся данные с момента последнего обновления данных в ХД.
ЦЕЛЬ:
- Обеспечить гарантированное вычленение изменившихся данных
- Обеспечить определение типа изменения (вставки, удаления, обновления)
- Обеспечить пакетную загрузку изменений в ХД
ОТВЕТ:
Существует несколько способов для обнаружения изменений:
1. Анализ колонки аудита или временной метке
В таблицу системы источника добавляется столбец содержащий дату и время вставки или последнего обновления. Значение колонки обычно заполняется с помощью триггеров, запускающихся автоматически при вставке или изменении записи. В некоторых случая в место времени можно использовать монотонно растущий цифровой код аудита.
Минусы:
- повышение нагрузки на СУБД системы источники и снижение скорости модификации данных из-за работы триггера;
- в случае, если эти колонки заполняются не триггером, то гарантировать достоверность обнаружения изменения невозможно;
- невозможно определить факт удаление;
- проблемы с изменением времени на сервере источнике или несинхронности со временем ХД (для временной метки);
- хранение цифровых кодов аудита последнего изъятия для каждой таблицы (для цифровых меток).
2. Анализ таблиц с журналами изменений
Для каждой отслеживаемой таблицы создаем журнальную таблицу, хранящую все строку после модификации, время модификации и тип модификации. Заполнение таблицы выполняется через триггер на вставку, удаление и обновление отслеживаемой таблицы.
Минусы:
- повышение нагрузки на СУБД системы источники и снижение скорости модификации данных из-за работы триггера;
- необходимо уметь агрегировать изменения по одной строке. Так как журнал выдает все изменения, то в течение часа может произойти вставка строки, обновление и последующее удаление;
- необходимость периодической очистки журналов;
- проблемы с изменением времени на сервере источнике или несинхронности со временем ХД;
3. Анализ журнальных файлов
Способ заключается в периодическом копировании журналов повторного выполнения (redo log) базы данных и разборе этих журналов с целью выделить транзакции, влияющие на интересующие вас таблицы.
Минусы:
- журналы поддерживается не всеми СУБД;
- необходимо уметь агрегировать изменения по одной строке;
- потеря информации об изменениях в случае выполнении административных работ.
Нередко журнальные файлы переполняются, что блокирует дальнейшие транзакции. Когда такое случается в промышленной транзакционной системе, реакцией ответственного администратора БД является очистка журналов. Если вы перебрали все варианты, и анализ журналов оказался единственным подходящим, то следует убедить администратора БД создать для вас специальный журнал транзакций.
4. Полное сравнение
При полном сравнении сохраняется полный снимок таблицы на вчерашний день, и сравнивается по каждой записи с сегодняшней версией для поиска каждого изменения. Дает гарантированное обнаружение изменений.
Минусы:
- затраты дисковой подсистемы;
- затраты на сравнение;
- реализация алгоритма расчета контрольных сумм.