Миграция схемы
В разработке программного обеспечения ( миграция схемы также миграция базы данных , управление изменениями базы данных ) относится к управлению управляемыми версиями , инкрементальными и иногда обратимыми изменениями в реляционных схемах баз данных . Миграция схемы выполняется в базе данных всякий раз, когда необходимо обновить или вернуть схему этой базы данных к более новой или более старой версии.
Миграция выполняется программно с помощью инструмента миграции схемы . При вызове с указанной желаемой версией схемы инструмент автоматизирует последовательное применение или отмену соответствующей последовательности изменений схемы до тех пор, пока она не будет приведена в желаемое состояние.
Большинство инструментов миграции схем направлены на минимизацию влияния изменений схемы на любые существующие данные в базе данных. Несмотря на это, сохранение данных в целом не гарантируется, поскольку изменения схемы, такие как удаление столбца базы данных, могут уничтожить данные (т. е. все значения, хранящиеся в этом столбце для всех строк в этой таблице, будут удалены). Вместо этого инструменты помогают сохранить значение данных или реорганизовать существующие данные для удовлетворения новых требований. Поскольку смысл данных часто не может быть закодирован, настройка инструментов обычно требует ручного вмешательства.
Риски и преимущества
[ редактировать ]Миграция схемы позволяет исправлять ошибки и адаптировать данные по мере изменения требований. Они являются важной частью эволюции программного обеспечения, особенно в гибких средах (см. ниже).
Применение миграции схемы к рабочей базе данных всегда сопряжено с риском. Базы данных разработки и тестирования, как правило, меньше по размеру и чище. Данные в них лучше понимаются или, если все остальное не помогает, объем данных достаточно мал, чтобы его мог обработать человек. Производственные базы данных обычно огромны, старые и полны сюрпризов. Сюрпризы могут исходить из многих источников:
- Поврежденные данные, записанные старыми версиями программного обеспечения и не очищенные должным образом.
- Подразумеваемые зависимости в данных, о которых больше никто не знает
- Люди напрямую меняют базу данных, не используя назначенные инструменты.
- Ошибки в инструментах миграции схемы
- Ошибки в предположениях о том, как следует переносить данные
По этим причинам процесс миграции требует высокого уровня дисциплины, тщательного тестирования и продуманной стратегии резервного копирования.
Стратегии миграции
[ редактировать ]В устойчивом состоянии одна версия приложения понимает только одну версию схемы. Поэтому самая базовая стратегия — закрыть приложение, выполнить миграцию схемы, а затем запустить новую версию приложения. Несмотря на свою простоту, эта стратегия приводит к простоям . В зависимости от критичности системы и особенностей ее использования можно допускать простои различной продолжительности, но в некоторых случаях их вообще нельзя допускать. В таких случаях можно использовать одну из следующих стратегий нулевого простоя.
Двойное письмо [1]
[ редактировать ]Вот общие этапы двойного чтения (также называемого двойным чтением):
- Подготовьте схему так, чтобы она могла хранить данные как в старом, так и в новом форматах. Это может означать добавление новой версии столбца или таблицы, не затрагивая существующие данные.
- Разверните новую версию приложения, которая записывает данные как в старом, так и в новом форматах (отсюда и название «двойная запись»). Важно обеспечить согласованность этих записей. После этого момента все вновь записанные данные будут существовать как в старом, так и в новом формате.
- Выполните обратную засыпку в базе данных: скопируйте данные из старого формата в новый формат, который существовал ранее и не обновлялся в последнее время, поэтому он еще не записан дважды. После этого в базе данных появится полная копия данных как в старом, так и в новом формате.
- Разверните новую версию приложения, которая переключается на чтение данных в новом формате и прекращает двойную запись. В распределенных системах важно переключить путь чтения перед остановкой двойной записи, поэтому этот шаг можно разделить на два.
- Удалите данные старого формата из схемы.
Двойное чтение [2]
[ редактировать ]Двойное чтение (также называемое двойным чтением) похоже на двойное письмо и состоит из следующих шагов:
- Подготовьте схему так, чтобы она могла хранить данные как в старом, так и в новом форматах. То же, что и выше.
- Разверните новую версию приложения, которая пытается читать как старый, так и новый форматы (отсюда и название «двойное чтение») и работает с любым существующим форматом.
- Разверните другую версию приложения, которая прекращает запись старого формата и вместо этого начинает писать новый формат. Все должно продолжать работать нормально, поскольку двойное чтение распознает, что ему необходимо читать новый формат для вновь записанных строк.
- Выполнить обратную засыпку в базе данных: все данные, записанные в старом формате, перенести в новый формат.
- Еще раз разверните изменение приложения, которое перестанет читать старые данные.
- Удалите данные старого формата из схемы.
Двойное чтение и письмо.
[ редактировать ]В этом комбинированном подходе приложение заменяется как на двойное чтение, так и на двойную запись. Поскольку обе отдельные стратегии гарантируют, что база данных может оставаться в сети без перебоев, комбинированный подход также дает тот же результат. Эта стратегия обеспечивает более детальный контроль над обратной засыпкой, которую можно разделить на более мелкие пакеты, а флаги функций можно использовать для более свободного и отдельного переключения путей чтения и записи. Это также может быть полезно, когда невозможно гарантировать выполнение только обычной двойной записи в согласованных транзакциях.
Сравнение
[ редактировать ]- Все описанные выше стратегии обеспечивают миграцию с нулевым временем простоя.
- Двойная запись имеет то преимущество, что старая и новая версии данных живут рядом, поэтому между ними можно провести сравнение, чтобы обеспечить согласованность перед переходом на новый формат. Но это происходит за счет удвоения требований к хранению.
- При двойном чтении в любой момент времени существует только одна версия каждого фрагмента данных, поэтому требования к хранению не увеличиваются.
- Комбинированный подход позволяет выполнять обратную засыпку меньшими партиями, что позволяет контролировать увеличение объема хранилища, но это достигается за счет дополнительной сложности.
Миграция схемы при гибкой разработке программного обеспечения
[ редактировать ]При разработке программных приложений, поддерживаемых базой данных, разработчики приложения обычно разрабатывают исходный код вместе с развивающейся схемой базы данных. Код обычно имеет жесткие ожидания относительно того, какие столбцы, таблицы и ограничения присутствуют в схеме базы данных, когда ему необходимо взаимодействовать с одной из них, поэтому только версия схемы базы данных, для которой был разработан код, считается полностью совместимой с этой версией исходного кода. .
При тестировании программного обеспечения , хотя разработчики могут имитировать наличие совместимой системы баз данных для модульного тестирования , на любом уровне тестирования выше этого (например, интеграционное тестирование или тестирование системы ) разработчики обычно тестируют свое приложение на локальной или удаленной тестовой базе данных. схематически совместим с тестируемой версией исходного кода. В продвинутых приложениях сама миграция может подвергаться тестированию миграции .
Благодаря технологии миграции схем модели данных больше не нужно полностью проектировать заранее, и их легче адаптировать к меняющимся требованиям проекта на протяжении всего жизненного цикла разработки программного обеспечения .
Связь с системами контроля версий
[ редактировать ]Команды разработчиков программного обеспечения обычно используют системы контроля версий для управления и совместной работы над изменениями, вносимыми в версии исходного кода. Разные разработчики могут разрабатывать разные, относительно старые или новые ветки одного и того же исходного кода, чтобы вносить изменения и дополнения во время разработки.
Если предположить, что разрабатываемое программное обеспечение взаимодействует с базой данных, каждая версия исходного кода может быть связана по крайней мере с одной схемой базы данных, с которой она совместима.
При хорошей практике тестирования программного обеспечения миграцию схем можно выполнять в тестовых базах данных, чтобы гарантировать совместимость их схемы с исходным кодом. Чтобы упростить этот процесс, инструмент миграции схемы обычно вызывается как часть автоматизированной сборки программного обеспечения в качестве предварительного условия этапа автоматического тестирования .
Можно сказать, что инструменты миграции схем решают проблемы управления версиями для схем баз данных точно так же, как системы контроля версий решают проблемы управления версиями исходного кода. На практике многие инструменты миграции схемы фактически полагаются на текстовое представление изменений схемы (например, файлы, содержащие операторы SQL), так что история версий изменений схемы может эффективно храниться вместе с исходным кодом программы в VCS. Такой подход гарантирует, что информация, необходимая для восстановления совместимой схемы базы данных для конкретной ветки кода, может быть восстановлена из самого дерева исходного кода. Еще одним преимуществом этого подхода является обработка одновременных конфликтующих изменений схемы; разработчики могут просто использовать свои обычные текстовые инструменты разрешения конфликтов для устранения разногласий.
Связь с эволюцией схемы
[ редактировать ]Инструментарий миграции схемы можно рассматривать как средство отслеживания истории развития схемы (т. е. эволюции схемы ).
Преимущества
[ редактировать ]Разработчикам больше не нужно удалять всю тестовую базу данных, чтобы создать новую тестовую базу данных с нуля (например, с помощью сценариев создания схемы из инструментов генерации DDL). Кроме того, если создание тестовых данных требует много времени, разработчики могут избежать повторного создания тестовых данных для небольших, неразрушающих изменений в схеме.
Ссылки
[ редактировать ]- ^ «Безопасный шаблон миграции базы данных без простоев» . 15 декабря 2015 года . Проверено 24 мая 2024 г.
- ^ «Миграция хранилища данных без простоев» . Проверено 24 мая 2024 г.
Ссылки
[ редактировать ]| Основной | |
|---|---|
| Языки | |
| Безопасность | |
| Дизайн |
|
| Программирование | |
| Управление | |
| Списки | |
| См. также | |
