Стратегии near real-time CDC

В заметке дан краткий обзор стратегий переноса горячих изменений (CDC) с помощью запросов к БД.

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

Этот вид стратегий допускает длинные транзакции в источнике, но не допускает параллельные операции с данными.

Стратегию рекомендуется выбирать, если в источник производится только добавление строк.

Это, пожалуй, самая простая стратегия, суть которой заключается в отслеживании фактического значения суррогатного ключа.

К простоте прилагаются ограничения:
• Данные должны содержать целочисленный суррогатный ключ.
• Значения ключа должны возрастать монотонно.
• Параллельные операции INSERT в таблице недопустимы.
• Операции UPDATE и DELETE недопустимы.

Рекомендуется:
• Индексировать ключ.
• Ограничивать размер выборки.

Запрос к источнику содержит:
• Сортировку ключа по возрастанию.
• Условие выборки.

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

Производится отслеживание значений меток времени (и ключа, если есть), проставляемых системой для целей CDC.

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

Рекомендуется:
• Иметь в данных ключ.
» Без ключа можно нарваться на большой блок изменений с одинаковой временной меткой, что может стать проблемой.
• Индексировать метки и ключ.
• Ограничивать размер выборки.
• Генерировать значения меток в БД (default-функцией или функцией, указанной в DML операторе).

Запрос к источнику может быть довольно сложным, если меток несколько, а ключ составной. Запрос содержит:
• Сортировку по возрастанию метки и ключа (если есть).
• Условие выборки.

Этот вид стратегий допускает параллельные операции с данными в источнике, но не допускает длинные транзакции.

Выбирайте эту стратегию, если требуется получать самые свежие изменения из источника по метке времени.

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

Если окно выборки данных находится рядом с текущим временем (в штатной ситуации это так, но окно может быть далеко, если образовался технический долг), то в следующей итерации часть данных будет прочитана повторно. Это объясняется тем, что некоторые транзакции могут быть ещё не завершены и вы не увидите изменений, хотя у таких записей уже есть метка времени.
• Определите максимально возможную продолжительность транзакции (МПТ).
• Нижняя граница запроса не может быть больше, чем текущее время минус МПТ.
• Текущее время определяется запросом к БД-источника.

Недостатки:
• Повторное чтение данных порождает издержки – нагрузка на источник, получателя, сеть.
» Если в перекрывающийся интервал войдет большой блок изменений, то издержки удвоятся.
• Если какая-либо транзакция выйдет за МПТ, то произойдёт потеря изменений.

Ограничения:
• Данные должны содержать одно или несколько полей с метками времени операции над строкой.

Рекомендуется:
• Индексировать метки.
• Генерировать значения меток в БД (default-функцией или функцией, указанной в DML операторе).

Запрос к источнику содержит:
• Условие выборки.

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

Недостатки:
• Поставка изменений отстает на интервал МПТ.
» Т.е. фаза переноса данных происходит быстрее, чем при агрессивной выборке, но уровень актуализации ниже, так как изменения за интервал МПТ не переносятся.
• Если какая-то строка с изменениями вдруг ещё раз обновится в зоне МПТ (т.е. метка времени получит значение больше, чем верхняя граница), то она ускользнет из запроса. Если строка будет обновляться постоянно и часто, то она будет ускользать вечно (эффект может наблюдаться, например, в витринах данных). В учетных таблицах эффект постоянного выскальзывания маловероятен, но разовое выскальзывание может случаться часто.
• Если какая-либо транзакция выйдет за МПТ, то произойдёт потеря изменений.

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

Оперативность поставки данных определяется, в том числе, длительностью фазы переноса данных. Для максимального ускорения рекомендуется распараллелить процесс загрузки, для этого нужно открыть несколько соединений с БД. В идеале нужно иметь для каждой таблицы свое соединение, но так как у БД ограниченное количество ядер, то некоторые запросы встанут в очередь. Минимизация общего времени переноса данных достигается управлением очередью. Для этого нужно иметь статистику времени выполнения процессов загрузки по каждой таблице, первыми в очередь должны заходить самые тяжелые процессы.

Про сохранение консистентности данных можно почитать тут.

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