Миграции схемы
Тема дорожной карты · Backend разработчик
Миграции баз данных — это версионированные, исполняемые скрипты, применяющие инкрементальные изменения схемы базы данных — добавление таблиц, изменение колонок, создание индексов или заполнение справочных данных — повторяемым, аудируемым способом, синхронизирующим каждое окружение (локальное, staging, продакшен) с текущей моделью данных приложения. Инструменты миграции Flyway (flyway migrate) и Liquibase применяют SQL или XML-ченджсеты в порядке версий и отслеживают применённые миграции в таблице метаданных (flyway_schema_history), тогда как ORM-интегрированные инструменты Alembic (alembic upgrade head) для SQLAlchemy/Python, Entity Framework Core (ef database update) для .NET и Rails Active Record (rails db:migrate) генерируют файлы миграций из изменений моделей. Миграции баз данных должны разрабатываться с учётом обратной совместимости для деплоев без простоя: следуйте паттерну expand-contract — сначала добавьте nullable колонку (expand), разверните новую версию приложения, пишущую и в старую, и в новую колонки, затем удалите старую колонку (contract) в последующей миграции, — чтобы избежать блокировки таблиц при ALTER TABLE на больших PostgreSQL или MySQL наборах данных. Масштабные изменения схемы, например добавление non-nullable колонки в таблицу с сотнями миллионов строк, следует выполнять с помощью pg_repack или pt-online-schema-change, чтобы избежать блокировок ACCESS EXCLUSIVE, блокирующих все чтения и записи на несколько минут. Интеграция миграций баз данных в CI/CD-пайплайны — запуск alembic upgrade head или flyway migrate как шага предварительного деплоя в GitHub Actions или GitLab CI — гарантирует атомарное применение схемы и кода.
Как это работает
Миграции схемы используют ACID-транзакции, декларативный SQL, реляционную схему. PostgreSQL — современный дефолт для новых проектов (богатая типизация, JSON-поддержка, расширения, MVCC); MySQL/MariaDB всё ещё распространён (legacy + WordPress); SQLite — для маленьких single-host (удивительно мощный); CockroachDB / YugabyteDB — для распределённого SQL. Стратегия индексов, план запроса (EXPLAIN), connection pooling — операционные основы. Миграции через Alembic, Flyway, Liquibase или фреймворк-специфичные тулы.
Когда применять
Postgres по умолчанию для любого нового проекта — широкий feature set, зрелая эксплуатация, JSON и full-text встроены. MySQL — только если команда или хостинг уже на нём. SQLite — для embedded или первых 10к юзеров (буквально — масштабируется дальше, чем думают). Distributed SQL (Cockroach, Yugabyte, TiDB) — только когда переросли primary-replica Postgres; эта точка гораздо дальше, чем продают вендоры.
Типичные ошибки
Ловушки Миграции схемы: пропущенные индексы на колонках в WHERE / JOIN (один медленный запрос валит БД); N+1 паттерны от ORM (eager-load явно); долгие транзакции держат локи (делите на меньшие записи); не анализируете план запросов перед деплоем (EXPLAIN ANALYZE); pool соединений мал или велик (начните с max_connections / replica_count, тюньте по наблюдениям).