Переход с Oracle на PostgreSQL: проблемы и их решение


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

Как избежать проблем в процессе миграции с Oracle

Когда мы говорим о переходе с Oracle на Postgres, то в первую очередь вспоминаем об импортозамещении. Но только ли в этом цель такой замены? Какие проблемы и подводные камни ждут нас на этом пути?

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

Например, во многих системах, в ядре которых используется Oracle, часто можно встретить использование PL/SQL. PL/SQL – это сильный инструмент, но его привязка к Oracle создаёт серьёзный "vendor lock", затрудняя миграцию на другие платформы и увеличивая зависимость от одного поставщика. Такая зависимость особенно остро ощущается, когда большой объём критически важной бизнес-логики реализован непосредственно в базе данных. В случае, когда компания остается на Oracle, она, скорее всего, рано или поздно столкнётся с отсутствием возможности горизонтального масштабирования бизнес-логики и сервисов её реализующих. Если же решение о замене принято, то в первую очередь следует оценить объем логики внутри СУБД. И при условии, что он переваливает за 50%, необходимо понимать, что такой переезд сопоставим с разработкой с нуля.

Решение задачи по переходу с Oracle на PostgreSQL «в лоб», связано с преобразованием пакетов и процедур PL/SQL в аналогичные структуры на PostgreSQL. Это непростой вопрос из-за различий в возможностях и синтаксисе обоих языков. На практике, такой подход приводит к тому, что из одного «vendor lock», мы попадаем в другой, попутно оставшись с проблемой отсутствия горизонтального масштабирования.

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

Переход к новым возможностям: ключевые вызовы и пути их преодоления

В 2023–2024 годах компания IconSoft (создана при участии АО «ГЛОНАСС») осуществляла масштабный проект по миграции с Oracle на PostgreSQL для одного из своих крупных заказчиков. Проект, в том числе, подразумевал перенос всех данных и процессов из систем, являющихся объектами КИИ, что предъявляло серьезные требования к решению задач по переходу. При этом, как было написано выше, обязателен был перенос всей бизнес-логики систем. Проект длился около полугода и, несмотря на все сложности, был успешно реализован – сейчас все системы данного клиента функционируют уже на СУБД PostgreSQL.

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

Рассмотрим более детально основные проблемы и методы их решения с которыми специалисты сталкиваются в ходе миграции на PostgreSQL.

1. Перенос таблиц и типов данных

Первым и одним из наиболее критичных этапов миграции является перенос таблиц и типов данных. На этом этапе проводится детальный анализ используемых в Oracle типов данных и их аналогов в PostgreSQL. Особое внимание уделяется специфическим случаям, где требуются специализированные решения. Формируется свод правил для разработчиков с указанием, какие типы данных Oracle соответствуют типам данных в PostgreSQL и что необходимо делать в той или иной ситуации. Это существенно облегчает процесс адаптации кода и структур базы данных, а также позволяет получить единообразие решений по смене структур данных.

2. Перенос пакетов Oracle

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

3. Средний слой и управление датами

В PostgreSQL другой принцип хранения дат с таймзонами, который отличается от принципа Oracle. Хотя это не требует разработки дополнительного программного обеспечения, разработчики должны учитывать такие различия при работе со средним слоем приложений. Это особенно важно для систем, чувствительных к временным меткам и таймзонам.

4. Автономные транзакции

Одной из особенностей Oracle является поддержка автономных транзакций, которых нет в стандартной версии PostgreSQL. Такие транзакции доступны только в версии Enterprise. Для решения этой задачи при миграции на версию Standard, можно разработать специальный механизм, позволяющий эмулировать поведение автономных транзакций. Это станет важным элементом в поддержке существующей бизнес-логики, которая остается в БД.

5. Секционирование

Секционирование в PostgreSQL реализовано иначе, чем в Oracle, что требует отказа от использования традиционных секций Oracle и пересмотра подходов к организации данных. Вместо этого создаются дополнительные индексы и проводится оптимизация запросов, что позволяет достичь сопоставимой производительности без использования секционирования по старому принципу. Анализ переноса секционированных таблиц является одной из ключевых задач на старте проекта

6. Миграция данных

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

Выгоды от миграции

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

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

Подробнее на сайте IconSoft

2377

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.

Предметная область
Отрасль
Управление
Мы используем файлы cookie в аналитических целях и для того, чтобы обеспечить вам наилучшие впечатления от работы с нашим сайтом. Заходя на сайт, вы соглашаетесь с Политикой использования файлов cookie.