Нюансы миграции с западных СУБД

27.06.2022
Многие зарубежные вендоры объявили об уходе с российского рынка. В этих условиях замена иностранных ИТ-продуктов отечественными стала первоочередной задачей для многих организаций, особенно в тех случаях, когда ИТ-объекты относятся к критической информационной инфраструктуре. Программные продукты Arenadata способны успешно замещать решения таких вендоров, как Cloudera, Oracle, Teradata и Vertica. На основе собственного опыта специалисты Arenadata разработали методические рекомендации по успешной миграции с западных систем.

В этой статье директор по консалтингу Arenadata Антон Балагаев разбирает основные нюансы этого процесса.
Антон Балагаев
Директор по консалтингу Arenadata

Задачи и трудозатраты

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



На долю кода СУБД приходится от 40 до 95% строк прикладных разработок. Это код запросов выполнения операций над данными: модификации данных, представлений и вывода информации. Самое важное в реляционных СУБД — код SQL, наиболее понятный объект приложения усилий при миграции.

ETL/ELT-процессы (0–60% строк) включают процессы загрузки данных, выполненные в ETL-инструментах, часто содержат исполняемый код, написанный на языке СУБД исходной инженерной системы.

Код приложений составляет от 0 до 15% строк. Несмотря на то что приложения, которые обращаются к СУБД, обычно хранят только ссылки на объекты СУБД, они тем не менее могут содержать встроенный код.

Наработки, созданные для выполнения прикладных задач, содержат код различных функциональных типов, и изменения, необходимые для их дальнейшего функционирования, можно классифицировать следующим образом:
  • преобразование метаданных, то есть служебных сведений, описывающих, как хранятся данные и влияющие на них объекты (в наиболее частых случаях — около 5% кода);
  • изменение скриптового кода запросов и представлений, в том числе содержащихся в хранимых процедурах (75% кода);
  • модификация функционального кода процедур, пакетов, функций и триггеров (20% кода).


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

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

До 70% работы со скриптами выполняют аналитики, которые знают бизнес-задачи, понимают, что именно эти скрипты преобразуют и каким должен быть результат. Оставшиеся 30% — дело разработчиков, переписывающих коды в сложных случаях, например при изменении синтаксиса запросов.

Конверсия функционального кода на 70% осуществляется разработчиками, которые хорошо осведомлены о специфике работы алгоритмов преобразования. Остальные 30% приходятся на аналитиков, выполняющих документирование.

После получения новых метаданных, скриптов и функций проводится замена кода. Её выполняют разработчики и аналитики, усилия которых распределяются в соотношениях 70 и 30%, 70 и 30%, 100 и 0%.

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



Как показывает опыт выполнения подобных проектов, перенос кода составляет основную часть трудозатрат, обычно до 80%. Далее следуют трудозатраты на вендорский или архитектурный надзор, верифицирующий правильность выполнения работ (8%), на настройку информационной безопасности (6%), на адаптацию регламентной документации (6%).

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

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

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

Сегодня весьма актуальной становится разгрузка инженерных систем (offload). Так, до сих пор многие организации не разделяли транзакционные и аналитические контуры, работавшие с единым хранилищем данных в комплексах Exadata. В нынешних условиях (из-за проблем с компанией Oracle и трудностей с приобретением новых машин баз данных) разгрузка Exadata позволит вывести на другую СУБД всё, что относится к аналитическому контуру, и оставить на прежних комплексах хорошо себя зарекомендовавшие сервисы, которые работают в OLTP-режиме.

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



Выбор оборудования

Длительность проекта миграции существенно зависит от конкретных условий его выполнения и требований заказчиков. Но при любом сценарии миграции нужно помнить, что для разных СУБД требуется различное оборудование. Поэтому повторно использовать имеющиеся аппаратные средства и обойтись без покупки нового оборудования удаётся не всегда.

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

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

И тогда, как правило, возникает желание всё перенести в облака. Однако нужно учитывать, что публичные облака в большинстве своём не адаптированы к развёртыванию кластерных систем. На основании опыта партнёров Arenadata, прошедших в процессе такой адаптации длинный путь, можно сказать, что это довольно длительный и трудоёмкий процесс.

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

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

Кроме того, в исключительных случаях имеет смысл рассмотреть возможность отхода от лучших практик и объединения таких ранее разделённых сред, как разработка, тестирование, пользовательское тестирование, preproduction.

Дополнительные возможности предоставляет разгрузка инженерных систем за счёт разделения аналитических и транзакционных задач. Сегодня для предприятий особенно важна долгосрочная стратегия непрерывности бизнеса, поэтому аналитические (как и некоторые другие) решения уходят на второй план. Их установка на менее производительное оборудование позволит повысить устойчивость наиболее критичных сервисов.

Освободившиеся аппаратные ресурсы можно использовать для СУБД с колоночным хранением, что значительно сокращает потребности в ёмкости хранения данных. Этот эффект усиливается современными алгоритмами компрессии и возможностью федерализации входящих и исходящих запросов для поддержки размещения данных в различных системах.

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

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

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

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



Источник: статья опубликована в издании «Компьютерный мир» (ИД «Открытые системы)
Всегда на связи. Узнайте больше о миграции иностранных СУБД на решения Arenadata Специалисты Arenadata и сертифицированные партнёры компании имеют релевантный опыт миграции с иностранного ПО. Оставьте заявку на бесплатную консультацию по вопросам миграции с западных СУБД!

Читайте также

все новости
ошибка! проверьте правильно ли вы заполнили поле Email

Этот сайт использует cookie-файлы и другие технологии, чтобы помочь вам в навигации, а также предоставить лучший пользовательский опыт, анализировать использование наших продуктов и услуг, повысить качество рекламных и маркетинговых активностей.