Миграция Directum RX на СУБД Tantor Postgres в ПАО «АЛРОСА»

Специалисты АЛРОСА, Directum и «СТАРКОВ Групп» (партнер Directum) установили и настроили СУБД Tantor Postgres вместе с графической платформой администрирования и мониторинга, адаптировали запросы, подготовили скрипты миграции, непосредственно организовали миграцию базы с MS SQL на российское решение от «Тантор Лабс», провели тонкую настройку конфигураций, оптимизацию индексов и анализ журналов логирования. Команда «СТАРКОВ Групп» имела обширный и релевантный опыт сотрудничества и хорошо знала особенности работы и функционал систем. Команда вендора привлекалась в рамках анализа метрик производительности на этапе ОПЭ. Со стороны АЛРОСА в проекте участвовали системный инженер, ведущий разработчик, архитектор решения и консультант, курирующий всю активность по тестированию и устранению замечаний в рамках тестирования, а со стороны партнёра - инженер и разработчик.

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

Для миграции данных использовался механизм, который предполагал копирование только данных, а структура и схема БД воссоздавалась сразу на Tantor Postgres. Средствами Directum Launcher была сгенерирована новая чистая БД (генерация структуры данных платформенными скриптами под тип PostgreSQL), далее с учетом всех проектных модификаций воссоздавалась структура БД публикациями прикладной разработки и инициализации.

При адаптации прикладной разработки (доработке SQL-запросов) проектная команда столкнулась с регистрозависимостью колонок таблиц, а также с особенностями типа данных, связанного с датами (date, timestamp). Был проведен ручной рефакторинг: замена типов NVARCHAR на TEXT или VARCHAR, адаптация работы с датами (DATETIME в TIMESTAMP), обработка BIT-полей под логику BOOLEAN. Поскольку PostgreSQL чувствителен к регистру в именах объектов, в ходе рефакторинга скриптов к единому стилю приводились имена объектов (чаще всего к нижнему регистру), а также обеспечивалось корректное использование кавычек.

На тестовой миграции команда ожидаемо получила определенные просадки произодительности, и было принято общее решение отказаться от всех прикладных индексов, созданных ранее для MS SQL и настраивать производительность сразу под новую СУБД. Для ускорения активно использовались отчеты PGProfile и встроенные в Платформу Tantor сервисы профайлинга SQL-запросов. Консультанты активно запускали бизнес-процессы, а технические специалисты ежедневно собирали отчет PGProfile, анализировали тяжелые запросы и создавали новые индексы. Список созданных индексов собирался в общий скрипт, который и был применен после миграции в продуктивную среду. Некоторые запросы Directum RX приходилось адаптировать, избавляясь от конструкций, специфичных для MS SQL, и заменяя их на более производительные под PostgreSQL. В рамках задач по адаптации скриптов и запросов прямых обращений в техподдержку Tantor не требовалось, особенности адаптации SQL-запросов в рабочем порядке решались силами проектной команды. Большинство возникающих вопросов покрывала документация. Далее в течение первой недели ОПЭ оптимизировали производительность.

Продуктивная миграция проходила по заранее разработанному тайминг-плану. Окно было согласовано с бизнес-заказчиком заблаговременно, предполагало длинный выходной. Работы, не влияющие на старт эксплуатации, были запланированы на следующие выходные после запуска. Период после миграции выпадал на перерыв между отчетными периодами (закрытие финансового периода и начисления заработной платы), чтобы при возникновении значительных инцидентов не пострадали бы бизнес-процессы.

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