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

Данные (Data) — формы представления информации, с которыми работают информационные системы компании и их пользователи.

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

База данных, БД (Database, DB) — совокупность данных компании или проекта, которые хранятся соответствии со схемой. Это: статические данные (неизменяемые, хранятся в lookup-таблицах), пользовательские (изменяются при работе с приложением), все объекты БД (процедуры, таблицы, триггеры и пр). Все действия с данными выполняют в соответствии с правилами средств моделирования данных.

Система управления базами данных, СУБД (Database Management System, DBMS) — ПО, обеспечивающее создание и управление БД.

Схема базы данных (Database schema) — структура БД, описанная на формальном языке, поддерживаемом СУБД. Включает описание содержания и ограничений целостности. Основные объекты графического представления схемы — это таблицы и связи. Может содержать и другие объекты, но не пользовательские данные: представления, индексы, пакеты, связи БД, последовательности.

Таблица (Table) — связанные данные, которые в структурированном виде хранятся в БД. Состоит из столбцов и строк.

Миграция данных (Data Migration) — 1. Разовое массовое перемещение данных из систем-источников в систему-приемник. Эксплуатация данных в системах-источниках при этом прекращается. 2. Процесс преобразования БД, при котором меняется схема БД от одной версии до другой. Миграция подразумевает как прямое изменение БД (апгрейд, db_upgrade), так и обратное изменение (даунгрейд, db_downgrade).

Системы-источники (исторические системы) — БД компании, которые будут полностью или частично менять при внедрении новой системы.

Система-приемник — целевая система, в которую переносят данные из системы-источника.

Исходные данные — данные, выгруженные из исторических систем (обычно в формат xls-файлов, поскольку этот формат «понимает» большинство исторических систем разных поколений).

Трансформация данных — процесс преобразования, конвертации исходных данных в в данные для загрузки в соответствии с шаблонами.

Данные для загрузки — данные, готовые для загрузки в целевую систему.

Шаблоны данных для загрузки — описание таблиц данных для загрузки в систему-приемник.

Версия БД — определенное состояние структуры БД. У версии есть номер, соотносящийся с номером версии приложения, так как приложение и БД — неразрывные части целого.

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

За годы и десятилетия работы в вашем ИT-ландшафте наверняка появилось несколько (а у некоторых довольно много) информационных систем разного типа, которые служат для поддержки бизнес-процессов и баз данных, а также их автоматизации. Со временем управление этим «зоопарком информационных систем», как в шутку говорят ИТ-специалисты, становится нерентабельным, а бизнес-требования нового времени не могут преодолеть технологические ограничения, которые не позволяют развивать ИС. Устаревшие БД становятся сильно подвержены внешним вторжениям и утечкам конфиденциальной корпоративной информации. Поэтому, чтобы обезопасить данные также применяют миграцию БД.

В 2014 году в России взят курс на импортозамещение систем, лицензируемых зарубежными производителями и подпадающих под санкции. Это резко увеличило спрос на полную или частичную замену БД в компаниях и госсекторе.

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

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

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

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

Ниже мы опишем нюансы двух разных процессов: миграции базы данных (когда все данные переезжают в новое место) и версионной миграции данных (когда в базу ежедневно вносятся изменения при разработке приложения).

Процесс переезда БД включает организационную подготовку и собственно миграцию. Обе эти части миграции происходят в несколько этапов.

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

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

План. Сюда входят: объем переносимых данных, даты выгрузки данных из исторических систем, периоды среза (области фильтра) данных для миграций, даты тестовых и итоговой миграций, объемы тестовых миграций. В течение работ план может неоднократно корректироваться.

Состав мигрируемых данных. Что будет подлежать миграции? Например: остатки, обороты, классификаторы, справочные или транзакционные данные.

Определение способов и критериев проверки качества в процессе и по итогам миграции — целостности, согласованности, корректности данных и отсутствия их дублирования без причин.

Определение способов отката БД к предыдущему состоянию в случае ошибок и сбоев в процессе миграции.

Этапы технологической части
Подготовка шаблонов загрузки данных и загрузчика файлов данных. Шаблон содержит технические описания: всех полей данных для загрузки, правил загрузки таблицы целевой системы на основании данных для загрузки, заполнения полей таблиц целевой системы, если перенос данных будет не «один в один» из файла данных для загрузки.

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

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

Мэппинг данных. Data mapping — это процесс сопоставления исходных данных и данных для загрузки. Этап может занимать до 50% всех работ по миграции. Подэтапы: мэппинг полей и мэппинг таблиц. Здесь возможны действия по нормализации данных.

Подготовка правил трансформации. На основании согласованных реестров мэппинга полей специалисты по целевой системе разрабатывают правила (скрипты) трансформации данных.

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

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

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

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

Пример ошибки при нарушении последовательности запросов. Если в одной из таблиц есть необнуляемое строковое поле (not nullable) без данных (пустая строка), то вы можете решить, что семантически неправильно хранить пустые строки. Правильно было бы хранить NULL'ы. Последовательность действий здесь должна быть такой:

1. Изменить тип поля на nullable.
   
   
2. Заменить в этой таблице на продакшн БД пустые строки на NULL.
   
   
3. Изменить код приложения так, чтобы при получении из БД данных, хранящихся в этом поле, код адекватно реагировал на NULL'ы. Теперь в это поле вместо пустых строк надо записывать NULL'ы.
   
   

Если до новой версии будет обновлено только приложение (п.3) без БД (п-п 1-2), то в какой-то момент произойдет вставка NULL в поле not nullable, что будет являться ошибкой.

Существует несколько различных подходов к организации версионной миграции баз данных: метод инкрементных изменений, метод идемпотентных изменений, метод уподобления структуры БД исходному коду и другие. Также имеется множество готовых инструментов для версионной миграции БД: Migrator.NET, ECM7.Migrator, Active Record Migrations, SQL Source Control, DotNetMigrations, Fluent Migrator, DbDeploy.NET, Tarantino, Mygrate, DBUpdater, Wizardby и другие. Однако какой бы подход не применялся, в процессе создания и хранения версионных миграций желательно придерживаться следующих принципов:

• чтобы любую версию БД можно было обновить до любой версии;
  
  
• чтобы набор SQL-запросов, которые позволяют реализовать миграцию между любыми двумя версиями, можно было получить максимально быстро и просто;
  
  
• чтобы всегда можно было создать БД с нуля со структурой самой последней версии (полезно как при развертывании нового продакшн-сервера, так и в процессе разработки и тестирования приложения);
  
  
• чтобы при слиянии разных веток после работы над ними ручное редактирование файлов БД было сведено к минимуму;
  
  
• чтобы откатить БД на более раннюю версию было так же просто, как и обновить на более новую.
  
  

Примечание: раздел о версионной миграции даных подготовлен по материалом этой экспертной статьи.

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

Перед его составлением надо произвести аудит всей БД и определиться с качеством данных. В каком формате они находятся, насколько они конфиденциальны, изменит ли это миграция? Важно определить потенциальные проблемы с данными до того, как они возникнут, чтобы адаптировать план соответственно. Также важно определиться со способом резервного копирования данных и выполнить его. Определившись со временными рамками миграции (а это длительный процесс), подготовьте бизнес к периоду простоя.

Также перед составлением конкретного плана миграции данных надо определиться с сотрудниками, которые будут ее выполнять. Группы по миграции желательно отделить от команд разработки и эксплуатации (но сохранить с ними взаимодействие без барьеров), чтобы не перегружать сотрудников, а также потому что специалисты по миграции владеют узкоспециальными знаниями.

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

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

Руководство по миграции. Перенос баз данных MySQL в SQL Server от Microsoft

Миграция реляционных баз данных в Azure

Миграция базы данных PostgreSQL от Selectel

Выполнение миграций от комьюнити веб-фреймворка Laravel

Блог программиста Дмитрия Елисеева

Миграция БД от создателей фреймворка веб-приложений ASP.NET MVC (вверху ссылка на более свежее руководство по ASP.NET Core 5)

MySql-миграции: что это и как реализовать простым php-скриптом с сайта для разработчиков webdevkin.ru

Миграции базы данных из блога для разработчиков «Узелки на память»

Если же вы решили гарантированно обеспечить нужный уровень отказоустойчивости при миграции данных, то можете воспользоваться услугами команды Git In Sky по быстрой и безопасной миграции и поддержке БД.