Разработка базы данных для добавочного «экспорта» в хранилище данных

Question

Имеется реляционная база данных объемом 1 ТБ, которая в настоящее время находится в SQL Server. Хранилищу данных требуется «копия» основных частей базы данных. Данные хранилища не должны быть старше 24 часов. Размер реляционной базы данных делает нецелесообразным выполнять полную загрузку каждую ночь. Как мне спроектировать мою реляционную базу данных для поддержки дополнительной нагрузки на склад?

Очень небольшая часть (<0,1%) базы данных изменяется за один день, и это в основном вставки. Внутридневные изменения не требуются, только окончательный снимок. </p>

Главной задачей является поддержание производительности реляционной базы данных, после чего не нужно тратить лишнее пространство.

Answer 1

Это сложная область, обычно называемая «Извлечение, преобразование, загрузка» или ETL.Там нет правильного ответа, и ни одна из книг, которые я нашел, не была настолько убедительной - Ральф Кимбалл, кажется, пишет самые полезные.

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

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

Если производительность снижается, вам может потребоваться использовать зеркало вашей транзакционной базы данных для выполнения задач ETL - это совершенно новый уровень сложности.

Я бы прочиталСначала книги Кимбалла, и посмотрите, выглядят ли какие-либо идеи непосредственно применимыми.

Answer 2

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

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

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

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

Конечно, это не единственный способ сделать это. Но, надеюсь, он предоставит вам некоторый применимый контекст.

Answer 3

Нужно ли вам фиксировать изменения внутри дня или вам просто требуется снимок текущего состояния в конце каждого дня?

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