Миграция базы данных что это
В чем суть миграций БД?
Здравствуйте.
В данный момент изучаю Flask, проходя данный туториал:
https://blog.miguelgrinberg.com/post/the-flask-meg.
Так как никакого опыта работы с БД я не имею (совсем чайник), то возникло несколько вопросов после прочтения:
https://blog.miguelgrinberg.com/post/the-flask-meg.
Автор данного туториала использует ORM SQLAlchemy.
После прочтения осталось неясным:
1. Что такое миграция, для чего конкретно нужна и как это связанно с сохранением данных?
2. Чем миграция отличается от db_upgrade or db_downgrade?
3. Что будет, если миграции не производить?
1. Что такое миграция, для чего конкретно нужна и как это связанно с сохранением данных?
переход от одной структуры БД к другой без потери косистентности
2. Чем миграция отличается от db_upgrade or db_downgrade?
3. Что будет, если миграции не производить?
Леша: изменилась модель хранения
Добавили пару полей, БД потеряла 3нф
Для восстановления 3нф нужно создать еще одну модель
Теперь нужно переместить часть данных в новую модель
Если не делать миграцию, то связм потеряются = нет консистентности
А без миграции, есть только вариант с удалением таблицы и созданием двух новых
Леша: миграции производятся при изменении полей моделей
Те, поменялся тип поля у модели = миграция
добавилось поле = миграция
Обьем изменений неважен
Причем не всегда изменения возможно провести в один заход. Иногда приходится делать две и более миграции для изменения одного поля
поменялся тип поля у модели = миграция
добавилось поле = миграция
а если поступить так:
остановить сервер
в базе данных (Mysql) ручками произвести изменения
далее в моделях flask подправить соотвествено
далее стратануть веб сервер.
ТАК НЕЛЬЗЯ? ПОЧЕМУ?
На PHP сайтах делаемже и ничо вроде живы!
sim3x,
Тоесть разработчики PHP (да и других языков) сайтов в течении лет так 30 как минимум говнокодили.
Чот как то не укладывается в голове это определение необходиости миграции.
89109983838, да, все время говнокодили
Только не 30, а 22
Миграции требуются в проектах, которые развиваются и поддерживаются
NOSQL хайп уже давно прошел, им все переболели и забыли
Версионная миграция структуры базы данных: основные подходы
Проблемы контроля версий баз данных и миграций между версиями уже не раз поднимались как на Хабре (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 структуры БД осуществляется проще, чем при использовании других подходов;
Изменения данных придется хранить отдельно, и затем вручную вставлять в сгенерированные скрипты-миграции;
Вручную выполнять миграции очень неудобно, необходимы автоматизированные средства.
Этот метод имеет много позитивных качеств. Если вас не страшат описанные проблемы с изменениями данных, и если обновления продакшн-серверов случаются редко, рекомендую использовать именно этот метод.
Готовые решения для версионной миграции БД
Описанные выше методы могут использоваться без сторонних решений, однако существуют и готовые к использованию продукты, каждый со своей идеологией и оригинальным подходом, достойные отдельной статьи. При выборе решения версионной миграции, обязательно рассмотрите и такие продукты.
Миграция баз данных: зачем и почему
Со временем в ИT-ландшафте большинства компаний, долго существующих на рынке, собирается большое количество разнотипных информационных систем (ИС) для автоматизации и поддержки бизнес-процессов, в том числе базы данных (БД). Эти системы «живут» в компаниях годами, а иногда и десятилетиями. Такое множество ИС ИТ-специалисты в шутку называют зоопарком. В какой-то момент его сопровождение становится очень дорогим, а технологические ограничения не позволяют развивать ИС в соответствии с новыми бизнес-требованиями. Тогда компании стремятся обезопасить устаревшие БД от внешних вторжений, утечек и минимизировать риск утраты ценных данных (коммерческой, конфиденциальной информации). Сделать это можно при помощи миграции БД.
Зачем компаниям мигрировать данные, как организовать процесс без потерь и почему это выгодно в долгосрочной перспективе? Рассказываю в статье.
Когда у компаний возник интерес к миграции БД и с чем это связано
Направление миграции БД было популярно за рубежом 15 лет назад. В России на него обратили внимание только в 2014 году, когда появилась необходимость импортозамещения систем, лицензируемых зарубежными производителями и подпадающих под санкции. Что и послужило драйвером роста количества заказов на миграцию и значительно увеличило спрос на полную или частичную замену БД. На тот момент именно импортозамещение оказалось главной целью миграции перехода от устаревших систем к новым. Затем стало ясно, что с помощью миграции БД можно изменить ИT-ландшафт компании – сократить затраты на сопровождение ИС и получить принципиально новые возможности, например, работу с BigData.
Зачем мигрировать
Выгоду постепенной миграции БД можно отследить только в долгосрочной перспективе. Рассматривая вариант ухода от старой системы посредством модернизации на имеющейся платформе, компания сталкивается с трудностями – это дорогостоящий и многоступенчатый процесс. В таком случае новая система будет получать нужные данные из старых БД, которые также будут работать. В итоге бизнесу приходится платить за обе платформы, когда требуется лишь одна. Возрастает стоимость оборудования, необходимого для функционирования всей совокупности ИT-систем, сопровождения. Вдобавок трудовых ресурсов потребуется больше, а специалистов по устаревшим системам мало. Получается, что экономически эффективнее мигрировать все данные, ценные для принятия решений и прогнозирования, на одну платформу.
Миграция БД не только гарантирует экономию средств, но и может стать триггером роста эффективности всего ИT-подразделения. Если правильно подойти к процессу перехода от устаревших систем к новым, он сможет стать началом цифровой трансформации в компании. Если осуществить миграцию в тщательно отработанную целевую архитектуру, можно получить принципиально новые функции, например возможность работы с большими данными. Вот еще несколько причин, почему миграция БД нужна бизнесу.
Говоря о стоимости миграции для бизнеса, следует заметить, что она заметно варьируется для различных систем и может составлять от десятков миллионов рублей для средних компаний до сотен миллионов – для крупных.
Ценообразование процесса зависит от следующих факторов:
Сегодня цель миграции БД – в сокращении издержек на обслуживание ИT-инфраструктуры в долгосрочной перспективе. Более того, последние несколько лет заметен активный интерес к миграции не только БД, но и серверов приложений на российское ПО, что отвечает стратегии импортозамещения, и ПО с открытым кодом.
Процесс миграции БД: с чем вы столкнетесь
Миграция должна быть четко организованной и непрерывной, независимо от способа переноса информации. Без грамотной структуры и продуманного плана компании придется выйти за рамки запланированного бюджета и столкнуться с тем, что целевая система будет работать не так, как планировалось. Во время миграции БД может возникнуть несколько проблем.
В процессе миграции данные преобразуются и перемещаются из одной среды в другую. При этом информация, извлеченная из старой системы, должна «подготовиться» к переносу в целевое местоположение, чтобы команде удалось избежать ошибок, перечисленных выше. Процесс миграции не всегда проходит гладко.
Наиболее неудачный сценарий миграции БД – появление в ИT-ландшафте очередной недоработанной системы, которой нельзя будет пользоваться. Это «эффект второй системы», описанный экспертом в области теории вычислительных систем Фредериком Бруксом. Такой эффект увеличит сложность сопровождения ИС и создаст дополнительную финансовую нагрузку на компанию. Например, в подобной БД будут присутствовать ошибки на уровне данных, которых можно избежать при корректном составлении сценариев или на стадии разработки стратегии миграции. Из возможных технологических ошибок надо отметить неправильный выбор целевой архитектуры, а именно наследование неудачных решений исходной системы.
Более мягкий сценарий неудачной миграции – необходимость обращения к старой системе при наличии новой. Его суть в том, что новая СУБД станет выполнять бизнес-функции, но устаревшую нельзя будет полностью вывести из эксплуатации, поскольку в ней заложены архивные данные для исполнения некоторых бизнес-процессов. И хотя такой тип миграции исключает риск простоев, он довольно сложный – работать нужно будет буквально на два фронта. К тому же компании придется не только выделить бюджет на новую систему, но и платить за обслуживание старой.
Самый оптимальный вариант миграции – комбинированный, плавный. Его суть в том, что в целевой системе готовится платформа со всем необходимым функционалом и данные переносятся постепенно. В новой системе сначала реализуются бизнес-процессы, требующие вовлечения старых систем, затем новая СУБД постепенно принимает на себя функционал не в исходном виде, а с новыми возможностями. Такой вариант миграции предполагает, что у команды есть стратегия переноса данных. В ней должны быть прописаны следующие условия, критические для корректной миграции.
Подходы к миграции БД: какой выбрать
Мигрировать данные из исходной системы в целевую можно несколькими способами – с помощью автоматизации или вручную. Применение той или иной методики зависит от вводных условий и состояния исходной системы. На следующих примерах объясняю суть каждого из подходов.
1. При автоматизированном подходе вмешательство человека в структуру БД минимизируется. Технической группе, занимающейся миграцией БД, нужно создать комбинацию методик и инструментов, которые позволят наладить непротиворечивое и повторяемое управление изменениями в структуре БД и в самих данных. Это гибкий способ миграции, поскольку любой участник команды сможет внести изменения в БД как в общий сервер, так и на локальную версию в различных программных средах без обработки данных вручную.
Несколько лет назад мы мигрировали базу данных для крупного российского банка с платформы Microsoft SQL Server 2008 на Oracle 11g. Заказчик хотел централизовать ИС различных территориальных подразделений в единую систему, выбрал одну из целевых архитектур и решил перенести туда все существующие решения. Основной сложностью было то, что система не могла простаивать более 72 часов и дорабатывалась в процессе миграции.
2.Подобные требования к проекту наложили очень серьезные ограничения на подход к решению. Мигрировать с применением ручных техник было невозможно из-за жестких требований по времени самой миграции. Поэтому мы разработали систему, которая автоматизировала перевод системы заказчика (включая перевод всех данных, хранимого кода, проведения тестирования и анализа производительности) на новую платформу. Мы проводили большое число тестовых миграций как отдельных модулей, так и всей системы, тестирование и доработку системы миграции, что позволило выполнить всю процедуру без сбоев и в требуемое время. Также техническая группа по миграции разработала методику тестирования, основанную на записи и воспроизведении взаимодействия БД с внешними приложениями и связанными системами.Ручной подход предполагает, что команда разработки вносит изменения в структуру целевой БД и переносит данные вручную. Мы осуществляли миграцию медицинской системы с устаревшей версии СУБД на новую от другого поставщика. В этом случае исходная система уже не модифицировалась, и перед нами стояла сложная задача по восстановлению информации о ней. Так как документации не осталось, а разработчики системы были недоступны для консультаций, мы применили ручной подход и начали миграцию с разбора функциональности существующего решения и проведения соответствия с бизнес-требованиями к процессам.
В результате удалось мигрировать данные и встроить систему в новые бизнес-процессы, при этом объем кода уменьшился более чем в два раза. Кроме того, получилось исключить уже не используемые модули и функциональные возможности.
Миграция БД – комплексный и важный для компании процесс. Необходимость сохранения целостности данных требует, чтобы он выполнялся правильно, а техническая группа осознавала целеполагание и следовала четко проработанной стратегии.
Проводя миграцию БД, компания уменьшает расходы на сопровождение не актуальных систем в частности и ИT-инфраструктуры в целом, оптимизирует ИС, перемещая все данные в одно место, и создает дополнительный барьер от атак злоумышленников. В эпоху big data необходимо использовать инновационные и эффективные методы хранения информации, особенно если речь идет о сложной ветвящейся СУБД. Миграция БД – это серьезный шаг, который позволит компании перейти не только на новую технологию, но и выйти на новый уровень ИТ-инфраструктуры.