Migracije baze podataka mjesto su gdje se dizajn aplikacije susreće s realnošću produkcije. Promjena sheme može izgledati bezazleno u zahtjevu za povlačenje, a ipak postati razlog zbog kojeg se implementacija zaustavi, API vraća pogreške ili zauzeta baza podataka provede minute držeći zaključavanje. Razlika je rijetko u samom alatu za migracije. Ona je u disciplini koja se koristi za dizajniranje, redoslijed, testiranje i implementaciju promjena.

Za skalabilan pozadinski sustav, migracije treba tretirati kao verzionirani operativni kôd. One definiraju kako se trajno stanje razvija kroz okruženja te moraju funkcionirati za praznu bazu podataka, dugotrajnu produkcijsku bazu podataka i implementaciju u kojoj se stare i nove verzije aplikacije nakratko izvršavaju usporedno.

Promatrajte shemu kao javni ugovor

Timovi za pozadinski sustav često primjenjuju razmišljanje o kompatibilnosti na API-je, ali zaboravljaju ga primijeniti na sheme baza podataka. Stupac tablice, indeks, ograničenje ili vrijednost nalik enumu mogu koristiti više verzija aplikacije, pozadinski radnici, izvještaji, integracije i operativne skripte.

Zbog toga su destruktivne promjene osobito rizične. Uklanjanje stupca odmah nakon promjene aplikacijskog kôda pretpostavlja da ga je svaki korisnik već prestao koristiti. U distribuiranom sustavu ta je pretpostavka često pogrešna.

Sigurniji pristup je obrazac proširenja i sužavanja:

1. Dodajte novu strukturu sheme bez uklanjanja stare.
2. Implementirajte aplikacijski kôd koji prema potrebi može čitati ili zapisivati oba oblika.
3. Dopunite postojeće podatke u kontroliranim serijama.
4. Prebacite čitanja i zapise na novu strukturu.
5. Provjerite da se stara struktura više ne koristi.
6. Uklonite staru strukturu u kasnijoj migraciji.

Na primjer, promjena jednog korisničkog polja full_name u first_name i last_name nije jedna atomska odluka o proizvodu. To je nekoliko kompatibilnih promjena baze podataka i aplikacije. Razdvajanje tih promjena održava implementaciju reverzibilnom na razini aplikacije i smanjuje mogućnost djelomično migriranih podataka.

Učinite svaku migraciju determinističkom

Migracija bi trebala proizvesti isto predviđeno stanje sheme svaki put kada se primijeni na podržanu početnu točku. To znači izbjegavanje ručnih izmjena samo u produkciji, nedokumentiranih koraka postavljanja i migracija koje ovise o postojanju podataka u određenom obliku, a da to ne provjere.

Koristite konvenciju imenovanja koja prenosi redoslijed i namjeru. Naziv datoteke poput 20261102_add_order_status_index korisniji je od update_orders. Cilj nije estetika; cilj je učiniti povijest implementacije razumljivom kada se incident dogodi mjesecima kasnije.

Neka migracije budu male i usmjerene. Migraciju koja stvara tablice, transformira milijune redaka, ponovno gradi indekse i mijenja dozvole može biti teško pregledati i gotovo nemoguće čisto oporaviti nakon nje. Kad god je moguće, odvojite promjene sheme od opsežnog premještanja podataka.

Namjerno dizajnirajte ograničenja

Ograničenja su vrijedna jer štite podatke neovisno o aplikacijskom kôdu. Strani ključ, pravilo jedinstvenosti ili zahtjev da vrijednost ne smije biti null mogu spriječiti vrste pogrešaka koje sama provjera u aplikaciji ne može pouzdano zaustaviti.

No ograničenja također zahtijevaju operativno planiranje. Dodavanje ograničenja jedinstvenosti postojećim podacima neće uspjeti ako duplikati već postoje. Prije nego što shemu učinite strožom, identificirajte neispravne zapise, odlučite kako ih treba riješiti i osigurajte da novi zapisi tijekom čišćenja ne mogu stvoriti dodatne neispravne podatke.

ALTER TABLE orders
  ADD COLUMN external_reference VARCHAR(128);

CREATE UNIQUE INDEX orders_external_reference_unique
  ON orders (external_reference);

Ovaj je primjer namjerno nepotpun kao produkcijsko uvođenje. Prije stvaranja jedinstvenog indeksa, tim mora odlučiti je li NULL dopušten, trebaju li sve postojeće narudžbe imati vrijednosti i kako treba postupati s duplikatima. SQL sintaksa je lakši dio; podatkovni ugovor je pravi posao.

Odvojite rad na shemi od dopuna podataka

Opsežne dopune podataka čest su izvor poteškoća pri migracijama. Jedna transakcija koja ažurira veliku tablicu može potrošiti značajne resurse, generirati opsežnu aktivnost zapisivanja i ometati uobičajeni promet. Također može premašiti vremenska ograničenja implementacije.

Umjesto toga, najprije dodajte novi stupac, a zatim pokrenite proces dopune koji se može nastaviti u serijama. Proces bi trebao biti idempotentan: ponovno pokretanje serije ne bi smjelo oštetiti već obrađene retke. Također bi trebao izvještavati o napretku i podnositi prekide jer implementacije i radnici mogu zakazati.

Praktična strategija rada u serijama jest odabrati ograničen skup zapisa koji još trebaju obradu, ažurirati ih i ponoviti postupak. Izbjegavajte oslanjanje na nestabilni pomak kroz skup podataka koji se mijenja. Trajni kursor primarnog ključa ili izričit mehanizam stanja migracije obično je lakše nastaviti i razumjeti.

Nakon dovršetka dopune, provedite konačno ograničenje tek kada aplikacija dosljedno zapisuje valjane vrijednosti. Taj redoslijed sprječava da novo ograničenje prekine rad starijih instanci aplikacije tijekom postupne implementacije.

Razumijte zaključavanja, transakcije i prozore implementacije

Ne ponašaju se sve operacije baze podataka jednako. Neke promjene sheme brza su ažuriranja metapodataka; druge mogu skenirati tablice, ponovno graditi indekse ili steći zaključavanja koja blokiraju čitanja ili zapise. Podrška za transakcijski DDL također se razlikuje prema pokretaču baze podataka i operaciji. Proces migracije ne smije pretpostaviti da će se svaka neuspjela promjena sheme automatski vratiti.

Prije implementacije potencijalno skupe promjene, testirajte je na realističnoj kopiji ili reprezentativnom opsegu podataka. Izmjerite proteklo vrijeme, pregledajte ponašanje zaključavanja i potvrdite podržava li odabrana baza podataka metodu manjeg utjecaja za tu operaciju. Ako se operacija ne može sigurno uklopiti u uobičajene uvjete implementacije, zakažite je kao izričitu operativnu promjenu umjesto da je skrivate unutar rutinskog izdanja.

U kontejneriziranim okruženjima pokrećite migracije kao kontrolirani korak implementacije umjesto da svakom aplikacijskom kontejneru dopustite utrku pri pokretanju. Istodobni pokušaji migracije mogu stvoriti izbježive kvarove, osobito kada se više replika pokrene odjednom. Jedan određeni posao ili proces izdanja trebao bi primjenjivati migracije; instance aplikacije trebale bi se pokrenuti tek nakon što potrebna verzija sheme postane dostupna.

Vraćanje unatrag nije uvijek pravi plan oporavka

Timovi često pitaju ima li svaka migracija silaznu migraciju. Iskren odgovor jest da neke promjene nisu sigurno reverzibilne. Nakon što su podaci transformirani, izbrisani ili zapisani u novom formatu, vraćanje sheme možda neće obnoviti prethodno stanje.

Snažnija strategija jest popravak unaprijed: najprije napravite aditivne promjene, zadržite stare strukture tijekom razdoblja kompatibilnosti i po potrebi pripremite korektivnu migraciju. Sigurnosne kopije i dalje su ključne, ali one su mehanizam oporavka od katastrofe, a ne zamjena za pažljivo dizajniranje migracija.

Za destruktivne operacije budite izričiti. Potvrdite da su podaci arhivirani ili namjerno potrošni, provjerite da nijedna podržana verzija aplikacije ne čita ciljnu strukturu te osigurajte da su ovisni poslovi i integracije krenuli dalje.

Ugradite migracije u inženjerski tijek rada

Pouzdana praksa migracija uglavnom je pouzdana praksa pregleda. Datoteke migracija tretirajte s jednakom ozbiljnošću kao autentifikacijski kôd ili promjene javnog API-ja. Pregledavatelji bi trebali postavljati praktična pitanja:

• Mogu li stare i nove verzije aplikacije sigurno raditi tijekom implementacije?
• Zaključava li promjena veliku ili intenzivno korištenu tablicu?
• Je li potrebna dopuna podataka i može li se nastaviti nakon neuspjeha?
• Jesu li ograničenja valjana za postojeće zapise?
• Što se događa ako implementacija stane nakon ove migracije?
• Je li promjena vidljiva putem zapisa, metrika ili pregleda baze podataka?

Pokrećite migracije u kontinuiranoj integraciji na praznoj bazi podataka i, gdje je praktično, na bazi podataka nadograđenoj s ranije verzije sheme. Prvo potvrđuje početno postavljanje. Drugo potvrđuje put kojim stvarni produkcijski sustavi zaista prolaze.

Evolucija sheme proizvod je strpljenja

Arhitektura skalabilnog pozadinskog sustava nije samo odabir brze baze podataka ili dodavanje više instanci aplikacije. Riječ je o mijenjanju sustava bez pretvaranja svake promjene u kockanje. Dobre migracije su postupne, kompatibilne, vidljive i namjerno dosadne.

Kada se promjene sheme dizajniraju kao niz, a ne kao pojedinačni događaj, implementacije postaju mirnije, a oporavak lakše upravljiv. To je stvarna vrijednost zrele prakse migracija: omogućuje bazi podataka da se razvija istim tempom kao proizvod, a da ne postane dio kojeg se svi boje dotaknuti.