Как отказаться от Oracle и MS SQL Server в закрытом контуре?
Современные ИТ базируются на системах управления базами данных (СУБД) — практически в любом достаточно сложном высокотехнологичном инструменте есть та или иная база, которая накапливает и обрабатывает данные пользователей. Хотя сейчас популярны нереляционные базы, тем не менее классические СУБД, основанные на языке SQL, по-прежнему остаются достаточно популярными — они используются в транзакционных и высоконагруженных информационных системах. Лидерами в производстве подобных базовых компонент остаются такие компании как Oracle, Microsoft и IBM, которые покинули российских пользователей. Однако основанные на их продуктах СУБД продолжают работать, а это значит, что их нужно сопровождать по мере устаревания и готовить приложения на их основе к переносу на отечественные решения.
SQL-миграция
В проектах, связанных с Большими данными, таких как искусственный интеллект и IoT, используются распределенные нереляционные базы, однако в коммерческих решениях — интернет-магазинах, веб-сайтах, CRM, ERP, бухгалтерии — по-прежнему внедрены SQL-базы. Сам язык SQL хорошо стандартизован, однако коммерческие производители, такие как Oracle и Microsoft, разработали для него расширения различных встроенных процедур, которые мешают просто взять приложения с одной SQL-базы (например, Oracle, DB2 или MS SQL Server) и перенести ее на другую (PostgreSQL, MySQL и аналоги). Это связано с хранимыми процедурами на специализированных языках программирования, так для Oracle — это PL/SQL, для MS SQL Server — Transact-SQL, для DB2 — SQL PL.
Естественно, что и открытые базы данных также имеют свои собственные процедурные языки, причем обычно несколько. Так в PostgreSQL по умолчанию процедуры можно писать в том числе и на PL/pgSQL, и C. Поэтому, чтобы перенести приложения, написанные для базы данных одного производителя, придется портировать и встроенные процедуры с одного языка на другой. Если разработчики приложений использовали не очень много процедурных вставок и они достаточно простые, то процесс переноса может оказаться достаточно легким, в противном же случае проще заново разработать процедуры на новом языке, чем портировать старые с помощью средств автоматической миграции.
В рамках проектов по импортозамещению СУБД часто возникают вопросы по переносу приложений с Oracle на PostgreSQL. Сейчас это очень популярное направление перехода с одной СУБД на другую, поэтому оно вызывает интерес у большого количества заказчиков. Причем, помимо чисто технических аспектов такого переноса, можно столкнуться и с организационными — необходимостью анализировать системы заказчиков, находящиеся в закрытом контуре предприятий без доступа к реальным данным.
Аналогичные проблемы могут возникнуть в случае, если заказчик не может дать прямой доступ к СУБД по причине сложности согласования с ИБ и необходимости защиты конфиденциальной информации или персональных данных. В этом случае можно использовать следующий пошаговый подход:
- Шаг 1. Заказчик самостоятельно, с помощью специальных скриптов, собирает информацию по самым крупным объектам в БД, с точки зрения объема процедурного кода. Команду миграции в первую очередь должны интересовать объекты, представляющие внутреннюю бизнес-логику базы, такие как процедуры и функции (для примера). По результатам деятельности этих скриптов формируется список наиболее крупных объектов по объему портируемого кода. По результатам его анализа можно сделать первичные выводы о том, много ли включений в код уникальных операторов диалекта PL/SQL или операторов(функций), свойственных только СУБД Oracle. По итогам формируем первичное представление, какой объем придется переписывать вручную. Если затраты, которые придется понести заказчику, его устраивают, то можно переходить к следующему этапу.
- Шаг 2. Необходимо сформировать выгрузку метаданных СУБД, которая содержит только служебные сведения о наименовании таблиц, функций, триггеров и других внутренних объектов базы данных. Она позволяет сформировать виртуальный стенд с аналогичными метаданными и произвести подробный анализ всей СУБД вместе с процедурами, но не заполненный реальными данными. По результатам этой деятельности должен быть составлен список объектов и функций СУБД, которые нужно либо переписывать вручную, либо заменить на аналоги в PostgreSQL.
- Шаг 3. Далее на основании исследования с предыдущего шага принимаем решение о целесообразности портирования тех или иных сервисов базы данных. Если портирование нецелесообразно, то приходиться полностью переписывать его под PostgreSQL.
Компании сейчас не обязательно эту работу делать самостоятельно — можно воспользоваться услугами компаний, которые имеют большой опыт подобной миграции и наработанные скрипты, автоматизирующие весь процесс.
«Айтанго» по поддержке СУБД
Фокусными направлениями компании «Айтанго» как раз и являются услуги, связанные с СУБД и DevOps. Причем она может как оказывать услуги по поддержке уже внедренных баз данных иностранных производителей, так и обеспечивать процесс переноса работающих решений на отечественные с помощью использования методологии DevOps — без остановки работы приложений. Компания в рамках обеспечения собственной импортонезависимости обучает и сертифицирует своих инженеров для работы с «Я.Облако», продолжая при этом работать с проектами с открытыми кодами: TeamCity, Jenkins, Ansible, ELK, Docker, Kubernetes, Openshift и других. Это позволяет переносить устаревшие реплики баз данных в том числе и в новые облачные среды.
Уникальным же предложением «Айтанго» являются проекты по миграции с одной СУБД на другую в рамках закрытого контура без прямого доступа специалистов компании к самим данным по описанной выше процедуре. Инженеры компании могут развернуть несколько виртуальных машин у себя, установить в них СУБД и перенести ее на отечественную платформу, а потом переместить уже готовое и протестированное решение в контур заказчика с постепенной миграцией данных уже в закрытом контуре. В этом случае специалисты компании на своем стенде производят все необходимые настройки, после чего контейнер с настроенной СУБД и сопутствующим ПО целиком переносятся в контур клиента, оперативно разворачивается и постепенно, в соответствии с правилами DevOps замещает работающее иностранное решение. Причем специалисты «Айтанго» уже выполняли проекты в том числе и по миграции в закрытом контуре СУБД с обычного PostgreSQL на Postgres Pro.
В целом, процесс переноса базы данных на импортонезависимое решение сейчас можно сделать достаточно эффективно, причем без остановки функционирования системы — для этого используется методология DevOps. Причем услуги специализированной компании, такой как «Айтанго», скорее всего, обойдутся заказчику дешевле, а их результат будет более надежен за счет накопленного опыта и подготовленных средств автоматизации процесса миграции с учетом особенностей различных СУБД. Хотя сотрудники заказчика лучше понимают заложенную в базу данных бизнес-логику, тем не менее для перехода с одной СУБД на другую важнее более тонкое знание особенностей обоих продуктов.
