Импортозамещение: СУБД PostgreSQL

Вячеслав Муравлев, наш ведущий разработчик, рассказал журналу PC Magazine о специфике миграции ИТ-системы с СУБД Oracle на PostgreSQL. Как организовать работу с данными для облегчения процесса миграции? В чем преимущество использования автоматических тестов? И как оптимизация функционала влияет на производительность и нагрузку новой СУБД? Об этом — в материале «Импортозамещение: СУБД PostgreSQL» на сайте и в бумажной версии издания.

Я изложу взгляд на переход на новую СУБД с позиции разработчика ИТ-систем.

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

Первый шаг миграции — это проведение аудита ИТ-системы для ответа на следующие вопросы.

• Каким образом она работает с данными?
• Есть ли автоматические тесты — модульные и функциональные?
• Есть ли бизнес-логика в хранимых процедурах, триггерах?
• Используются ли специфические компоненты СУБД (например, Oracle AQ)?
• Каковы требования к производительности и нагрузке? Насколько возможно отклонение от текущих показателей?

Далее рассмотрим возможные варианты ответов на эти вопросы.

Работа с данными

Хорошей практикой является организация работы с данными через промежуточный слой доступа (Data Access Layer, DAL). Такой слой может быть построен на основе существующих технологий (например, ORM-средств) или разработан самостоятельно. При наличии такого слоя объем доработок ИТ-системы может существенно сократиться (в идеале, свестись к изменению настроек промежуточного слоя — указаний новых названий таблиц и схем, настройке генерации ID, замене типов данных СУБД). Если приложение использовало специфические возможности и расширения SQL-диалекта заменяемой СУБД, то наличие промежуточного слоя позволяет провести локальные замены таких конструкций без сквозных доработок всей системы.

Если промежуточного слоя в системе нет, то можно предложить два варианта.

1. Создать его. Это не дешево и не быстро, но позволит в будущем обезопасить систему от значительных переделок в аналогичных случаях. Это, скорее всего, благоприятно скажется на общей архитектуре системы (зависит, конечно, от архитектуры системы).
2. Решать проблему «в лоб»: искать и заменять в системе специфичные запросы и конструкции, по возможности используя средства автоматизации типа find и sed.

Какой вариант выбрать, однозначно сказать сложно — многое зависит от контекста ИТ-системы. Может оказаться, что стоимость обоих вариантов одинакова. Если переводимую систему планируется эксплуатировать в течение значительного срока, есть смысл вложиться в создание промежуточного слоя доступа.

Тесты

Покрытие существенной части ИТ-системы автоматическими тестами заметно облегчает миграцию (если, конечно, тестирование не проводится средствами СУБД). Прогнав полный набор тестов, можно узнать, какая часть ИТ-системы пострадала от перехода. При внесении исправлений в код появляется быстрая обратная связь. Если такого тестового набора нет, то возможны варианты: 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 человеко-недель.

Выводы

Для тех ИТ-систем, команда разработки которых вела «здоровый образ жизни»: проектировала архитектуру, вкладывалась в тестирование и т. д., — миграция пройдет менее затратно, нежели для ИТ-систем с ситуационной архитектурой или для систем, построенных на основе конкретной СУБД.

Но, с другой стороны, миграция может дать хороший шанс для построения новой архитектуры и дальнейшего развития ИТ-системы. Нередки случаи, когда работы по перепроектированию признаются необходимыми, но откладываются «до лучших времен» или «до подходящего случая». Миграция на новую СУБД — это и есть подходящий случай (выделяются и время, и бюджет, организуется полное регрессионное тестирование), и при определенной расторопности и удачливости у команды ИТ-системы появляется возможность изменить ее (и свою) жизнь к лучшему.