Компактный Enterprise Data Hub

Как сократить затраты на дисковое пространство в EDH конструктивным образом.

EDH часто создается для концентрации данных под оперативные задачи. В таких задачах требуется свежие данные за несколько последних дней/месяцев. Стало быть, хранить полные таблицы смысла нет – это очень накладно. Организовать TTL данных просто, если речь идет о потоковых данных, но заметно сложнее, если речь идет о транзакционных данных учетных систем. В учетной системе данные организованы в модель и находятся в консистентном состоянии. Удаление устаревших данных может привести к разрушению ссылочной целостности с соответствующими неприятными последствиями. В процессе добавления новых записей также можно получить на руки холостой внешний ключ.

Для решения проблемы нам понадобится:

Таблица с описанием отношений между сущностями нужна и для корректного удаления, и для восстановления записей.

Восстановление ссылочной целостности реализуется так …

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

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

Удаление записей реализуется так …

Найдите в таблице устаревшие записи, к которым не ведут внешние ключи, и удалите их.

Лайфхак » Процесс не нужно делать рекурсивным, если его запускать ежедневно.