Зачем нужна миграция данных? По некоторым оценкам, к 2023 году объем накопленной в мире информации достиг 120 зеттабайт. И количество информации будет только расти. Поэтому системы, которые потребители выбирали когда-то давно, вряд ли будут готовы к таким объемам. И, конечно, с постоянным развитием сетевой инфраструктуры растут и ожидания пользователей по скорости ответа ИТ-систем. И даже если постоянно добавлять старым серверам ресурсов, в какой-то момент развитие системы остановится из-за сложностей с масштабированием. Так что если вы ведете ИТ-проект, с большой вероятностью придется базу данных в какой-то момент придется заменять.
Одна из ключевых причин, зачем компании перемещают данные из собственной инфраструктуры в облачную, — смена парадигмы от владения к аренде, которая позволяет платить ровно столько, сколько используют ресурсов. И это стало одной из причин, почему, по данным Deloitte Insights, к 2023 году примерно 94% компаний используют хотя бы один облачный сервис.
Помимо возможности управлять издержками на поддержание проекта, миграцию данных могут делать и с целью повышения безопасности, и ради получения доступа к новым технологиям. К примеру, Platform V СберТеха предлагает целую линейку хорошо интегрированных между собой решений.
В этой статье мы рассмотрим основные особенности процесса миграции данных, в том числе подготовку, выбор инструментов, планирование, экспорт и импорт информации, тестирование и оптимизацию.
Подготовка к миграционному процессу
Самое важное на этом этапе — это определить круг заказчиков работ, причины, цель, критерии ее достижения в процессе перехода с текущей базы данных на другую. Точное понимание решаемых проблем (будь то необходимость нарастить производительность, снижение издержек на поддержку системы, импортозамещение или любые другие) позволяют оцифровать критерии, по которым мы поймем, что цели мы достигнем.
Сформулированные критерии помогут составить список приемочных испытаний нового решения. Помимо технических параметров, важно указать сценарии работы, которые должны отрабатывать на новой базе данных. Взять их можно из документов, продуктовых требований. Это очень важный этап, поскольку позволяет точно зафиксировать ожидания пользователей от системы и не потерять функциональность сервисов и приложений в ходе миграции между базами данных.
Полученная в ходе подготовки проекта информация позволит принять ряд важных решений:
- брать ли новую систему во владение или в аренду;
- где ее размещать: на своих мощностях или в дата-центре;
- кому поручить поддержание работы сервера: собственным специалистам или подрядчику, роль которого могут взять на себя и сотрудники дата-центра, где вы держите оборудование.
То есть подготовка миграции данных — это совместная работа как технической команды, так и бизнес-команды, который отвечает за его экономическую составляющую. И важно учитывать не только долгосрочную стоимость поддержания новой среды, но и реализацию самого проекта, закупку лицензий и вероятные потери клиентов из-за возможного снижения доступности сервиса во время миграции.
Выбор инструмента для миграции
Обычно производители баз данных — и коммерческие, и сообщества разработчиков БД с открытым исходным кодом — создают различные утилиты переноса информации в свою систему.
Перемещение данных возможно произвести самостоятельно с использованием встроенных инструментов. В то же время перенос кода хранимых процедур может потребовать ручного переписывания или применения коммерческих или бесплатных инструментов конвертации. Важно отметить, что ни платные, ни бесплатные инструменты качества своей работы не гарантируют, но в проприетарных решениях есть техподдержка, которая поможет решить возникающие проблемы. Автоматически переведенный код не всегда получается оптимальным, и после миграции может оказаться, что система с новой базой данных работает медленнее, чем могла бы. В этом случае производительность можно довести до требуемой вручную с помощью доработок.
Если в коде бэкенда использовались вызовы прямой выборки и управления данными, то вероятно потребуется и его доработка. И в этом случае уже потребуется полное тестирование системы на новой базе данных.
Планирование и стратегия
Выбор стратегии зависит от конкретных условий и целей проекта.
- Полная миграция, где все данные переносят одновременно. Происходить это может по-разному, в зависимости от характера данных и задач, решаемых сервисом. Например, это может быть реализовано перезапуском сервиса с переключением на новую БД, куда начинают поступать новые данные. А старые (накполенные до момента переключения) копируют “на лету”. Этот вариант, допустим, например, в системе сбора чаевых, где поступление новых платежей не зависит от старых данных. Такой подход позволит почти без простоя переключиться на новую систему, но вызовет временную деградацию сервиса из-за невозможности посмотреть историю до тех пор, пока старые данные не скопируются в новую систему.
- Частичная миграция, при которой данные переносят небольшими партиями, помогает лучше контролировать процесс и минимизировать риски. Например, можно сначала перенести менее критичные данные и протестировать их работу в новой системе, а затем перейти к более важным. Этот подход требует больше времени, но обеспечивает более высокую надежность. И здесь в проект придется включать доработки на диспетчеризацию запросов.
В Platform V есть специальные средства, которые позволяют маршрутизировать запросы между системами. Так, можно запустить обработку запросов в двух и более БД, одна из которых может под промышленной нагрузкой постепенно забирать обработку себе. Содержание двух систем увеличивает расходы на инфраструктуру и ее сложность, зато позволяет не рисковать всеми клиентами сразу, а плавно переводить их в новый сервис, аккуратно отслеживать качество его работы.
Очистка и преобразование данных при их экспорте/импорте
Подготовку к очистке и преобразованию информации надо делать на этапе подготовки всего проекта. В этот момент нужно обратить внимание на типы данных, которые используют в таблицах, и понять, как они должны преобразоваться в новые в другой БД. Например, в Oracle и PostgreSQL используются разные типы, и их соответствие не всегда очевидно. Тип NUMBER в Oracle может быть преобразован в NUMERIC или DECIMAL в PostgreSQL. И на этапе планирования миграции важно оценить, что хранится в NUMERIC в Oracle, какие значения, и какой именно для них подойдет новый тип в PostgreSQL. Причем это нужно делать не в сам момент оценки, а предвидеть, какие значения могут набраться к моменту миграции. То же самое с текстовыми данными. Типы VARCHAR2 и CLOB в Oracle могут быть преобразованы в VARCHAR и TEXT в PostgreSQL соответственно.
Тестирование и проверка
В процесс миграции должны быть обязательно встроены шаги контроля качества переноса данных. Необходимо проверить полноту и целостность данных, а также убедиться, что механизмы контроля целостности корректно работают и в новой системе.
Для проверки полноты переноса можно пересчитать количество строк в старых и новых таблицах. Можно дополнительно рассчитать контрольные суммы по некоторым столбцам. Это помогает выявить любые несоответствия или потери данных.
Следующий этап — функциональное тестирование. Оно заключается в проверке того, как работают приложения и сервисы, которые используют перенесенные данные. Нужно удостовериться, что все бизнес-кейсы решаются и что система ведет себя в соответствии со спецификацией. При переносе данных придется пересоздавать структуру пользователей и ролей, потому надо провести аудит прав доступа новых пользователей и ролей, а также контроль задействованных уровней шифрования.
Управление производительностью и оптимизация
Важно оценить примерную производительность в новой системе до фактической миграции. Решить эту задачу можно несколькими способами.
Самое простое — это моделирование нагрузки. Если характер текущей промышленной нагрузки известен, для испытаний новой базы данных подойдут имитаторы запросов, соответствующих реальным. На этой модели можно будет опробовать принципы, подходы и инструменты обеспечения требуемой производительности. В крупных проектах полную миграцию сразу обычно не делают — нагрузку переводят постепенно. В этот момент стоит обратить внимание на поведение системы и соответствие ожидаемым параметрам, которые вы получили на модели.
Если все хорошо, то можно перейти к следующему этапу: переводу данных из старой базы в новую. Важно делать это плавно, поскольку по мере роста нагрузки использование вычислительных ресурсов и фактическая производительность решения может изменяться нелинейно.
Обучение и поддержка пользователей
В программу обучения обязательно должны входить блоки:
- управление безопасностью решения;
- измерение производительности;
- своевременное выявление проблем;
- средства их оперативного решения.
Это обучение нужно включить в стоимость и план проекта и провести до начала перевода промышленной нагрузки на новую базу.
Заключение
При разработке проекта миграции на новую базу данных важно сформулировать цель и ожидания от проекта.
Стоит подготовить план миграции, в который необходимо включить технические меры:
- Подбор нового решения и моделирование нагрузки на нем.
- Исследование старой структуры данных.
- Планирование новой БД и инструментов.
- Планирование вычислительных ресурсов на новую базу данных.
- Подготовка приемочных испытаний. Они включают как технические критерии, так и описание бизнес-кейсов, которые должна решать система.
- Контроль качества миграции.
- Порядок проведения аудита безопасности.
Помимо технических особенностей важно уделить внимание и организационным: обеспечить финансирование, учесть бюджетные ограничения, включить в проект не только прямые затраты, но и обучение персонала.
