Миграция на PostgreSQL и импортозамещение СУБД
Перенос с MS SQL Server и Oracle на PostgreSQL: оценка объёма работ, миграция схемы, данных и хранимой логики, запуск без остановки бизнеса.
У большинства проектов миграции есть дедлайн, который поставили не ИТ: требования к отечественному программному обеспечению, окончание вендорской поддержки, невозможность продлить лицензии или закрыть уязвимости обновлением. Сроки при этом обычно называют раньше, чем кто-либо оценил объём работ, - и первым делом нужно понять, во что вы ввязываетесь.
Начинаем с оценки, а не с переноса
Обследование существующей системы - отдельный этап с понятным результатом. Мы разбираем, что именно предстоит перенести, и на выходе вы получаете документ, с которым можно идти к руководству за сроком и бюджетом, даже если делать миграцию будет другая команда.
- Инвентаризация: таблицы, объём данных, хранимые процедуры, функции, триггеры, задания
- Что используется реально, а что мертво и переносить это не нужно
- Список несовместимостей: конструкции, которых в PostgreSQL нет или которые ведут себя иначе
- Внешние зависимости: интеграции, отчётность, связанные серверы, приложения
- Оценка трудоёмкости по этапам и выбор сценария перехода
Как проходит миграция
Перенос структуры с учётом различий в типах данных, сортировке и регистрозависимости. Первичная заливка исторических данных и сверка контрольных сумм.
Переписывание процедур, функций и триггеров с T-SQL или PL/SQL на PL/pgSQL. Самая трудоёмкая часть: механический перевод даёт код, который формально работает и неверно считает.
Прогон одних и тех же операций на старой и новой системе, сверка результатов и производительности. Расхождения разбираются поштучно - до перевода нагрузки, а не после.
Параллельная работа систем с синхронизацией данных и постепенным переводом нагрузки либо перенос в окно, если простой допустим. Со сценарием возврата на старую систему.
PostgreSQL из открытых репозиториев, Postgres Pro и российские сборки, в том числе в составе Astra Linux и РЕД ОС - включая закрытый контур без доступа в интернет. Целевую платформу выбираем под ваши требования к сертификации и поддержке, а не по привычке.
После перехода систему нужно эксплуатировать: кластер, бэкапы, мониторинг и настройка под нагрузку - см. администрирование PostgreSQL.
Стоимость
Обследование и оценка объёма - отдельный оплачиваемый этап, стоимость зависит от размера системы; на выходе документ с трудоёмкостью по этапам. Сама миграция считается сметой после обследования: назвать цену переноса, не зная, сколько внутри базы живой логики, - значит назвать её наугад. Разовые работы и небольшие переносы - по часам, 4 200 или 6 500 ₽/час. Оплата по этапам, с правом остановиться после любого из них.
Частые вопросы
Сколько занимает миграция на PostgreSQL?
Зависит не от объёма данных, а от количества логики внутри базы. Небольшая система с тонким слоем хранимых процедур переносится за недели. База с тысячами процедур, триггеров и заданий, накопленных за пятнадцать лет, - это месяцы, и основное время уходит не на перенос данных, а на переписывание и проверку логики.
Что переносится тяжелее всего?
Хранимая логика на T-SQL или PL/SQL, специфичные функции работы с датами и строками, иерархические запросы, оконные конструкции с вендорскими расширениями, задания планировщика, связанные серверы и внешние интеграции. Отдельная тема - код приложения, который писался в расчёте на поведение конкретной СУБД: порядок сортировки, регистрозависимость, поведение при пустых значениях.
Автоматические конвертеры справятся?
Они переносят структуру таблиц и простой код - это экономит время на механической части. Но конвертер не знает, какие процедуры используются, а какие мертвы уже пять лет, и не отвечает за то, что цифры в отчётах после переноса совпадут. Проверка результата и разбор несовпадений - основная часть работы, и она ручная.
Можно ли перейти без остановки работы?
Обычно да, через параллельную работу систем: данные синхронизируются в PostgreSQL, часть нагрузки переводится постепенно, старая система остаётся доступной как запасной вариант. Это дороже и дольше, чем перенос в выходные, но снимает риск остановки бизнеса. Выбор между двумя вариантами делается по цене простоя.
Точно ли нужно мигрировать?
Не всегда. Если регуляторных требований нет, система стабильна и рисков от отсутствия вендорской поддержки вы не видите - разумно остаться и вложиться в сопровождение. Мы скажем об этом прямо: миграция ради миграции стоит денег и приносит новые проблемы взамен старых.
Кто будет сопровождать PostgreSQL после перехода?
Это нужно решить до старта, а не после. Опыт эксплуатации MS SQL не переносится на PostgreSQL автоматически: другая модель версионности строк, другая работа с памятью, autovacuum, репликация и кластеризация устроены иначе. Мы обучаем вашу команду по ходу проекта либо берём базы на абонентское обслуживание.
Расскажите о задаче - мы предложим подходящий формат.