Миграция с MSSQL на PostgreSQL: как мы это сделали и какие уроки извлекли

Наш проект долгое время работал на MSSQL, и это нас устраивало. Однако с ростом неопределенности и планами на переезд на российские мощности, мы решили перенести базу данных на более доступный для российских пользователей продукт. В этом посте мы расскажем, как прошла наша миграция, с какими трудностями мы столкнулись и какие уроки извлекли. Если вы планируете подобный переход, надеемся, наш опыт будет вам полезен.

Мы остановились на PostgreSQL потому что наша команда имеет богатый опыт работы с ним. Помимо этого он предлагает open-source лицензию, отличную производительность, богатый набор функций и активное сообщество.

Как выглядел проект

Проект реализован как .NET приложения с использованием ADO.NET framework, который в свою очередь вызвал хранимые процедуры. Все запросы к базе данных были реализованы через хранимые процедуры.

• 20+ микросервисов.
• Покрытие тестами ключевого функционала, примерно 75% кода.
• Базовый класс работы с данными

Этапы миграции

Анализ и планирование

Мы начали с анализа структуры базы данных, запросов и зависимостей. Поскольку решение было переносить все "как есть" (lift and shift), без оптимизаций, нам важно было понять, какие функции MSSQL мы используем и как их заменить в PostgreSQL.

- Скрипты и миграция схемы: Мы написали скрипты для автоматической конвертации схемы базы данных.

- Хранимые процедуры и функции: Эта часть потребовала значительных усилий из-за различий в синтаксисе T-SQL (MSSQL) и PL/pgSQL (PostgreSQL).

- Названия процедур и переменные: В данном вопросе оба продукта сильно разнятся, перенос "как есть" и заключался в том что бы максимально сохранить последовательность названий, тем самым минимизировать время на рефакторинг.

- Порядок развертывания обновленных сервисов: Критически важные и интенсивно работающие с базой данных сервисы должны быть развернуты первыми, что бы обеспечить минимальный downtime.

Миграция базового класса

Микросервисы реализованы с использованием многоуровневой архитектуры, мы довольно быстро переписали базовый класс для работы с PostgreSQL.

Перенос данных

Мы написали свой скрипт переноса данных из MSSQL и импорта в PostgreSQL, так как нашли этот способ менее затратным с точки зрения времени.

• Проблемные типы данных: Некоторые типы данных в MSSQL (например, DATETIME, NVARCHAR) требовали дополнительных усилий.
• Индексы и constraints: Их пришлось пересоздавать вручную после переноса данных.

Тестирование

• Unit и интеграционное тестирование: Перенос каждого микросервиса сопровождался автоматическим тестированием, тем самым возникшие проблемы решались на ранней стадии.
• Нагрузочное тестирование: Мы провели симуляцию нагрузки на базу данных, сравнимую с продакшеном, чтобы оценить производительность PostgreSQL после миграции. Тесты включали типичные запросы, параллельные соединения и интенсивные операции чтения/записи. По результатам анализа мы скорректировали индексы и оптимизировали некоторые запросы для улучшения скорости обработки."
• E2E тестирование: После переноса все было протестировано в "Дев" среде.
• Учения: Провели несколько симуляций развертки в "Дев" среде, чтобы минимизировать риски.

Финальный переход

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

Отключение MSSQL

После успешного тестирования мы отключили MSSQL базу данных, сделали бэкапы и свернули Azure SQL сервисы.

Уроки и выводы

1. Планируйте заранее    Миграция — это долгий процесс, который требует тщательного планирования. Убедитесь, что у вас есть достаточно времени и ресурсов.

2. Автоматическое тестирование необходимо    Если у вас нет хорошего покрытия кода тестами - даже не начинайте. Ошибки, которые можно найти на ранних этапах, обойдутся дешевле, чем проблемы в production. В нашем случае, несмотря на то на то что мы имели не плохой охват тестами, все равно некоторые проблемы были найдены только на этапе E2E тестирования.

3. Обратите внимание на различия в синтаксисе и функциях    MSSQL и PostgreSQL имеют разные подходы к реализации некоторых функций (например, оконные функции, работа со строками). Будьте готовы к переписыванию части кода.

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

5. Не забывайте про команду    Миграция — это не только техническая задача, но и организационная. Убедитесь, что ваша команда готова к изменениям и имеет опыт работы с продуктом. Не все хорошо воспринимают обучение по 'бразильской' системе, когда новый инструмент осваивается на практике, без четких инструкций. Если в команде есть специалисты, которым важно пошаговое руководство, стоит заранее подготовить обучающие материалы.

6. Документируйте всё    Каждый шаг, каждое решение и каждая проблема должны быть задокументированы. Это поможет в будущем, если что-то пойдет не так.

Итоги

Миграция с MSSQL на PostgreSQL заняла у нас 2 месяца, но результат того стоил. Мы получили базу данных которая может работать на любых мощностях без vendor lock-in. Если вы планируете подобный переход, надеюсь, наш опыт будет вам полезен.

А если у вас есть вопросы или вы хотите поделиться своим опытом, пишите нам! Будем рады обсудить. 😊