Миграция с Oracle на PostgreSQL: зачем, как и что для этого нужно

Уменьшить затраты. В 90% случаев с Oracle на PostgreSQL переходят, чтобы сократить издержки. Лицензии Oracle платные, и довольно дорогие, а PostgreSQL — открытое ПО, которое можно использовать бесплатно.

У нас была ситуация, когда мы перевозили одну компанию с Oracle, причём полностью переписывали всю систему и логику — проект был масштабным и дорогостоящим. И даже в этом случае переезд окупался за три года — то есть через это время стоимость лицензий Oracle, от которых компания отказалась, превысила бы стоимость разработки нового проекта. Если говорить о простой миграции, без переписывания всех систем, переезд окупится еще быстрее.

Вынести бизнес-логику наружу. Система Oracle, беспорно, сильная СУБД. В 90-х и 00-х  годах бизнес-логику прописывали прямо на уровне базы данных. Даже сейчас можно встретить такие проекты. Но они сугубо специфичные и рассматриваться в рамках статьи не будут. В наши дни тенденция изменилась, и бизнес-логику стараются реализовывать уже на уровне приложения. Это и понятно, появились технологии масштабируемости: Docker, Kubernetes и так далее. Всё это позволило горизонтально увеличивать ресурсы приложения. 

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

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

Что важно знать об особенностях PostgreSQL

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

С Oracle не так — она платная. Если возникнут какие-то проблемы, их попытаются устранить максимально быстро и могут даже компенсировать потери за сбой или простой. 

По этой причине Oracle ещё активно используют там, где особенно важна надёжность — чаще всего в банковском секторе.

Но не нужно думать, что PostgreSQL не надёжен. Он надёжный. В последних версиях стабильность и надёжность заметно выросла — это можно заметить по тому, что обновления с исправлениями ошибок для новых мажорных версий стали выходить сильно реже.

Более медленная работа. Нельзя сказать, что PostgreSQL сильно медленнее Oracle. Но при любой миграции на postgresql вероятность замедления есть. В основном из-за того, что ранее написанные запросы были оптимальны для Oracle, но не для PostgreSQL. Их придётся отлавливать и переписывать. К этому нужно просто быть готовым.

В каких случаях простой миграции недостаточно

Обычно миграцией называют простой перенос базы данных с Oracle на PostgreSQL «один-в-один». Но иногда стоит более глобальная задача — полностью переписать систему под новую СУБД. Заодно решить несколько попутных задач: улучшить дизайн приложения, поменять стек технологий и так далее.

Как-то раз нам понадобилось настроить миграцию приложения, где поверх Oracle использовали Oracle E-Business Suite. Это приложение, родом прямиком из 90-х — с вырвиглазным интерфейсом и допотопными функциями. Кто работал — знает) Из-за этого нам нельзя было просто подменить базу — пришлось переписывать всю систему. Заодно настроить новую систему интеграции с другими сервисами. 

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

Что нужно для миграции на PostgreSQL с Oracle

Планирование. Чем больше будет учтено тонкостей миграции, тем проще будет осуществлена миграция.

Пример из жизни. Один раз мы мигрировали систему, в которой не было никакой аналитики, с Oracle в PostgreSQL. Даже не были описаны бизнес-сценарии работы. Ох, это было сложно. И больно. Нам показывали старую систему и просили сделать так же в новой системе. Данные мы искали в БД сами =) А потом мигрировали и просили проверить. Хорошо, что была служба поддержки пользователей, она нам здоров помогала в миграции данных. В итоге проект довели до конца. 

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

Администраторы БД с компетенциями в PostgreSQL и Oracle. Важно, чтобы обе компетенции были у одного человека — ведь придётся сначала разбирать функции в Oracle, а потом переносить из PostgreSQL. На небольшой проект хватит одного человека, на более крупный понадобится несколько.

Системный администратор/DevOps. Тот, кто будет строить инфраструктуру серверов. Его компетенции зависят от того, свои у вас серверы или арендованные в облаке.

Разработчики. Они понадобятся,чтобы интегрировать приложение с новой базой или вообще полностью его переписать. У меня был кейс, когда мы брали кусочки модулей, реализовывали их в PostgreSQL на стороне Java и потихоньку делали миграцию данных из одной системы в другую. Параллельно распиливали монолит на микросервисы.

Специалисты по миграции данных. Они нужны, если требуется переносить большие объёмы данных. Их задача — писать миграционные скрипты и следить за перемещением данных.