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

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

Опыт компании Arenadata

Антон Балагаев, директор по консалтингу Arenadata

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

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

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

В компании Arenadata созданы продукты, способные замещать решения таких зарубежных вендоров, как Cloudera, Oracle (Exadata и Big Data Appliance), Teradata, Vertica и ряда других.

Программные решения Arenadata вошли в проекты миграции крупнейших российских организаций, включая ФНС РФ, Счетную палату России, ПАО «Газпром нефть», банк ВТБ, X5 Retail Group и ряд других.

На основе собственного опыта специалисты 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-задач.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

     

    Источник

    Xrfiles.ru - это Файлы XR, содержащие данные для программы, которые можно загрузить в память системы.

    Файлы XR содержат файлы компоновки, в которых хранятся коды для всех классов и методов, используемых в программе.

    Кроме того, Файлы XR содержат текстовые файлы, в которые заносятся различные дополнительные сведения о каждом классе, методе и файле. Для всех Файлов XR, кроме файлов компоновки и текстовых файлов, необходимо задать имена.
    Рейтинг
    ( Пока оценок нет )
    Понравилась статья? Поделиться с друзьями:
    Xrfiles.ru
    Добавить комментарий

    ;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: