Привет, Хабр! Меня зовут Иван Чувашов, я сертифицированный администратор PostgreSQL с 13-летним опытом работы с БД и спикер курса по PostgreSQL в Слёрме. Хочу поговорить на весьма актуальную в последнее время тему — о миграции на PostgreSQL с Oracle. Расскажу, зачем вообще тратить время и деньги на миграцию, какие для этого понадобятся компетенции, какие есть варианты миграции, как этот процесс можно организовать и избежать типичных ошибок.
Зачем переходить с 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. Но при любой миграции вероятность замедления есть. В основном из-за того, что ранее написанные запросы были оптимальны для Oracle, но не для PostgreSQL. Их придётся отлавливать и переписывать. К этому нужно просто быть готовым.
В каких случаях простой миграции недостаточно
Обычно миграцией называют простой перенос базы данных с Oracle на PostgreSQL «один-в-один». Но иногда стоит более глобальная задача — полностью переписать систему под новую СУБД. Заодно решить несколько попутных задач: улучшить дизайн приложения, поменять стек технологий и так далее.
Как-то раз нам понадобилось настроить миграцию приложения, где поверх Oracle использовали Oracle E-Business Suite. Это приложение, родом прямиком из 90-х — с вырвиглазным интерфейсом и допотопными функциями. Кто работал — знает) Из-за этого нам нельзя было просто подменить базу — пришлось переписывать всю систему. Заодно настроить новую систему интеграции с другими сервисами.
Вообще таких кейсов, когда необходимо переписывать все, может быть много. Например, чтобы раздербанить монолит на микросервисы или решить другие архитектурные задачи. Миграция с Oracle как раз удобный момент, чтобы сделать всё это разом и сразу построить новую систему, оптимальную для работы с PostgreSQL.
Что нужно для миграции на PostgreSQL с Oracle
Планирование. Чем больше будет учтено тонкостей миграции, тем проще будет осуществлена миграция.
Пример из жизни. Один раз мы мигрировали систему, в которой не было никакой аналитики, с Oracle в PostgreSQL. Даже не были описаны бизнес-сценарии работы. Ох, это было сложно. И больно. Нам показывали старую систему и просили сделать так же в новой системе. Данные мы искали в БД сами =) А потом мигрировали и просили проверить. Хорошо, что была служба поддержки пользователей, она нам здоров помогала в миграции данных. В итоге проект довели до конца.
Очень много терпения. Процесс перехода обычно длительный и затратный, нужно зарываться в тонны кода и переписывать множество функций.
Администраторы БД с компетенциями в PostgreSQL и Oracle. Важно, чтобы обе компетенции были у одного человека — ведь придётся сначала разбирать функции в Oracle, а потом переносить из PostgreSQL. На небольшой проект хватит одного человека, на более крупный понадобится несколько.
Системный администратор/DevOps. Тот, кто будет строить инфраструктуру серверов. Его компетенции зависят от того, свои у вас серверы или арендованные в облаке.
Разработчики. Они понадобятся,чтобы интегрировать приложение с новой базой или вообще полностью его переписать. У меня был кейс, когда мы брали кусочки модулей, реализовывали их в PostgreSQL на стороне Java и потихоньку делали миграцию данных из одной системы в другую. Параллельно распиливали монолит на микросервисы.
Специалисты по миграции данных. Они нужны, если требуется переносить большие объёмы данных. Их задача — писать миграционные скрипты и следить за перемещением данных.
Два пути миграции
Мы разобрались, зачем вообще мигрировать и что для этого понадобится. Прежде чем переходить к пошаговому плану, посмотрим, какие есть способы миграции. Крайних варианта два:
Реализовать ту же логику на PostgreSQL. База Oracle остаётся, приложение не трогаем, ну или почти не трогаем (со стороны приложения придётся менять запросы к новой БД), и параллельно реализуем все нужное на PostgreSQL. Здесь важно перенести внутренний функционал из Oracle в PostgreSQL и покрыть его тестами для верификации результатов в обеих системах.
Этот способ сложный для DBA, зато позволяет переехать быстрее и требует меньших трудозатрат. После полной миграции мы прогоняем нагрузочные тесты в обоих приложениях и сравниваем результаты. Тюним конфигурацию и, если нужно, запросы в PostgreSQL. Далее отказываемся от Oracle и начинаем работать уже в PostgreSQL. Этот путь для систем с небольшой внутренней бизнес-логикой внутри Oracle.
Почему тесты — это важно. Был у меня такой интересный опыт, когда заказчик попросил переписать внутреннюю бизнес-логику Oracle на PostgreSQL. Доступ к самой системе и продовским данным не предоставил (все наши просьбы игнорировал). И мне пришлось самому придумывать тесты для Oracle и PostgreSQL и сравнивать результаты между собой. Это напоминало ситуацию «подгонка под ответ». С горем пополам нам удалось сдать проект. Дальнейшую историю жизни этого проекта я не знаю.
Выпилить всю логику из Oracle. Это вторая крайность. При таком подходе мы максимально переносим логику в приложение, привлекая разработчиков для переписывания кода. В итоге у нас в Oracle остаётся только база данных, которую мы затем заменяем на PostgreSQL, переливая данные из одной СУБД в другую. Это гораздо дольше, но прозрачнее в плане работы с системой.
Обычно для миграции выбирают какой-то промежуточный путь, то есть важные бизнес-процессы переносят в приложение, а простые несложные процедуры оставляют в Oracle, чтобы потом перенести в PostgreSQL в том же функционале.
Этапы миграции
Теперь разберём по шагам, как происходит миграция. Мы будем рассматривать как раз средний вариант, когда часть бизнес-логики остаётся на стороне БД, но часть выносится в приложение.
1. Подготовка. Один из самых важных и скучных этапов, который потребует много времени. Здесь нужно оценить, какие у вас в распоряжении есть ресурсы, хватает ли компетентных специалистов и серверных мощностей. А также проанализировать объём бизнес-логики реализованной на стороне Oracle, насколько она актуальна и востребована. Например, оценить, нет ли там давно неиспользуемых функций, которые остались из прошлого и не нуждаются в переносе.
Иногда подготовка нужна особенно серьёзная. Например, я знаю ситуацию, когда в PostgreSQL нужно было перенести большой объем данных за короткое время. Это объёмная задача, и вышеописанные методы там не работают. Простая миграция данных заняла бы несколько суток, а регламентное окно у нас было несколько часов. Поэтому мы заранее поделили данные на слои по приоритетам (горячие, теплые и холодные данные) и переливали их поэтапно, написав мигратор. Всё это необходимо было запланировать ещё на стадии подготовки.
2. Создание тестовой базы PostgreSQL. Нужно создать базу и перенести туда структуру и данные. Можно воспользоваться утилитой ora2pg, она не только мигрирует данные, но и может конвертировать процедуры и функции на язык PL/pgSQL, что на первом этапе очень удобно.
3. Валидация бизнес-логики. Создаем unit-тесты для покрытия важной бизнес-логики как в Oracle, так и в PostgreSQL. Это понадобится для проверки правильной работы функционала. Например, для создание тестов в Oracle можно воспользоваться SQL Developer, а для PostgreSQL — pgTAP. Можно этого не делать, если у вас приложение достаточно плотно покрыто unit-тестами.
4. Миграция процедур. Сначала процедуры можно переписать один в один, например, воспользовавшись утилитой ora2pg. Но потом лучше всё-таки переписать процедуры уже полноценно, учитывая особенности PostgreSQL.
5. Работа в тестовом режиме. Конечно, любые глобальные переделки должны прогоняться на тестовом окружении. Разворачивается PostgreSQL и приложение, данные перегоняются из Oracle, и система на PostgreSQL начинает работать в тестовом режиме. Запускается нагрузочное тестирование и сравнивается среднее время ответов для двух систем. С помощью модификации запросов и конфигурации PostgreSQL достигаются целевые показатели.
6. Переезд в PostgreSQL. Когда всё протестировано и отработано, система выкладывается в продуктовое окружение. Я видел реализацию, когда внутри приложения формировали дополнительный модуль, который отправлял запросы на модификацию данных в обе СУБД, поддерживая в них консистентность данных. Такое подход позволяет гибко управлять переключением нагрузки между двумя СУБД, но требует дополнительных трудозатрат со стороны разработки приложения и дополнительной нагрузки на сервер приложения. При выборе такого подхода трафик можно постепенно переключать на PostgreSQL, а Oracle освобождать от нагрузки.
Другой способ ввода в прод PostgreSQL — это использование микросервисной архитектуры, переключение отдельных зависимых микросервисов с Oracle на PostgreSQL.
Сколько занимает миграция
Сроки сильно зависят от проекта. У меня была задача перегнать 300 Гб из простой хранилки на Oracle, без внутренней логики — это заняло два дня (от установки специального софта до готовой рабочей БД). Правда, потом пришлось еще немного переписывать приложение, чтобы научить его работать с новой базой, но сама миграция прошла максимально быстро.
Самый долгий проект был на два года: нужно было полностью всё переписать, заново переделать интеграционные процессы, создать полностью новую структуру данных. Кстати, перегнать структуру из Oracle в PostgreSQL никакими сторонними инструментами не получилось, в БД было слишком много объектов (около миллиона).
Был опыт перегона базы данных и структуры в ней. Это заняло несколько месяцев, но в проекте не было тестов со стороны Oracle и PostgreSQL, так что пришлось серьёзно повозиться со скриптами и постараться учесть все бизнес-кейсы.
Какие сложности могут возникнуть в процессе миграции
Сложности возникают, когда нет знаний о том, как приложение работает с данными. Перенести сами данные один в один из Oracle в PostgreSQL максимально просто, но если требуется выстраивать другую структуру или архитектуру, уже очень важно понимать, как работает приложение.
У меня был опыт, когда некоторые миграционные процессы приходилось переписывать по несколько раз. Потому что мы писали дополнительные модули и понимали, что в главном модуле всё работает не совсем так, как нужно со стороны приложения.
Плюс есть не совсем сложности, а скорее моменты, к которым нужно быть готовым:
PostgreSQL /= Oracle. Пока еще) Поэтому отдельные функции PostgreSQL могут работать медленнее. Это связано с особенностями архитектуры, и на самом деле критического влияния на бизнес-процессы не имеет.
База из Oracle на 1 Тб в PostgreSQL может весить 1,5–2 Тб, так как здесь не реализовано сжатие.
У Oracle и PostgreSQL есть ряд технических особенностей, но они выплывают уже на этапе проработки/миграции проекта. Это не трудности, а, скорее, задачи, которые нужно решать.
При миграции из Oracle в PostgreSQL не нужно ждать серьёзных улучшений в быстродействии. Все останется так же, а может даже замедлиться. Профит от PostgreSQL не в быстродействии, а в экономии денег и независимости от санкций.
В Слёрме сейчас запускают курс «PostgreSQL: replication, backup and observability». Там я буду учить построению репликаций, работе с резервным копированием и организации мониторинга всей системы. Программу составили на реальных задачах команд эксплуатации, будет много кейсов и практики. Если купите курс до конца мая — получите в подарок бесплатную консультацию со мной, где я отвечу на любые ваши вопросы о PostgreSQL.
