Schema Migration — BD sxemlərinin miqrasiyasının mahiyyəti, növləri və alətləri

Schema Migration nədir

Schema Migration — verilənlər bazası strukturunun dəyişikliklərinin versiyalaşdırılmış fayllar vasitəsilə idarə edilməsi təcrübəsidir. Bu fayllar müxtəlif mühitlərə ardıcıl olaraq tətbiq edilir. Hər fayl bir sıra SQL əmrləri ehtiva edir: cədvəl yaratma, sütun əlavə etmə, indeks dəyişdirmə və ya məhdudiyyətləri yeniləmə. Miqrasiya aləti tətbiq edilmiş versiyaları izləyir və hər dəyişikliyin dəqiq bir dəfə yerinə yetirilməsini təmin edir.

Məlumatların köçürülməsi ilə məşğul olan Data Migration-dan fərqli olaraq, Schema Migration yalnız struktur — DDL əməliyyatları ilə idarə edir. Bu əsas fərqdir: Schema Migration Data Migration-dan əvvəl işləyir, hədəf sxemi yaradır, sonra isə Data Migration məlumatları yükləyir. Redgate (2024) məlumatına görə, istehsal bazalarında 62% insident miqrasiya skriptləri olmadan əl ilə sxem dəyişiklikləri ilə bağlıdır.

Miqrasiyaların versiyalaşdırılması

Hər Schema Migration unikal identifikator alır — adətən versiya (V1, V2) və ya vaxt möhürü. Alət xüsusi cədvəldə (flyway_schema_history, alembic_version) tətbiq edilmiş miqrasiyaların siyahısını saxlayır. İşə salındıqda siyahını classpath-dəki fayllarla müqayisə edir və yalnız yenilərini tətbiq edir. İdempotentlik — əsas xüsusiyyət: təkrar işə salma yan təsirlərə səbəb olmur.

Sxem dəyişikliklərinin növləri

Tipik Schema Migration əməliyyatları: cədvəl yaratma (CREATE TABLE), sütun əlavə etmə (ALTER TABLE ADD COLUMN), tipləri dəyişmə, indeks yaratma, xarici açarlar əlavə etmə və ardıcıllıqları yeniləmə. Daha mürəkkəb miqrasiyalar məlumatları qoruyaraq sütunların adını dəyişmə, cədvəli bir neçəyə bölmə və sxemi şardlara replikasiya etməni əhatə edir.

BD sxem miqrasiyası nə üçün lazımdır

Schema Migration olmadan tərtibatçılar BD-ni əl ilə dəyişdirir — konsolda DDL yazır, dev mühitində sütunlar əlavə edir və onları yaddaşdan staging-ə köçürür. Nəticə: mühitlər arasında sxem uyğunsuzluğu, yerləşdirmə zamanı dəyişikliklərin itirilməsi və production-da sınıq miqrasiyalar. Schema Migration üç əsas problemi həll edir: ardıcıllıq, təkrarlana bilmə və audit.

Mühitlər arasında ardıcıllıq

BD strukturu kodda təsvir edildikdə, dev, staging və production-da eyni olur. Tərtibatçı dəyişikliyi tətbiq etməyi unuda bilməz — alət bütün buraxılmış miqrasiyaları ardıcıl olaraq yerinə yetirəcək. Əgər production-da sütun yoxdursa, kod isə onu tələb edirsə — proqram xəta ilə çökəcək. Avtomatik yoxlama bu ssenarini aradan qaldırır.

Yeni tərtibatçılar üçün təkrarlana bilmə

Komandanın yeni üzvü flyway migrate əmrini işə salır və bir neçə saniyə ərzində cari sxemi əldə edir — production zərfi və əl ilə DDL sorğuları olmadan. Bu, xüsusilə mikroservis arxitekturasında vacibdir, burada hər xidmətin öz BD-si var və sxem onlarla miqrasiyadan yığılır. Tam təkrarlana bilmə işə başlama müddətini günlərdən dəqiqələrə endirir.

Dəyişikliklərin auditi

Hər Schema Migration proqram kodu ilə birlikdə versiya idarəetmə sistemində saxlanılır. Pull Request açıb, sxem dəyişikliyinin dəqiq SQL əmrlərini görüb code review edə bilərsiniz. İnsident zamanı hansı miqrasiyanın sonuncu tətbiq edildiyini və onun müəllifini asanlıqla müəyyən etmək olar. Git tarixçəsi layihənin bütün müddəti ərzində verilənlər bazası dəyişikliklərinin tam izini verir.

Sxem miqrasiya alətləri

Bazarda müxtəlif dillər və platformalar üçün onlarla Schema Migration aləti mövcuddur. Seçim texnologiya stack-indən, miqrasiya təsvir formatından və geri qaytarma tələblərindən asılıdır. Əsas kateqoriyaları və məşhur alətləri nəzərdən keçirək.

Aləti necə seçmək

Java/Kotlin stack-ləri üçün — Flyway ən yüngül və proqnozlaşdırılan olaraq. Tez-tez geri qaytarma tələb edən layihələr üçün — Liquibase, rollback memari olaraq daxil edilmişdir. Python/Django üçün — Alembic SQLAlchemy-nin standart aləti kimi. DevOps mühəndisi olmayan startaplar üçün — ən az konfiqurasiya tələb edən aləti seçin: Flyway yalnız skript faylı və migrate əmri tələb edir.

Kommersiya həllər

Açıq mənbə alətlərindən əlavə kommersiya həllər də mövcuddur: Redgate SQL Change Automation, Datical DB və DBmaestro. Onlar sxemlərin vizual müqayisəsini, konfliktlərin avtomatik həllini və CI/CD pipeline-ları ilə inteqrasiyanı təmin edir. Lakin əksər layihələr üçün Flyway və ya Alembic əlavə lisenziyalar olmadan 100% ehtiyacları ödəyir.

Flyway ilə miqrasiya

Kotlin ilə Flyway-də Schema Migration-ın praktiki nümunəsini nəzərdən keçirək. PostgreSQL verilənlər bazasına orders cədvəlini əlavə edən bir miqrasiya yaradaq. Flyway avtomatik olaraq flyway_schema_history cədvəlini yaradır və tətbiq edilmiş versiyaları izləyir.

-- 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-in Kotlin layihəsində dataSource konfiqurasiyası vasitəsilə qoşulması. Konfiqurasiyadan sonra flyway:migrate əmri classpath-dəki bütün yeni miqrasiyaları tətbiq edəcək.

// FlywayConfig.kt — Spring Boot-da Flyway konfiqurasiyası
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()
    }
}

Python layihələri üçün Alembic

Alembic — SQLAlchemy üzərində qurulmuş Python üçün Schema Migration alətidir. Onun əsas xüsusiyyəti SQLAlchemy modelinin cari BD sxemi ilə müqayisəsi əsasında skriptlərin avto-generasiyasıdır. Alembic Django, FastAPI və Flask layihələri üçün uyğundur.

İnisializasiya və miqrasiya yaratma

İnisializasiyadan (alembic init alembic) və connection string konfiqurasiyasından sonra alembic revision --autogenerate əmri SQLAlchemy modellərini skan edir və miqrasiya skripti yaradır. Tərtibatçıya yalnız yaradılan kodu yoxlamaq və alembic upgrade head vasitəsilə tətbiq etmək qalır. Autogenerate əl ilə DDL yazmağa sərf olunan saatlara qənaət edir.

# models.py — Avto-generasiya üçün SQLAlchemy modeli
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)

Sxem miqrasiyasının ən yaxşı təcrübələri

Təcrübəli komandalar Schema Migration qaydaları toplusu hazırlayıblar ki, bu da nasazlıq riskini azaldır və sazlamanı asanlaşdırır. Bu təcrübələrə riayət etmək yetkin mühəndislik mədəniyyətinin əlamətidir. Beş əsas qayda miqrasiyaların layihələndirilməsini, sınaqdan keçirilməsini və yerləşdirilməsini əhatə edir.

Bir miqrasiya — bir dəyişiklik

Hər Schema Migration tam olaraq bir məntiqi dəyişiklik etməlidir: cədvəl yaratmaq, sütun əlavə etmək və ya indeksi dəyişmək. Bir neçə əməliyyatı bir miqrasiyada qarışdırmaq geri qaytarmanı çətinləşdirir — əgər ikinci əməliyyat uğursuz olarsa, birinci artıq tətbiq edilib və onu ayrıca geri qaytarmaq lazımdır. Kiçik addımlar etibarlı miqrasiyaların əsasıdır.

Dərc edilmiş miqrasiyaları heç vaxt redaktə etməyin

Miqrasiya production-da tətbiq edildikdən sonra onu dəyişdirmək olmaz — yalnız problemi düzəldən yeni miqrasiya yaratmaq lazımdır. Dərc edilmiş miqrasiyanı redaktə etmək izləyicini pozur: başqa verilənlər bazası olan tərtibatçılar heş uyğunsuzluğu görəcək. Dəyişməz miqrasiyalar bütün mühitlərdə proqnozlaşdırılan davranışı təmin edir.

Production surətində sınaq

Schema Migration-ı production-da tətbiq etməzdən əvvəl onu istehsal məlumatlarının surətində yerinə yetirin. Məqsəd icra sürətini, cədvəl blokadalarının mövcudluğunu və dəyişikliklərin düzgünlüyünü yoxlamaqdır. Böyük cədvəllər üçün ALTER TABLE saatlarla yazmağı bloklaya bilər — test bunu əvvəlcədən aşkar edəcək. Staging istehsal surəti ilə məcburi addımdır.

Yeni sütunlar üçün NOT NULL-dan qaçınmaq

Defolt dəyəri olmayan NOT NULL ilə yeni sütun — miqrasiya uğursuzluğunun tez-tez səbəbidir. Mövcud qeydlərdə dəyər NULL olacaq və NOT NULL xətaya səbəb olacaq. Ən yaxşı təcrübə: sütunu defolt və nullable ilə yaradın, sonra ayrı miqrasiya ilə məlumatlar doldurulduqdan sonra NOT NULL əlavə edin.