Миграция баз данных: как за 4 месяца переехать с Oracle на PostgreSQL

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

В условиях санкций многие компании ищут альтернативы иностранному ПО, чьи вендоры ушли с российского рынка. К таким аналогам относится PostgreSQL. По данным аналитиков TAdviser, госкомпании стали закупать отечественные СУБД в три раза чаще: если в 2021 году на российские решения приходилось порядка 60 контрактов, в 2022 году их было уже больше 200.

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

Ищем аналог Oracle

В SimbirSoft обратилась госкомпания, которая использовала Oracle. Но в марте 2022 года вендор покинул российский рынок, и с тех пор пользователи СУБД столкнулись с рядом рисков:

• сохранения безопасности данных;
• отсутствия обновлений и техподдержки от вендора.

Именно это подтолкнуло клиента искать аналог, который заменит продукт по функциональности.

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

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

Почему PostgreSQL — оптимальная альтернатива

Проанализировав ситуацию, клиент решил использовать PostgreSQL в качестве альтернативной СУБД. У системы есть ряд неоспоримых преимуществ:

• 1. Открытый исходный код. Большое комьюнити разработчиков выступает в качестве вендора и поддерживает ПО в актуальном состоянии. Это делает решения на его основе достойным вариантом для импортозамещения.
• 2. Общие расходы, как правило, меньше, чем на Oracle (но зависят от кейса).
• 3. Достаточная функциональность, гибкость, масштабируемость.

Именно эти плюсы привлекли внимание клиента к системе. Для заказчика PostgreSQL стала достойной заменой импортному ПО. Нельзя сказать, что процесс переноса оказался простым: мы столкнулись с разными сложностями при подготовке переноса и проверке целостности данных.

Особенности миграции

Мы разделили процесс на несколько этапов, а сама реализация заняла 4 месяца:

• 1. Подготовили миграцию схемы БД.
• 2. Реализовали скрипт переноса данных.
• 3. Внесли правки в код приложения: адаптировали SQL-запросы, изменили настройки подключения к БД.
• 4. Проверили, что новая БД соответствует старой (схема, данные, производительность).
• 5. Запустили систему после небольшого запланированного простоя с новой БД.

Задача проекта — быстро и качественно осуществить перенос данных в новую систему. Огромным плюсом было то, что клиент мог периодически останавливать работу системы в продакшне для переезда БД. Это помогло сократить действия при подготовке и непосредственной миграции данных и тем самым уменьшить риск ошибок в процессе. Мы выполнили задачу значительно быстрее установленных сроков.

«Если переезд должен осуществиться без перерыва в работе системы, это необходимо предусмотреть заранее. Например, осуществлять миграцию с использованием промежуточного инстанса БД, при этом во время перехода отправлять обновления данных в обе БД: выполнить накопившиеся транзакции в PostgreSQL сразу после основного этапа миграции». 

Мария, PHP-разработчик SimbirSoft.

Упрощаем процесс

Однако на процесс подготовки также влияют и другие факторы. Например, различия типов данных и то, как с ними работают СУБД. Типы данных и поведение СУБД при работе с ними различаются. Это, в свою очередь, влияет на время подготовки миграции.

Обычно в таких случаях есть несколько вариантов действий:

• 1. Написать скрипты по миграции самостоятельно, так как переносить большой объем таблиц и данных вручную — нерационально. Это подходит только для небольших частей.
• 2. Использовать готовые инструменты: утилиты, программы.

Мы решили совместить оба варианта: использовали утилиту Ora2Pg, где это было возможно, а часть переноса автоматизировали с помощью самописных скриптов, так как функциональности утилиты не хватало.

Ora2Pg — это инструмент для миграции данных, который автоматизирует создание схемы БД, аналогичной имеющейся на Oracle, и переносит ее на PostgreSQL. Утилита автоматизирует рутинную работу, но не делает 100% необходимых задач по переезду. Однако нам удалось автоматизировать часть процесса, не покрытого функциональностью Ora2Pg, и существенно сэкономить время на проекте.

Сложности с кодом

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

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

Мария, PHP-разработчик SimbirSoft.

На проекте в разное время участвовали от 2 до 5 разработчиков SimbirSoft. Они проделали глобальную работу по исследованию и исправлению устаревшего легаси-кода: исправляли запросы (в основном, мелкие отличия, экранирование, замену специфичных для исходной системы функций и синтаксических конструкций), проверяли, сравнивая результаты и скорость работы с Oracle, иногда оптимизировали запросы, рефакторили устаревший код. В общем, приводили приложение в соответствие с новыми требованиями.

Проверяем систему и целостность данных

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

• скорость;
• достоверность;
• гибкость настройки.

Так как база имела большой объем данных и их полная проверка могла бы занять значительное время, то проверять в продакшене решили только некоторый процент каждой таблицы. Данные в таблицах преобразовывались в более короткие значения (хешировались) и сравнивались между собой.

«При реализации проверки нам также пришлось учитывать различия типов данных и сортировки. Например, тип GUID в Oracle сортируется как строка, а аналогичный в PostgreSQL uuid — как шестнадцатеричное число». 

Мария, PHP-разработчик SimbirSoft.

Тестирование показало, что схемы базы соответствуют исходным, хеши данных совпадают и приложение работает в соответствии с ожиданиями.

Поведем итог: заменит ли PostgreSQL Oracle?

Кейс показал, что во многих случаях PostgreSQL — подходящая альтернатива Oracle. У системы есть как свои особенности, так и важные преимущества — большое комьюнити разработчиков, надежность и уверенность в поддержке ПО — как раз то, из-за чего наш заказчик решил переехать с Oracle. Продукты на основе PostgreSQL (Postgres Pro, Tantor) используют в том числе для импортозамещения в госсекторе в качестве отечественного ПО. Схема и подходы аналогичны тому, что описано в кейсе.

Однако важно помнить, что на процесс миграции влияет сложность БД и степень использования специфических возможностей Oracle. Объем потраченных на переезд ресурсов зависит от многих факторов: объема и качества кода проекта, размера БД, необходимости оптимизации и других моментов. Опытный подрядчик поможет оценить все условия и подобрать подходящие инструменты и верный подход для уменьшения трудностей при переезде.

Все материалы о нашей практике разработки — здесь. Больше кейсов импортозамещения ПО — в нашем портфолио.