Schema Migration — суштина, врсте и алати миграције шема базе података

Шта је Schema Migration

Schema Migration је пракса управљања променама структуре базе података кроз верзионисане датотеке које се секвенцијално примењују на различита окружења. Свака датотека садржи скуп SQL команди: креирање табеле, додавање колоне, промена индекса или ажурирање ограничења. Алат за миграцију прати примењене верзије и гарантује да се свака промена извршава тачно једном.

За разлику од Data Migration, која преноси садржај табела, Schema Migration управља само структуром — DDL операцијама. Ово је фундаментална разлика: Schema Migration ради пре Data Migration, креирајући циљну шему, коју затим Data Migration пуни подацима. Према Redgate (2024), 62% инцидената у продукционим базама података је повезано са ручним променама шеме без миграционих скрипти.

Верзионисање миграција

Свака Schema Migration добија јединствени идентификатор — обично верзију (V1, V2) или временску ознаку. Алат чува у посебној табели (flyway_schema_history, alembic_version) листу примењених миграција. При покретању, упоређује листу са датотекама у classpath-у и примењује само нове. Идемпотентност је кључно својство: поновно покретање не изазива нуспојаве.

Типови промена шеме

Типичне операције Schema Migration: креирање табела (CREATE TABLE), додавање колона (ALTER TABLE ADD COLUMN), мењање типова, креирање индекса, додавање страних кључева и ажурирање секвенци. Сложеније миграције укључују преименовање колона са чувањем података, поделу табеле на више делова и репликацију шеме на шардове.

Зашто је потребна миграција шеме базе података

Без Schema Migration, програмери ручно мењају базу података — пишу DDL у конзоли, додају колоне у dev окружењу и копирају их у staging по сећању. Резултат: неслагање шема између окружења, губитак промена при имплементацији и покварене миграције на продукцији. Schema Migration решава три кључна проблема: конзистентност, поновљивост и ревизију.

Конзистентност између окружења

Када је структура базе података описана у коду, идентична је у dev, staging и production. Програмер не може заборавити да примени промену — алат ће извршити све пропуштене миграције секвенцијално. Ако на продукцији недостаје колона, а код је захтева — апликација ће пасти са грешком. Аутоматска провера елиминише овај сценарио.

Поновљивост за нове програмере

Нови члан тима покреће flyway migrate и добија актуелну шему за неколико секунди — без dump-а из продукције и ручних DDL упита. Ово је посебно важно у микросервисној архитектури, где сваки сервис има своју базу података, а шема се саставља од десетина миграција. Потпуна поновљивост скраћује време укључивања са дана на минуте.

Ревизија промена

Свака Schema Migration се чува у систему контроле верзија заједно са кодом апликације. Може се отворити Pull Request, видети тачне SQL команде промене шеме и извршити code review. При инциденту, лако се утврђује која миграција је последња примењена и ко је њен аутор. Git историја пружа потпуни траг промена базе података током целог трајања пројекта.

Алати за миграцију шема

На тржишту постоје десетине алата Schema Migration за различите језике и платформе. Избор зависи од технолошког стека, формата описа миграција и захтева за враћање. Размотримо главне категорије и популарне алате.

Како одабрати алат

За Java/Kotlin стекове — Flyway као најлакши и најпредвидљивији. За пројекте са честим враћањима — Liquibase, који има уграђени rollback архитектонски. За Python/Django — Alembic као стандардни алат SQLAlchemy. За стартапе без DevOps инжењера — изаберите алат са најмање конфигурације: Flyway захтева само датотеку са скриптом и команду migrate.

Комерцијална решења

Поред open-source алата, постоје комерцијална решења: Redgate SQL Change Automation, Datical DB и DBmaestro. Она пружају визуелно поређење шема, аутоматско решавање конфликата и интеграцију са CI/CD цевоводима. Међутим, за већину пројеката Flyway или Alembic покривају 100% потреба без додатних лиценци.

Миграција са Flyway

Размотримо практични пример Schema Migration у Kotlin са Flyway. Направимо миграцију која додаје табелу orders у PostgreSQL базу података. Flyway аутоматски креира табелу flyway_schema_history и прати примењене верзије.

-- V1__Create_Orders_Table.sql
CREATE TABLE orders (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id         UUID NOT NULL,
    total_amount    DECIMAL(10,2) NOT NULL,
    currency        VARCHAR(3) NOT NULL DEFAULT 'USD',
    status          VARCHAR(20) NOT NULL DEFAULT 'pending',
    created_at     TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    CONSTRAINT fk_user FOREIGN KEY (user_id) REFERENCES users(id)
);

Повезивање Flyway у Kotlin пројекту кроз конфигурацију dataSource. Након конфигурације, команда flyway:migrate ће применити све нове миграције из classpath-а.

// FlywayConfig.kt — Flyway конфигурација у Spring Boot
import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration
import org.flywaydb.core.Flyway

@Configuration
class FlywayConfig {
    @Bean
    fun flyway(dataSource: DataSource): Flyway {
        return Flyway.configure()
            .dataSource(dataSource)
            .locations("classpath:db/migration")
            .baselineOnMigrate(true)
            .load()
    }
}

Alembic за Python пројекте

Alembic је алат Schema Migration за Python, изграђен на SQLAlchemy. Његова кључна карактеристика је аутоматска генерација скрипти на основу поређења SQLAlchemy модела са тренутном шемом базе података. Alembic је погодан за пројекте у Django, FastAPI и Flask.

Иницијализација и креирање миграције

Након иницијализације (alembic init alembic) и конфигурације connection string-а, команда alembic revision --autogenerate скенира SQLAlchemy моделе и генерише скрипт миграције. Програмеру остаје да провери генерисани код и примени га кроз alembic upgrade head. Autogenerate штеди сате ручног писања DDL-а.

# models.py — SQLAlchemy модел за ауто-генерацију
from sqlalchemy import Column, Integer, String, DateTime, Enum
from sqlalchemy.orm import DeclarativeBase
import enum

class OrderStatus(enum.Enum):
    pending = "pending"
    paid = "paid"
    shipped = "shipped"

class Base(DeclarativeBase):
    pass

class Order(Base):
    __tablename__ = "orders"
    id = Column(Integer, primary_key=True)
    status = Column(Enum(OrderStatus), nullable=False)
    created_at = Column(DateTime, nullable=False)

Најбоље праксе миграције шема

Искусни тимови су развили скуп правила Schema Migration која смањују ризик од отказа и поједностављују отклањање грешака. Поштовање ових пракси је знак зреле инжењерске културе. Пет кључних правила покрива пројектовање, тестирање и примену миграција.

Једна миграција — једна промена

Свака Schema Migration треба да уради тачно једну логичку промену: креира табелу, дода колону или промени индекс. Мешање више операција у једној миграцији отежава враћање — ако друга операција падне, прва је већ примењена и мора се враћати засебно. Мали кораци су основа поузданих миграција.

Никада не уређивати објављене миграције

Након што је миграција примењена на продукцији, не може се мењати — може се само креирати нова која исправља проблем. Уређивање објављене миграције квари трацкер: програмери са другом базом података видеће неусаглашеност хеша. Непроменљиве миграције гарантују предвидљиво понашање у свим окружењима.

Тестирање на копији продукције

Пре примене Schema Migration на продукцији, извршите је на копији продукционих података. Циљ је проверити брзину извршења, постојање закључавања табела и исправност промена. За велике табеле ALTER TABLE може блокирати уписивање сатима — тест ће то открити унапред. Staging са продукционим dump-ом је обавезан корак.

Избегавати NOT NULL за нове колоне

Нова колона без подразумеване вредности са NOT NULL — чест узрок неуспеха миграције. У постојећим записима вредност ће бити NULL, а NOT NULL ће изазвати грешку. Најбоља пракса: креирајте колону са подразумеваном вредношћу и nullable, затим засебном миграцијом додајте NOT NULL након попуњавања података.