{"id":14290,"url":"\/distributions\/14290\/click?bit=1&hash=bece6ae8cf715298895ba844b6416416882fe02c5d18dab2837319deacd2c478","title":"\u041a\u043e\u0440\u043f\u043e\u0440\u0430\u0446\u0438\u0438 \u043a\u0430\u043a \u043d\u0438\u043a\u043e\u0433\u0434\u0430 \u0440\u0430\u043d\u044c\u0448\u0435 \u0445\u043e\u0442\u044f\u0442 \u0441\u043e\u0442\u0440\u0443\u0434\u043d\u0438\u0447\u0430\u0442\u044c \u0441 \u043c\u0430\u043b\u044b\u043c \u0431\u0438\u0437\u043d\u0435\u0441\u043e\u043c","buttonText":"","imageUuid":""}

Опыт миграции базы данных с бизнес-логикой из 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. Что ощутимо сказывалась на сроках. Но в целом всё было решаемо.

Процесс миграции процедур, сгруппированный по ETL-пакетам. В основном время уходило на тестирование и отладку найденных проблем в коде

Оптимизация производительности

Для новой базы данных были выделены вычислительные мощности, аналогичные предыдущим. Система функционировала ночью и главный критерий к производительности был — все расчёты должны быть выполнены за ночь.

Сразу после миграции этот срок никак не выполнялся. Чтобы ускорить процесс мы итеративно искали проседающие места. Связаны они были с использованием низко производительных методов в PG, неоптимальными настройками серверов и неправильной настройкой индексов в базе данных. В несколько итераций мы добились срока в два раза лучше допустимого.

У нас был один insert запрос, который до оптимизации выполнялся 16 часов, а после — 30 секунд

Запуск Postgres Pro версии системы в промышленную эксплуатацию

Запуск в промышленную эксплуатацию начали после завершения всех проверок, что с функциональностью и скоростью работы в PG всё нормально. Процесс запуска проходил так:

  • Сначала 2 дня данные переносились в новую БД без остановки работы текущей MS системы.
  • Затем 1 день строили индексы.
  • На ближайших выходных:
  • остановили MS систему, дозалили новые данные, перезапустили аналитические расчеты, переключили взаимосвязи с внешними системами на PG систему.
  • Включили оба инстанса системы:
  • PG версия работает полноценно, с ней работают внешние системы и аналитика. MS версия работает на тех же самых входных данных как эталон.

Первые 3 месяца в 2023 году MS версия системы еще работала в качестве эталона. Когда убедились, что в работе PG нет проблем, MS вывели из эксплуатации.

Итоги

Проект был выполнен за 6 месяцев пятью разработчиками: четверо со стороны «Нетрики» и один — от заказчика. Postgres Pro обладает достаточными возможностями чтобы воссоздать серьёзную промышленную систему с бизнес-логикой и сохранить при этом исходные вычислительные мощности и производительность.

0
5 комментариев
Дягилев Дмитрий

Спасибо за статью, интересный обзор.

Ответить
Развернуть ветку
Алексей Грушин

Лайк только из-за сердитого кота в коробке, знаете как заманить читателей

Ответить
Развернуть ветку
Николай

@Нетрика , а вы сравнивали итоговый performance mssql vs postgresql?

Ответить
Развернуть ветку
Anton Nemtsev

Мы решали задачу заказчика "Все процедуры должны выполняться за ночь с запасом по времени". MS SQL выполнял их за ~3 часа. Мы остановили оптимизацию PostgreSQL на отметке ~4 часа. Именно остановили, так как можно было оптимизировать и дальше, но достигнутый результат более чем приемлем.

Сравнения скорости выполнения отдельных методов не делали - не было на это времени. Просто находили медленные места и исправляли их.

Ответить
Развернуть ветку
Александр А.

Текстуальное:

Postres - опечатка.

"писать с 0" - блин, неужели так кто-то пишет в публичных текстах?

Ответить
Развернуть ветку
2 комментария
Раскрывать всегда