|
Персональные инструменты |
|||
|
Импортозамещение: СУБД PostgreSQLМатериал из CustisWikiВячеслав Муравлев, наш ведущий разработчик, рассказал журналу PC Magazine о специфике миграции ИТ-системы с СУБД Oracle на PostgreSQL. Как организовать работу с данными для облегчения процесса миграции? В чем преимущество использования автоматических тестов? И как оптимизация функционала влияет на производительность и нагрузку новой СУБД? Об этом — в материале «Импортозамещение: СУБД PostgreSQL» на сайте и в бумажной версии издания. Я изложу взгляд на переход на новую СУБД с позиции разработчика ИТ-систем. Первое, что хочется отметить, — очень многое зависит от самой ИТ-системы и того окружения, в котором она работает. Какова продолжительность жизненного цикла системы, численный и качественный состав команды разработчиков, интенсивность доработки, сроки перехода, политика предприятия в отношении вывода текущей СУБД из эксплуатации, бюджет проекта — эти (и, возможно, не только эти) условия будут влиять на принимаемые в ходе миграции решения. Все дальнейшие умозаключения и рекомендации следует соотносить с ответами на эти вопросы. Первый шаг миграции — это проведение аудита ИТ-системы для ответа на следующие вопросы.
Далее рассмотрим возможные варианты ответов на эти вопросы. Содержание[убрать]Работа с даннымиХорошей практикой является организация работы с данными через промежуточный слой доступа (Data Access Layer, DAL). Такой слой может быть построен на основе существующих технологий (например, ORM-средств) или разработан самостоятельно. При наличии такого слоя объем доработок ИТ-системы может существенно сократиться (в идеале, свестись к изменению настроек промежуточного слоя — указаний новых названий таблиц и схем, настройке генерации ID, замене типов данных СУБД). Если приложение использовало специфические возможности и расширения SQL-диалекта заменяемой СУБД, то наличие промежуточного слоя позволяет провести локальные замены таких конструкций без сквозных доработок всей системы. Если промежуточного слоя в системе нет, то можно предложить два варианта.
Какой вариант выбрать, однозначно сказать сложно — многое зависит от контекста ИТ-системы. Может оказаться, что стоимость обоих вариантов одинакова. Если переводимую систему планируется эксплуатировать в течение значительного срока, есть смысл вложиться в создание промежуточного слоя доступа. ТестыПокрытие существенной части ИТ-системы автоматическими тестами заметно облегчает миграцию (если, конечно, тестирование не проводится средствами СУБД). Прогнав полный набор тестов, можно узнать, какая часть ИТ-системы пострадала от перехода. При внесении исправлений в код появляется быстрая обратная связь. Если такого тестового набора нет, то возможны варианты: 1) создать его; 2) провести полное регрессионное тестирование вручную. Возможно, оба варианта окажутся одинаково дорогими и тогда создание тестов будет иметь смысл только для самих разработчиков ИТ-системы как инвестиция на будущее. Здесь на выбор будет влиять, опять-таки, контекст ИТ-системы. Бизнес-логика в СУБДХранимые процедурыЕсли в ИТ-системе бизнес-логика (или ее часть) размещена в хранимых процедурах, то следует определиться: останется ли она там или будет перенесена на уровень сервера приложений. Если бизнес-логика остается на уровне СУБД, то возникают проблемы конверсии текущих процедур в формат новой СУБД и модификации вызовов этих процедур из кода системы. Здесь опять может сыграть положительную роль наличие промежуточного слоя для работы с СУБД, экранирующего особенности работы с процедурами от кода приложения. ТриггерыС триггерами ситуация аналогичная. Если переносить логику триггеров на уровень сервера приложений, то потребуется создание некоего механизма событий для вызова этой логики. Специфические компоненты СУБДТут особо конкретного сказать нечего: если в ИТ-системе использовались специфические возможности СУБД, то их надо либо переносить из СУБД на Open Source или коммерческие (в зависимости от ситуации) аналоги, либо реализовывать собственными силами средствами новой СУБД. Требования к производительности и нагрузкеТут надо учитывать (и доносить это до заказчика ИТ-системы), что какие-то части функционала, оптимизированные под текущую СУБД, могут «проседать» по производительности и нагрузке на новой СУБД. Пока компетенция по новой СУБД невысокая, это исправить не удастся, но со временем ситуация может выправиться. Такие части ИТ-системы могут быть выявлены заранее, либо при прогоне тестов (если они есть), либо при анализе кода на наличие специфических конструкций и тестировании их исполнения на текущей и целевой СУБД. Пример переводаВ рамках изучения возможностей миграции на PostgreSQL компания CUSTIS провела пилотный проект по миграции одной ИТ-системы с Oracle на PostgreSQL. Система представляет расчетную back-office систему, построенную по принципу трехзвенной архитектуры. Большая часть бизнес-логики (основные расчеты) ИТ-системы находилась на уровне сервера приложений, часть логики (бухгалтерский учет) — в хранимых процедурах Oracle. При проектировании ИТ-системы в архитектуру изначально был заложен принцип доступа к данным через Data Access Layer (DAL). DAL был построен на основе технологии JPA поверх Hibernate. Также в ходе разработки ИТ-системы был создан богатый набор модульных тестов, что позволило оперативно выявлять места в коде с использованием специфических для Oracle конструкций. Поскольку сроки миграции были установлены небольшие, а перенос логики компонента учета на PostgreSQL занял бы значительное время, то решили сначала реализовать промежуточный вариант — гибридное хранение данных одновременно в Oracle и PostgreSQL. В Oracle осталась логика учета и необходимые для нее таблицы, а в PostgreSQL были смигрированы остальные данные приложения. Перенос учетной части на PostgreSQL запланировали на второй этап миграции. Для организации гибридного доступа было подготовлено решение на основе инструмента федерализации доступа к данным JBoss Teiid. Оно позволило обращаться к двум СУБД как к единой базе. Поскольку приложение работало через DAL, все эти тонкости для него были экранированы. Сами доработки ИТ-системы заняли около 2 человеко-недель. ВыводыДля тех ИТ-систем, команда разработки которых вела «здоровый образ жизни»: проектировала архитектуру, вкладывалась в тестирование и т. д., — миграция пройдет менее затратно, нежели для ИТ-систем с ситуационной архитектурой или для систем, построенных на основе конкретной СУБД. Но, с другой стороны, миграция может дать хороший шанс для построения новой архитектуры и дальнейшего развития ИТ-системы. Нередки случаи, когда работы по перепроектированию признаются необходимыми, но откладываются «до лучших времен» или «до подходящего случая». Миграция на новую СУБД — это и есть подходящий случай (выделяются и время, и бюджет, организуется полное регрессионное тестирование), и при определенной расторопности и удачливости у команды ИТ-системы появляется возможность изменить ее (и свою) жизнь к лучшему. |
||