Миграция баз данных: зачем и почему
Со временем в И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 необходимо использовать инновационные и эффективные методы хранения информации, особенно если речь идет о сложной ветвящейся СУБД. Миграция БД – это серьезный шаг, который позволит компании перейти не только на новую технологию, но и выйти на новый уровень ИТ-инфраструктуры.
Опубликовано 25.01.2021
