Портфолио, проекты и кейсы Creative

ORM и миграции БД. История трех переездов.

Backend Frontend Mobile app



Осуществление переноса логики приложения и данных из одной БД в другую и на третью.


Срок реализации - 1 неделя


Задача


Перенести содержимое базы данных с одной СУБД на другую. Сохранить корректность работы внутри приложения.


Стэк


MySQL, MSSQL, PostgreSQL


Решения


В процессе разработки web-приложения возникла необходимость осуществлять переезд с одной базы в другую (и не один раз). Но так как наши разработчики для работы с базами данных используют ORM Sequelize, переезд был менее болезненным. ORM предоставляет ряд преимуществ например, отсутствие потребности писать запросы вручную, независимость от диалекта языка и использование встроенных методов, что было удобно для переезда.

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

Последний переезд был на PostgreSQL. Почему? Техническое задание видоизменялось с переходом из отдела в отдел, в соответствии с ростом служебной иерархии. На этапе третьего переезда возникли проблемы не с ORM, а с передачей данных. Проект был в другом сервере, поэтому понадобилось переносить данные, накопившееся за два года, в связи с чем возникла необходимость использования инструментов, помогающих конвертировать данные под форматы новой базы.

Но, основная проблема, все же, была связана с переносом, а точнее отсутствием доступа до боевой БД заказчика (с тестовым всё ОК!). DevОps-разработчики заказчика скопировали не все, но самое главное — не учли генераторы последовательности. В результате, при копировании последнее вставленное значение не сохранилось, а PostgresSQL устроен так, что хранит последнее вставленное значение в базу. В итоге сохранилась информация о том, что последний id, был первым, из-за чего возник “плавающий” баг.

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

Тем не менее, успешно реализовав данный кейс, была изобретена супер- разработка: скрипт, который обрабатывает все таблицы, анализирует последние вставленные id и устанавливает корректные значения для последовательностей.



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

Александр, teamlead frontend компании Creative