Для чего нужна миграция бд
Миграция баз данных: зачем и почему
Со временем в ИT-ландшафте большинства компаний, долго существующих на рынке, собирается большое количество разнотипных информационных систем (ИС) для автоматизации и поддержки бизнес-процессов, в том числе базы данных (БД). Эти системы «живут» в компаниях годами, а иногда и десятилетиями. Такое множество ИС ИТ-специалисты в шутку называют зоопарком. В какой-то момент его сопровождение становится очень дорогим, а технологические ограничения не позволяют развивать ИС в соответствии с новыми бизнес-требованиями. Тогда компании стремятся обезопасить устаревшие БД от внешних вторжений, утечек и минимизировать риск утраты ценных данных (коммерческой, конфиденциальной информации). Сделать это можно при помощи миграции БД.
Зачем компаниям мигрировать данные, как организовать процесс без потерь и почему это выгодно в долгосрочной перспективе? Рассказываю в статье.
Когда у компаний возник интерес к миграции БД и с чем это связано
Направление миграции БД было популярно за рубежом 15 лет назад. В России на него обратили внимание только в 2014 году, когда появилась необходимость импортозамещения систем, лицензируемых зарубежными производителями и подпадающих под санкции. Что и послужило драйвером роста количества заказов на миграцию и значительно увеличило спрос на полную или частичную замену БД. На тот момент именно импортозамещение оказалось главной целью миграции перехода от устаревших систем к новым. Затем стало ясно, что с помощью миграции БД можно изменить ИT-ландшафт компании – сократить затраты на сопровождение ИС и получить принципиально новые возможности, например, работу с BigData.
Зачем мигрировать
Выгоду постепенной миграции БД можно отследить только в долгосрочной перспективе. Рассматривая вариант ухода от старой системы посредством модернизации на имеющейся платформе, компания сталкивается с трудностями – это дорогостоящий и многоступенчатый процесс. В таком случае новая система будет получать нужные данные из старых БД, которые также будут работать. В итоге бизнесу приходится платить за обе платформы, когда требуется лишь одна. Возрастает стоимость оборудования, необходимого для функционирования всей совокупности ИT-систем, сопровождения. Вдобавок трудовых ресурсов потребуется больше, а специалистов по устаревшим системам мало. Получается, что экономически эффективнее мигрировать все данные, ценные для принятия решений и прогнозирования, на одну платформу.
Миграция БД не только гарантирует экономию средств, но и может стать триггером роста эффективности всего ИT-подразделения. Если правильно подойти к процессу перехода от устаревших систем к новым, он сможет стать началом цифровой трансформации в компании. Если осуществить миграцию в тщательно отработанную целевую архитектуру, можно получить принципиально новые функции, например возможность работы с большими данными. Вот еще несколько причин, почему миграция БД нужна бизнесу.
1. Миграция БД обеспечивает независимость от санкционной политики и помогает снизить затраты на лицензирование.
2. Переход на современные системы способствует снижению расходов на поддержку и сопровождение ИT-ландшафта.
3. Миграция обеспечивает переход на БД с открытым исходным кодом. Как правило, разработчиков для таких систем найти проще, чем специалистов по enterprise-решениям.
4. Миграция позволяет минимизировать затраты на серверное оборудование и построить кластеры на более доступных комплектующих.
5. В случае с приложениями, использующими базы данных, миграция необходима для того, чтобы обновлять функционал, добавлять новые возможности и устранять проблемы масштабирования запросов по мере роста числа пользователей.
6. Миграция БД позволяет поднять на новый качественный уровень процессы, обеспечивающие надежность и сохранность данных, ввести регламенты резервирования и хранения копий. В длительной перспективе это значительно сэкономит ресурсы компании на обслуживание ИT-инфраструктуры.
Говоря о стоимости миграции для бизнеса, следует заметить, что она заметно варьируется для различных систем и может составлять от десятков миллионов рублей для средних компаний до сотен миллионов – для крупных.
Ценообразование процесса зависит от следующих факторов:
от количества хранимого кода, выполняющегося на стороне БД;
от объемов БД и имеющегося временного технологического окна для переключения с одной системы на другую;
от семантических различий в языках программирования исходной и целевой БД.
Стоимость процесса возрастает, когда нет возможности заморозить развитие исходной БД на время подготовки к миграции. Кроме того, зачастую процесс перехода с одной системы на другую сопряжен с архитектурными усовершенствованиями исходной БД, что также привносит дополнительные траты.
Сегодня цель миграции БД – в сокращении издержек на обслуживание ИT-инфраструктуры в долгосрочной перспективе. Более того, последние несколько лет заметен активный интерес к миграции не только БД, но и серверов приложений на российское ПО, что отвечает стратегии импортозамещения, и ПО с открытым кодом.
Процесс миграции БД: с чем вы столкнетесь
Миграция должна быть четко организованной и непрерывной, независимо от способа переноса информации. Без грамотной структуры и продуманного плана компании придется выйти за рамки запланированного бюджета и столкнуться с тем, что целевая система будет работать не так, как планировалось. Во время миграции БД может возникнуть несколько проблем.
1. Информация может потеряться. Потеря и дублирование данных о структуре БД и ее привязки к бизнес-процессам может стать причиной ошибок при дальнейшей модификации системы. Поэтому при миграции нужно не менять одно средство управления базами данных на другое, а мигрировать с «вычищением» данных – обеспечить их согласованность, целостность и исключить дублирование. Если выполнить эти условия полностью не удастся, то нужно убедиться, что персонал, выполняющий миграцию, знал об этом дублировании и его причинах.
2. Бизнес-логика может быть скопирована с ошибками. Необходимо перемещать не только данные, но и бизнес-логику, реализованную в хранимых процедурах средств управления БД. Но здесь следует быть аккуратнее: бизнес-логика в старой системе может быть написана на различных языках программирования и просто «копировать» ее в новую систему – значит привнести в нее все существующие ошибки и, возможно, добавить новые.
3. Недостаток квалифицированных кадров, способных понимать логику целевой и старой системы. Для выполнения миграции специалисту необходимо быть компетентным как в исходных средствах управления базами данных, так и в целевых. Это существенно экономит время и уменьшает вероятность ошибок. Но, как уже было сказано выше, таких специалистов мало.
В процессе миграции данные преобразуются и перемещаются из одной среды в другую. При этом информация, извлеченная из старой системы, должна «подготовиться» к переносу в целевое местоположение, чтобы команде удалось избежать ошибок, перечисленных выше. Процесс миграции не всегда проходит гладко.
Наиболее неудачный сценарий миграции БД – появление в ИT-ландшафте очередной недоработанной системы, которой нельзя будет пользоваться. Это «эффект второй системы», описанный экспертом в области теории вычислительных систем Фредериком Бруксом. Такой эффект увеличит сложность сопровождения ИС и создаст дополнительную финансовую нагрузку на компанию. Например, в подобной БД будут присутствовать ошибки на уровне данных, которых можно избежать при корректном составлении сценариев или на стадии разработки стратегии миграции. Из возможных технологических ошибок надо отметить неправильный выбор целевой архитектуры, а именно наследование неудачных решений исходной системы.
Более мягкий сценарий неудачной миграции – необходимость обращения к старой системе при наличии новой. Его суть в том, что новая СУБД станет выполнять бизнес-функции, но устаревшую нельзя будет полностью вывести из эксплуатации, поскольку в ней заложены архивные данные для исполнения некоторых бизнес-процессов. И хотя такой тип миграции исключает риск простоев, он довольно сложный – работать нужно будет буквально на два фронта. К тому же компании придется не только выделить бюджет на новую систему, но и платить за обслуживание старой.
Самый оптимальный вариант миграции – комбинированный, плавный. Его суть в том, что в целевой системе готовится платформа со всем необходимым функционалом и данные переносятся постепенно. В новой системе сначала реализуются бизнес-процессы, требующие вовлечения старых систем, затем новая СУБД постепенно принимает на себя функционал не в исходном виде, а с новыми возможностями. Такой вариант миграции предполагает, что у команды есть стратегия переноса данных. В ней должны быть прописаны следующие условия, критические для корректной миграции.
Стратегия должна быть четко прописана, а процесс миграции – взят под контроль специально выделенной рабочей группой.
Участники команды по миграции должны быть в полной мере знакомы с работой исходной и целевой систем. При осуществлении миграции важно заложить основу для будущего развития и не допустить повторения ошибок. Поэтому группы миграции желательно отделить от команд разработки и эксплуатации, но тесное взаимодействие, безусловно, необходимо сохранить. В силу того что в процессе миграции используются различные методики автоматизации, от участников команды требуется высокий уровень узкоспециальных знаний. Это решающее условие для назначения специальной группы, которая будет вести подобные проекты и при необходимости подключать дополнительных специалистов на каждый проект.
Перед переносом исходные данные должны пройти комплексный аудит. Вы должны знать, что вы переносите и как это вписывается в целевую систему. Игнорирование этого этапа может привести к критической ошибке в data mapping (сопоставлении полей в источнике миграции и целевой системе).
Если в исходных данных есть ошибки, их необходимо исправить перед переносом в новую СУБД.
Данные следует защищать и обслуживать. Базы данных – один из самых уязвимых объектов для кибератак. Однако сегодня на рынке существуют различные инструменты, позволяющие сделать перенос данных безопасным, например, системы обнаружения вторжений, средства анализа защищенности данных и сетевые экраны.
Состояние БД и отчетность по ним необходимо отслеживать. Процессы и инструменты контроля должны быть удобными и, где это возможно, автоматизированными.
Необходимо сделать резервную копию данных перед стартом. Такая «подушка безопасности» позволит не потерять нужную информацию в непредвиденных ситуациях, если процесс миграции пойдет не по плану.
Успех миграции во многом зависит от правильно выбранной методологии тестирования, поэтому уделите этому процессу особое внимание.
Не забывайте о валидации процесса. Корректно выстроенная процедура сверки данных поможет оценить состояние целевой системы после миграции. Валидация процедуры перегрузки данных позволяет удостовериться, что все данные исходной БД в полном объеме мигрировали, претерпев необходимые документированные трансформации. Она должна затрагивать не только содержимое объектов, но и всю схему данных в целом. Процесс верификации должен проводиться на предмет наличия объектов, их состояния и соответствия типов в целевой БД. Полная валидация – установление факта идентичности исходной и целевой БД с учетом изменений – требует больших затрат и выполнения полного чтения обеих баз. Но как метод тестирования процедуры перегрузки данных она не ограничивается технологическим окном, выделенным на промышленную перегрузку, и может выполняться только на предварительных прогонах.
И, наконец, придерживайтесь намеченной стратегии.
Подходы к миграции БД: какой выбрать
Мигрировать данные из исходной системы в целевую можно несколькими способами – с помощью автоматизации или вручную. Применение той или иной методики зависит от вводных условий и состояния исходной системы. На следующих примерах объясняю суть каждого из подходов.
1. При автоматизированном подходе вмешательство человека в структуру БД минимизируется. Технической группе, занимающейся миграцией БД, нужно создать комбинацию методик и инструментов, которые позволят наладить непротиворечивое и повторяемое управление изменениями в структуре БД и в самих данных. Это гибкий способ миграции, поскольку любой участник команды сможет внести изменения в БД как в общий сервер, так и на локальную версию в различных программных средах без обработки данных вручную.
Несколько лет назад мы мигрировали базу данных для крупного российского банка с платформы Microsoft SQL Server 2008 на Oracle 11g. Заказчик хотел централизовать ИС различных территориальных подразделений в единую систему, выбрал одну из целевых архитектур и решил перенести туда все существующие решения. Основной сложностью было то, что система не могла простаивать более 72 часов и дорабатывалась в процессе миграции.
Подобные требования к проекту наложили очень серьезные ограничения на подход к решению. Мигрировать с применением ручных техник было невозможно из-за жестких требований по времени самой миграции. Поэтому мы разработали систему, которая автоматизировала перевод системы заказчика (включая перевод всех данных, хранимого кода, проведения тестирования и анализа производительности) на новую платформу. Мы проводили большое число тестовых миграций как отдельных модулей, так и всей системы, тестирование и доработку системы миграции, что позволило выполнить всю процедуру без сбоев и в требуемое время. Также техническая группа по миграции разработала методику тестирования, основанную на записи и воспроизведении взаимодействия БД с внешними приложениями и связанными системами.
2. Ручной подход предполагает, что команда разработки вносит изменения в структуру целевой БД и переносит данные вручную. Мы осуществляли миграцию медицинской системы с устаревшей версии СУБД на новую от другого поставщика. В этом случае исходная система уже не модифицировалась, и перед нами стояла сложная задача по восстановлению информации о ней. Так как документации не осталось, а разработчики системы были недоступны для консультаций, мы применили ручной подход и начали миграцию с разбора функциональности существующего решения и проведения соответствия с бизнес-требованиями к процессам.
В результате удалось мигрировать данные и встроить систему в новые бизнес-процессы, при этом объем кода уменьшился более чем в два раза. Кроме того, получилось исключить уже не используемые модули и функциональные возможности.
Миграция БД – комплексный и важный для компании процесс. Необходимость сохранения целостности данных требует, чтобы он выполнялся правильно, а техническая группа осознавала целеполагание и следовала четко проработанной стратегии.
Проводя миграцию БД, компания уменьшает расходы на сопровождение не актуальных систем в частности и ИT-инфраструктуры в целом, оптимизирует ИС, перемещая все данные в одно место, и создает дополнительный барьер от атак злоумышленников. В эпоху big data необходимо использовать инновационные и эффективные методы хранения информации, особенно если речь идет о сложной ветвящейся СУБД. Миграция БД – это серьезный шаг, который позволит компании перейти не только на новую технологию, но и выйти на новый уровень ИТ-инфраструктуры.
Миграция данных: процесс, типы и золотые правила
Оглавление
В нашей повседневной жизни перемещение информации из одного места в другое – не более чем простая операция копирования и вставки. Когда дело доходит до переноса миллионов единиц данных в новую систему, все становится намного сложнее.
Однако многие компании рассматривают даже массовую миграцию данных как низкоуровневую задачу, выполняемую в два клика. Такая первоначальная недооценка приводит к дополнительным расходам времени и денег. Недавние исследования показали, что 55 процентов проектов миграции данных превышали бюджет, а 62 процента оказались сложнее, чем ожидалось, или фактически потерпели неудачу.
Как не попасть в ту же ловушку? Ответ заключается в понимании сути процесса миграции данных, от его триггеров до заключительных этапов.
Если вы уже знакомы с теоретическими аспектами проблемы, вы можете перейти к разделу Процесс миграции данных, где мы даем практические рекомендации. В противном случае, давайте начнем с самого простого вопроса: что такое миграция данных?
Что такое миграция данных?
Миграция данных против интеграции данных
В отличие от миграции, связанной с внутренней информацией компании, интеграция заключается в объединении данных из нескольких источников вне и внутри компании в единое представление. Это важный элемент стратегии управления данными, который обеспечивает связь между системами и дает доступ к контенту по широкому кругу вопросов. Консолидированные наборы данных – необходимое условие для точного анализа, извлечения бизнес-информации и отчетности.
Миграция данных – это односторонний путь, который заканчивается после того, как вся информация будет доставлена в целевое место. Интеграция, напротив, может быть непрерывным процессом, который включает потоковую передачу данных в реальном времени и обмен информацией между системами.
Миграция данных против репликации данных
При миграции данных после того, как данные полностью перенесены в новое место, вы в конечном итоге отказываетесь от старой системы или базы данных. При репликации вы периодически переносите данные в целевое расположение, не удаляя и не отбрасывая их источник. Итак, у него есть отправная точка, но нет определенного времени завершения.
Репликация данных может быть частью процесса интеграции данных. Также это может превратиться в миграцию данных – при условии, что исходное хранилище выведено из эксплуатации.
Теперь мы обсудим только миграцию данных – разовый и односторонний процесс переезда в новый дом, оставляя старый пустым.
Основные типы миграции данных
Миграция хранилища
Миграция системы хранения происходит, когда бизнес приобретает современные технологии, отказываясь от устаревшего оборудования. Это влечет за собой перенос данных с одного физического носителя на другой или с физического на виртуальную среду.
Примеры таких миграций: перенос данных
Перенос базы данных
Перенос приложений
Миграция центра обработки данных
Миграция бизнес-процессов
Миграция в облако
Миграция в облако – популярный термин, охватывающий все вышеупомянутые случаи, если они связаны с перемещением данных из локальной среды в облако или между различными облачными средами. Gartner ожидает, что к 2024 году облако привлечет более 45 процентов ИТ-расходов и будет доминировать над постоянно растущим числом ИТ-решений.
В зависимости от объемов данных и различий между исходным и целевым местоположениями миграция может занять от 30 минут до месяцев и даже лет. Сложность проекта и стоимость простоя определяют, как именно развернуть процесс.
Подходы к миграции данных
Миграция данных большого взрыва
Преимущества: менее затратный, менее сложный, занимает меньше времени, все изменения происходят один раз
Недостатки: высокий риск дорогостоящего отказа, требует простоя.
В сценарии большого взрыва вы перемещаете все активы данных из исходной среды в целевую за одну операцию в относительно короткий промежуток времени.
Системы не работают и недоступны для пользователей, пока данные перемещаются и претерпевают преобразования для соответствия требованиям целевой инфраструктуры. Перенос обычно выполняется во время официальных праздников или выходных, когда клиенты предположительно не используют приложение.
Подход «большого взрыва» позволяет выполнить миграцию в кратчайшие сроки и избавляет от хлопот одновременной работы в старой и новой системах. Однако в эпоху больших данных даже компании среднего размера накапливают огромные объемы информации, в то время как пропускная способность сетей и шлюзов API не бесконечна. Это ограничение необходимо учитывать с самого начала.
Вердикт. Подход большого взрыва подходит для небольших компаний или предприятий, работающих с небольшими объемами данных. Это не работает для критически важных приложений, которые должны быть доступны 24/7.
Тонкая миграция данных
Преимущества: меньшая подверженность неожиданным сбоям, нулевое время простоя
Недостатки: дороже, требует больше времени, требует дополнительных усилий и ресурсов для поддержания работы двух систем.
Этот подход, также известный как поэтапная или итеративная миграция, привносит опыт гибкой разработки в перенос данных. Он разбивает весь процесс на подмиграции, каждая со своими целями, сроками, масштабом и проверками качества.
Капельная миграция предполагает параллельную работу старой и новой систем и передачу данных небольшими приращениями. В результате вы получаете преимущество нулевого времени простоя, а ваши клиенты довольны доступностью приложений 24/7.
С другой стороны, итеративная стратегия занимает гораздо больше времени и усложняет проект. Ваша группа миграции должна отслеживать, какие данные уже были перенесены, и гарантировать, что пользователи могут переключаться между двумя системами для доступа к необходимой информации.
Еще один способ выполнить постепенную миграцию – оставить старое приложение полностью работоспособным до конца миграции. В результате ваши клиенты будут использовать старую систему как обычно и переключатся на новое приложение только после того, как все данные будут успешно загружены в целевую среду.
Однако этот сценарий не облегчает жизнь вашим инженерам. Они должны обеспечить синхронизацию данных в режиме реального времени на двух платформах после их создания или изменения. Другими словами, любые изменения в исходной системе должны запускать обновления в целевой системе.
Вердикт. Капельная миграция – правильный выбор для средних и крупных предприятий, которые не могут себе позволить длительные простои, но обладают достаточным опытом для решения технологических проблем.
Версионная миграция структуры базы данных: основные подходы
Проблемы контроля версий баз данных и миграций между версиями уже не раз поднимались как на Хабре (1, 2, 3 и др.), так и в Интернете (преимущественно, англоязычном).
В первом разделе этой статьи я рассматриваю основные проблемы, которые возникают в командах программистов при внесении любых изменений в структуру базы данных. Во втором разделе я попытался выделить основные общие подходы к тому, в каком виде изменения структуры базы данных можно хранить и поддерживать в процессе разработки.
Терминология
База данных — совокупность всех объектов БД (таблиц, процедур, триггеров и т.д.), статических данных (неизменяемых данных, хранящихся в lookup-таблицах) и пользовательских данных (которые изменяются в процессе работы с приложением).
Структура базы данных — совокупность всех объектов БД и статических данных. Пользовательские данные в понятие структуры БД не входят.
Версия базы данных — определенное состояние структуры базы данных. Обычно у версии есть номер, связанный с номером версии приложения.
Миграция, в данном контексте, — обновление структуры базы данных от одной версии до другой (обычно более новой).
В этом смысле термин миграция, похоже, используется во многих источниках (особенно этому поспособствовали миграции из gem’а Active Record, входящего в состав Ruby on Rails). Однако при использовании этого термина возникает двусмысленность: человек, который не знает контекста, скорее подумает, что речь идет о переносе базы данных с одной СУБД на другую (MySQL => Oracle), а то и вовсе о миграции процессов/данных между нодами кластера. Поэтому предлагаю в случаях, когда контекст неочевиден, использовать более точный термин: версионная миграция баз данных.
Зачем это нужно?
Разработчики, которые уже сталкивались с проблемой рассинхронизации версий БД и приложения, могут пропустить этот раздел. Здесь я напомню, почему нужно соблюдать паритет версий приложения и базы данных и какая общая проблема при этом возникает.
Версия базы данных должна соответствовать версии приложения
Итак, представьте себе следующую ситуацию: команда из нескольких программистов разрабатывает приложение, которое активно использует базу данных. Время от времени приложение поставляется в продакшн — например, это веб-сайт, который деплоится на веб-сервер.
Любому программисту в процессе написания кода приложения может понадобиться изменить структуру базы данных, а также, сами данные, которые в ней хранятся. Приведу простой пример: допустим, есть необнуляемое (not nullable) строковое поле в одной из таблиц. В этом поле не всегда есть данные, и в этом случае там хранится пустая строка. В какой-то момент вы решили, что хранить пустые строки — семантически неправильно в некоторых случаях (см. 1, 2), а правильно — хранить NULL’ы. Для того, чтобы это реализовать, понадобятся следующие действия:
1. Изменить тип поля на nullable:
ALTER myTable CHANGE COLUMN myField myField VARCHAR (255) NULL DEFAULT NULL ;
UPDATE myTable SET myField = NULL WHERE myField = » ;
3. Изменить код приложения так, чтобы при получении из БД данных, хранящихся в этом поле, он адекватно реагировал на NULL’ы. Записывать в это поле тоже теперь нужно NULL’ы вместо пустых строк.
Из пункта 3 можно видеть, что приложение и база данных — неразрывные части одного целого. Это означает, что при поставке новой версии приложения в продакшн, нужно обязательно обновлять и версию базы данных, иначе приложение попросту не сможет правильно работать. В данном примере, если до новой версии будет обновлено только приложение, то в какой-то момент произойдет вставка NULL в необнуляемое поле, а это очевидная ошибка.
Таким образом, обновление версии приложения требует корректной версионной миграции базы данных.
Так ли это просто?
Осознав, что паритет версий БД и приложения необходим, вам нужно удостовериться, что миграции БД до нужной версии всегда будут выполняться правильно. Но в чём здесь проблема? Ведь, на первый взгляд, сложного здесь ничего нет!
Тут снова обратимся к живому примеру. Допустим, программисты в процессе разработки записывают свои изменения структуры и данных БД в отдельный файл в виде SQL-запросов (как DDL-, так и DML-запросов). А при каждом деплое последней версии приложения вы одновременно обновляете до последней версии и базу данных, выполняя запросы из того самого SQL-файла… Но погодите, с какой версии вы обновляете БД до последней версии? «С прошлой»? Но так ли хорошо вы помните, что конкретно из себя представляла прошлая версия (её выпустили 2 месяца назад)? Если нет, то как вы собрались её обновлять? Ведь без точной информации о состоянии структуры и данных выполнить корректную миграцию невозможно: если вы непредумышленно выполните запросы, которые уже когда-то выполнялись, это может привести к потере данных или нарушению их целостности.
Простой пример — замена паролей на их MD5-суммы. Если повторно выполнить такой запрос, то данные можно будет восстановить только из бэкапа. Да и вообще, любые UPDATE ‘ы, DELETE ‘ы, и даже INSERT ‘ы, выполненные повторно, могут привести к крайне нежелательным последствиям. Не говоря уже о несвоевременных TRUNCATE ‘ах и DROP ‘ах (хотя такие случаи намного менее вероятны).
Кстати говоря, с этой точки зрения, недовыполнить — не меньшая опасность для работоспособности приложения, чем перевыполнить.
Таким образом, можно сделать вывод, что в процессе версионной миграции все запросы должны выполняться только один раз и, к тому же, в правильной последовательности. Последовательность важна потому, что одни изменения могут зависеть от других (как в примере с обнуляемым полем).
Общие принципы версионной миграции
Основание миграции
Как оказалось, у большинства подходов есть общий принцип: им необходимо основание (baseline) — некоторое эталонное состояние БД, от которого можно отталкиваться. Эта концепция довольно хорошо описана в статье «Versioning Databases – The Baseline» Скотта Аллена.
Попросту говоря, основание — это дамп структуры базы данных для версии, которая принята за базовую. Имея на руках основание, впоследствии всегда можно будет создать БД с нуля. После применения к этой БД всех миграций, созданных в процессе разработки, получим БД со структурой самой последней версии.
Далее будут рассмотрены три подхода к организации версионной миграции баз данных.
Метод инкрементных изменений
Этот метод хорошо описан в статье «Versioning Databases – Change Scripts» все того же Скотта Аллена. Схожий подход также описан в статье «Managing SQL scripts and continuous integration» Майкла Бэйлона.
Структура файлов
Database
|- Baseline.sql
|- 0001.03.01.sql
|- 0002.03.01.sql
|- 0003.03.01.sql
|- 0004.03.02.sql
|- 0005.03.02.sql
|- 0006.03.02.sql
‘- 0007.03.02.sql
В этом примере в папке хранятся все файлы, созданные при разработке версии 03. Впрочем, папка может быть и общей для всех версий приложения.
Хранение истории версий
Это всего лишь пример того, как может выглядеть таблица. При необходимости, её можно как упростить, так и дополнить.
В файле Baseline.sql в эту таблицу нужно будет добавить первую запись:
После выполнения каждого файла-миграции в эту таблицу будет заноситься запись со всеми данными о миграции.
Текущую версию БД можно будет получить из записи с максимальной датой.
Автоматическое выполнение миграций
Завершающий штрих в этом подходе — программа/скрипт, который будет обновлять БД с текущей версии до последней.
Выполнять миграцию БД автоматически довольно просто, т.к. номер последней выполненной миграции можно получить из таблицы MigrationHistory, а после этого остается только применить все файлы с бо́льшими номерами. Сортировать файлы можно по номеру, поэтому с порядком выполнения миграций проблем не будет.
На такой скрипт также возлагается задача добавления записей о выполненных миграциях в таблицу MigrationHistory.
В качестве дополнительных удобств, такой скрипт может уметь создавать текущую версию БД с нуля, сначала накатывая на БД основание, а затем выполняя стандартную операцию по миграции до последней версии.
Плюсы, минусы, выводы
Быстрое и удобное выполнение миграции до последней версии;
Механизм нумерации версий. Номер текущей версии хранится прямо в БД;
Для максимального удобства нужны средства автоматизации выполнения миграций;
Неудобно добавлять комментарии к структуре БД. Если их добавлять в Baseline.sql, то в следующей версии они пропадут, т.к. основание будет сгенерировано с нуля вновь, в качестве дампа новой версии структуры. Вдобавок, такие комментарии будут быстро устаревать;
Возникают проблемы в процессе параллельной разработки в нескольких ветках репозитория. Так как нумерация файлов-миграций — последовательная, то под одинаковыми номерами в разных ветках могут возникнуть файлы с разными DDL-/DML-запросами. Как следствие, при слиянии веток придется либо вручную редактировать файлы и их последовательность, либо же в новой, «слитой» ветке начинать с нового Baseline.sql, учитывающего изменения из обеих веток.
Этот метод в различных формах довольно широко распространен. К тому же, он легко поддается упрощению и модификации под нужды проекта.
В интернете можно найти готовые варианты скриптов по инкрементному выполнению миграций и встроить в свой проект.
Метод идемпотентных изменений
Этот метод описан в статье «Bulletproof Sql Change Scripts Using INFORMATION_SCHEMA Views» Фила Хэка. Описание схожего подхода также изложено в ответе на этот вопрос на StackOverflow.
Под идемпотентностью понимается свойство объекта оставаться неизменным при повторной попытке его изменить.
В тему вспоминается смешная сцена из «Друзей» 🙂
Основная идея этого подхода — написание миграционных файлов таким образом, чтобы их можно было выполнить на базе данных больше одного раза. При первой попытке выполнить любую из SQL-команд, изменения будут применены; при всех последующих попытках ничего не произойдет.
Эту идею проще всего уяснить на примере. Допустим, вам нужно добавить в БД новую таблицу. Если вы хотите, чтобы в том случае, если она уже существует, при выполнении запроса не возникло ошибки, — в MySQL для этих целей есть краткий синтаксис:
Стоит отметить, что в MySQL по какой-то причине запрещено выполнять DDL-запросы внутри условных выражений. Но этот запрет легко обойти — достаточно включить все подобные запросы в тело хранимой процедуры:
CREATE PROCEDURE sp_tmp() BEGIN
IF NOT EXISTS
(
—
— Условие.
—
)
THEN
—
— Запрос, изменяющий структуру БД.
—
END IF ;
DROP PROCEDURE sp_tmp;
Что за птица такая — information_schema?
Полный перечень таблиц с подробной информацией об их предназначении можно посмотреть в тексте стандарта. Краткий перечень можно увидеть в уже упоминавшейся выше статье Фила Хэка. Но самый простой способ, конечно же, — просто открыть эту базу данных на любом рабочем сервере БД и посмотреть, как она устроена.
Пример использования
Итак, вы знаете, как создавать идемпотентные SQL-запросы. Теперь рассмотрим, как этот подход можно использовать на практике.
Пример того, как в этом случае может выглядеть папка с sql-файлами:
В этом примере для каждой минорной версии базы данных создается отдельная папка. При создании каждой новой папки генерируется основание и записывается в Baseline.sql. Затем в процессе разработки в файл Changes.sql записываются все необходимые изменения в виде идемпотентных запросов.
Предположим, в процессе разработки в разное время программистам понадобились следующие изменения в БД:
a) создать таблицу myTable;
b) добавить в нее поле newfield;
c) добавить в таблицу myTable какие-то данные.
Все три изменения написаны так, чтобы не выполняться повторно. В результате, в каком бы из промежуточных состояний не находилась база данных, при выполнении файла Changes.sql всегда будет выполнена миграция до самой последней версии.
К примеру, один из разработчиков создал на своей локальной копии БД таблицу myTable, записал изменение a) в хранящийся в общем репозитории кода файл Changes.sql, и на какое-то время забыл о нём. Теперь, если он выполнит этот файл на своей локальной БД, изменение a) будет проигнорировано, а изменения b) и c) будут применены.
Плюсы, минусы, выводы
Очень удобное выполнение миграций с любой промежуточной версии до последней — нужно всего лишь выполнить на базе данных один файл (Changes.sql);
Потенциально возможны ситуации, в которых будут теряться данные, за этим придется следить. Примером может служить удаление таблицы, и затем создание другой таблицы с тем же именем. Если при удалении проверять только имя, то обе операции (удаление и создание) будут происходить каждый раз при выполнении скрипта, несмотря на то, что когда-то уже выполнялись;
Для того, чтобы изменения были идемпотентными, нужно потратить больше времени (и кода) на их написание.
Благодаря тому, что обновить базу данных до последней версии очень просто, и делать это можно вручную, этот метод показывает себя в выгодном свете в том случае, если у вас много продакшн-серверов и их нужно часто обновлять.
Метод уподобления структуры БД исходному коду
Отдельных статей, посвященных этому подходу, я, к сожалению, не нашел. Буду благодарен за ссылки на существующие статьи, если таковые имеются. UPD: В своей статье Absent рассказывает о своем опыте реализации схожего подхода при помощи самописной diff-утилиты.
Основная идея этого метода отражена в заголовке: структура БД — такой же исходный код, как код PHP, C# или HTML. Следовательно, вместо того, чтобы хранить в репозитории кода файлы-миграции (с запросами, изменяющими структуру БД), нужно хранить только актуальную структуру базы данных — в декларативной форме.
Пример реализации
Для простоты примера будем считать, что в каждой ревизии репозитория всегда будет только один SQL-файл: CreateDatabase.sql. В скобках замечу, что в аналогии с исходным кодом можно пойти еще дальше и хранить структуру каждого объекта БД в отдельном файле. Также, структуру можно хранить в виде XML или других форматов, которые поддерживаются вашей СУБД.
К примеру, в текущей версии репозитория уже есть таблица myTable, и в файле CreateDatabase.sql она выглядит следующим образом:
После этого измененный sql-файл сабмиттится в репозиторий кода.
Выполнение миграций между версиями
Чтобы выполнить миграцию с одной версии БД до другой, вам придется восстановить на двух временных БД структуру исходной и конечной версий, и затем сгенерировать миграционный скрипт. Впрочем, эта процедура может быть автоматизирована и много времени занимать не должна.
Как быть с изменениями данных?
Время от времени, при обновлении версии базы данных на продакшн-серверах, нужно обновлять не только структуру БД, но и хранящиеся в ней данные. В качестве примера можно привести перенос данных из таблицы со старой структурой в новые таблицы — в целях нормализации. Поскольку данные на продакшн-серверах уже существуют и используются, недостаточно просто создать новые таблицы и удалить старые, нужно еще и перенести имеющиеся данные.
В предыдущих методах, в контексте хранения и выполнения миграций, данные мало чем отличались от структуры БД. Но в данном методе изменения в данных стоят особняком, ведь хранить их в репозитории кода в декларативной форме невозможно: данные на всех серверах разные. А автоматически сгенерировать такие запросы для изменения данных также невозможно: это требует человеческого вмешательства.
Плюсы, минусы, выводы
Удобно наблюдать изменения в структуре между версиями при помощи средств системы контроля версий;
Как и любой исходный код, структуру БД удобно комментировать;
Для того, чтобы с нуля создать чистую базу данных последней версии, нужно выполнить всего лишь один файл;
Скрипты-миграции более надежны, чем в других методах, так как генерируются автоматически;
Мигрировать с новых версий на старые почти так же просто, как со старых на новые (проблемы могут возникнуть только с пресловутыми изменениями данных);
В случае слияния двух веток репозитория, merge структуры БД осуществляется проще, чем при использовании других подходов;
Изменения данных придется хранить отдельно, и затем вручную вставлять в сгенерированные скрипты-миграции;
Вручную выполнять миграции очень неудобно, необходимы автоматизированные средства.
Этот метод имеет много позитивных качеств. Если вас не страшат описанные проблемы с изменениями данных, и если обновления продакшн-серверов случаются редко, рекомендую использовать именно этот метод.
Готовые решения для версионной миграции БД
Описанные выше методы могут использоваться без сторонних решений, однако существуют и готовые к использованию продукты, каждый со своей идеологией и оригинальным подходом, достойные отдельной статьи. При выборе решения версионной миграции, обязательно рассмотрите и такие продукты.