Опыт миграции базы данных с бизнес-логикой из Microsoft SQL Server в Postgres Pro: ожидания и реальность
Антон Немцев, руководитель направления «Автоматизация» компании «Нетрика» рассказывает про успешный опыт импортозамещения СУБД в рамках ограниченных сроков и бюджета. Какой был план, что пошло не по нему, и как мы с этим справлялись.
После прекращения продаж в РФ крупнейшими зарубежными ИТ-вендорами многие столкнулись с выбором — вписываться в историю импортозамещения или надеяться, что всё само наладится. Наш заказчик — полу-государственная организация, поэтому у него выбора не было.
Задача — воссоздать до конца 2022 года существующую систему на Postgres Pro. Система агрегирует финансовые данные, обрабатывает их и готовит контент для аналитических отчётов и других потребителей. И всё это рассчитывается прямо в базе данных. При переносе архивных данных важно соответствие до последней копейки.
К делу приступили в июле 2022 года.
Обследование
Работы начали с обследования текущей системы в рамках отдельного договора. По его результатам сформулировали техническое задание и оценили стоимость работ. После чего заключили итоговый договор на миграцию.
6 ТБ данных в 341 таблице, где от 20 до 450 колонок и от 20 тысяч до 4 миллиардов строк. Эти данные обрабатываются в 131 процедуре, от 500 до 12 000 строк кода каждая
Конечно же, на этапе обследования мы выявили не все нюансы. В процессе миграции вскрывались скрытые процедуры на 11 000 строк, потребности в полной переписи отдельных функций и другие трудозатратные сюрпризы.
Но были и хорошие новости. Часть процедур оказалась рудиментом и не требовала воссоздания. А ещё мы смогли частично автоматизировать работу разработчиков по переписи исходного кода, что помогло удержаться в рамках бюджета и сроков.
Автоматизация миграции
Уже на старте проекта мы смогли автоматизировать рутинную работу и сфокусироваться на творческих задачах. Разработали 4 скрипта, которые делали следующее:
- Перепись SQL кода из MS в PG с сохранением форматирования и комментариев.
- Миграция SSIS пакетов в Apache Airflow с воссозданием исходных задач.
- Копирование данных из MS в PG.
- Контроль 100% соответствия данных в исходной и мигрированной базах данных, а также автотесты для контроля одинаковых результатов выполнения процедур в MS и PG.
Мы не стали использовать существующие скрипты для миграции. То что нашли, не подходило под наши запросы. Например, не сохраняло форматирование SQL-кода. Проще было написать своё.
Проблемы в процессе миграции
Автоматизация позволила переписать код на аналогичный, но это не означало, что он будет работать в PG. Постоянно возникали проблемы. Вот несколько примеров:
- В исходном MS SQL были скрытые баги. Например, не указан критерий сортировки при запросе select. По умолчанию в PG критерий другой, из-за чего после переноса кода процедура выдает иной результат.
- Длина имен колонок в таблицах и других объектах превышает максимальную допустимую в PG, из-за чего их приходилось переименовывать.
- Для некоторых методов из MS нет прямых аналогов в PG, из-за чего их приходилось писать с 0.
- А некоторые прямые аналоги методов в PG работают иначе, чем в MS, из-за чего их опять же приходилось писать с 0. Например, операции округления и конвертации дробного числа в целое.
Самым болезненным была необходимость исправлять код и в исходной базе MS, и в итоговой PG. Что ощутимо сказывалась на сроках. Но в целом всё было решаемо.
Оптимизация производительности
Для новой базы данных были выделены вычислительные мощности, аналогичные предыдущим. Система функционировала ночью и главный критерий к производительности был — все расчёты должны быть выполнены за ночь.
Сразу после миграции этот срок никак не выполнялся. Чтобы ускорить процесс мы итеративно искали проседающие места. Связаны они были с использованием низко производительных методов в PG, неоптимальными настройками серверов и неправильной настройкой индексов в базе данных. В несколько итераций мы добились срока в два раза лучше допустимого.
У нас был один insert запрос, который до оптимизации выполнялся 16 часов, а после — 30 секунд
Запуск Postgres Pro версии системы в промышленную эксплуатацию
Запуск в промышленную эксплуатацию начали после завершения всех проверок, что с функциональностью и скоростью работы в PG всё нормально. Процесс запуска проходил так:
- Сначала 2 дня данные переносились в новую БД без остановки работы текущей MS системы.
- Затем 1 день строили индексы.
- На ближайших выходных:
- остановили MS систему, дозалили новые данные, перезапустили аналитические расчеты, переключили взаимосвязи с внешними системами на PG систему.
- Включили оба инстанса системы:
- PG версия работает полноценно, с ней работают внешние системы и аналитика. MS версия работает на тех же самых входных данных как эталон.
Первые 3 месяца в 2023 году MS версия системы еще работала в качестве эталона. Когда убедились, что в работе PG нет проблем, MS вывели из эксплуатации.
Итоги
Проект был выполнен за 6 месяцев пятью разработчиками: четверо со стороны «Нетрики» и один — от заказчика. Postgres Pro обладает достаточными возможностями чтобы воссоздать серьёзную промышленную систему с бизнес-логикой и сохранить при этом исходные вычислительные мощности и производительность.
Спасибо за статью, интересный обзор.
Лайк только из-за сердитого кота в коробке, знаете как заманить читателей
@Нетрика , а вы сравнивали итоговый performance mssql vs postgresql?
Мы решали задачу заказчика "Все процедуры должны выполняться за ночь с запасом по времени". MS SQL выполнял их за ~3 часа. Мы остановили оптимизацию PostgreSQL на отметке ~4 часа. Именно остановили, так как можно было оптимизировать и дальше, но достигнутый результат более чем приемлем.
Сравнения скорости выполнения отдельных методов не делали - не было на это времени. Просто находили медленные места и исправляли их.
Текстуальное:
Postres - опечатка.
"писать с 0" - блин, неужели так кто-то пишет в публичных текстах?