Käesoleva artikli eesmärk on näidata raamatukogu näitel schema-keeper tööriistu, mis suudavad oluliselt lihtsustada andmebaaside arendamise protsessi PHP-projektides, mis kasutavad andmebaasisüsteemi PostgreSQL.

Selle artikli teave on eelkõige kasulik arendajatele, kes soovivad maksimaalselt ära kasutada PostgreSQL-i võimalusi, kuid seisavad silmitsi probleemidega, mis on seotud ettevõtte loogika säilitamisega andmebaasis.

Artikkel ei käsitle ettevõtte loogika säilitamise eeliseid ega puudusi andmebaasis. Eeldatakse, et lugeja on juba valiku teinud.

Käesolevas tööks uuritakse järgmisi teemasid:

1. Millises vormis hoida andmebaasi struktuuri dump versioonihaldussüsteemis (edaspidi - VCS)
2. Kuidas jälgida andmebaasi struktuuri muudatusi pärast dumpi salvestamist
3. Kuidas edastada andmebaasi struktuuri muudatusi teistesse keskkondadesse ilma konfliktide ja hiiglaslike migratsioonifailideta
4. Kuidas korraldada mitme arendaja paralleelset tööd projekti kallal
5. Kuidas turvaliselt juurutada suurem hulk muudatusi andmebaasi struktuuris tootmiskeskkonnas
   

   SchemaKeeper on kohandatud salvestatud protseduuridega, mis on kirjutatud keeles PL/pgSQL. Testimist teiste keeltes ei ole tehtud, seega võib kasutamine olla vähem tõhus või võimatu.

Millises vormis hoida andmebaasi struktuuri dump VCS-is

Raamatukogu schema-keeper pakub funktsiooni saveDump, mis salvestab andmebaasi kõigi objektide struktuuri eraldi tekstifailidena. Väljundina luuakse kataloog, mis sisaldab andmebaasi struktuuri eraldatud failides, mis on hõlpsasti lisatav VCS-i.

Vaatleme andmebaasi objektide teisendamist failideks mitme näite abil:

Objekti tüüp
Schema
Nimi
Faili suhteline tee

Tabel
public
accounts
./public/tables/accounts.txt

Salvestatud protseduur
public
auth(hash bigint)
./public/functions/auth(int8).sql

Vaade
booking
tariffs
./booking/views/tariffs.txt

Failide sisu on konkreetse andmebaasi objekti struktuuri tekstiline esitus. Näiteks salvestatud protseduuride korral on faili sisuks salvestatud protseduuri täielik määratlemine, mis algab plokist CREATE OR REPLACE FUNCTION.

Nagu on näha ülaltoodud tabelist, hoiab faili tee endas teavet objekti tüübi, skeemi ja nime kohta. Selline lähenemine lihtsustab dumpis navigeerimist ja andmebaasi muudatuste ülevaatamist.

Laien .sql näidatud, et IDE-de automaatselt pakkuda tööriistu andmebaasiga suhtlemiseks, kui fail on avatud.

Kuidas jälgida andmebaasi struktuuri muudatusi pärast dumpi salvestamist

Salvestades hetke andmebaasi struktuuri dump VCS-i, saame kontrollida, kas andmebaasi struktuuri on pärast dumpi loomist muudetud. Raamatukogus schema-keeper muutuste tuvastamiseks andmebaasi struktuuris on ette nähtud funktsioon verifyDump, mis tagastab teabe erinevuste kohta ilma kõrvaltoimeteta.

Alternatiivne kontrollimeetod on funktsiooni uuesti kutsumine saveDump, määrates sama kausta ja kontrollides VCS-is muutuste olemasolu. Kuna kõik andmebaasi objektid on salvestatud eraldi failidesse, näitab VCS ainult muudetud objekte.
Selle meetodi peamine miinus on failide ülekirjutamise vajadus, et näha muudatusi.

Kuidas edastada andmebaasi struktuuri muudatusi teistesse keskkondadesse ilma konfliktide ja hiiglaslike migratsioonifailideta

Tänu funktsioonile deployDump saab salvestatud protseduuride algkoodi redigeerida täpselt samamoodi nagu tavalist rakenduse algkoodi. Saame lisada/maha võtta uusi ridu salvestatud protseduuride koodis ja saata muudatused kohe versioonihaldussüsteemi, või luua/kustutada salvestatud protseduure, luues/kustutades vastavaid faile dumpi kaustas.

Näiteks, et luua uus salvestatud protseduur skeemis public on piisav luua uus fail, millel on laiend .sql kaustas public/functions, panna sinna salvestatud protseduuri algkood, sealhulgas plokk CREATE OR REPLACE FUNCTION, ja seejärel kutsuda funktsiooni deployDump. Samuti toimub salvestatud protseduuri muutmine ja kustutamine. Seega satub kood samal ajal nii VCS-i kui ka andmebaasi.

Kui salvestatud protseduuri algkoodis ilmneb viga või erimeelsus faili ja salvestatud protseduuri nimede vahel, siis deployDump ei toimi, kuvades viga. Salvestatud protseduuride erisus dumpi ja praeguse andmebaasi vahel on võimatu kasutada deployDump.

Uue salvestatud protseduuri loomisel ei ole vaja käsitsi sisestada õiget faili nime. Piisab, kui failil on laiend .sql. Pärast kutsumist deployDump kuvab vea tekst õige nime, mida saab faili ümbernimetamiseks kasutada.

deployDump võimaldab funktsiooni parameetreid või tagastatavat tüüpi muuta ilma täiendavate toiminguteta, samas kui klassikalise lähenemise korral oleks pidanud
esmajärjekorras täitma KUSTUTA FUNKTSIOON, ja alles seejärel CREATE OR REPLACE FUNCTION.

Kahjuks on olukordi, kus deployDump ei suudeta muudatusi automaatselt rakendada. Näiteks juhul, kui kustutatakse käivitaja funktsioon, mida kasutab vähemalt üks käivitaja. Sellised olukorrad lahendatakse käsitsi migratsioonifailide abil.

Kui muutuste ülekande eest salvestatud protseduurides vastutab ise schema-keeper, siis teiste struktuurimuudatuste ülekandmiseks tuleb kasutada migratsioonifaile. Näiteks on hea migratsioonidega töötamiseks raamatukogu doctrine/migrations.

Migratsioonid tuleb rakendada enne käivitamist deployDump. See võimaldab teha kõik struktuuri muudatused ja lahendada probleemsed olukorrad, et salvestatud protseduurides tehtud muudatused saaksid hiljem probleemideta edasi kanduda.

Migratsioonide töö kohta on rohkem teavet järgmistes jaotistes.

Kuidas korraldada mitme arendaja paralleelset tööd projekti kallal

On vaja luua DB täieliku initsialiseerimise skript, mida arendaja käivitab oma töömasinas, viies kohaliku DB struktuuri vastavusse VCS-s salvestatud dumpiga. Kõige lihtsam on jagada kohaliku DB initsialiseerimine kolmeks sammuks:

1. Baasskeemi faili importimine, mis kannab nime näiteks base.sql
2. Migratsioonide rakendamine
3. Kutsumine deployDump

base.sql — see on lähtepunkt, mille peale rakendatakse migratsioonid ja täidetakse deployDump, see tähendab base.sql + migratsioonid + deployDump = ajakohane DB struktuur. Sellise faili saab genereerida utiliidiga pg_dump. Kasutatakse base.sql ainult DB algse initsialiseerimise ajal.

Nimetame DB täieliku initsialiseerimise skripti refresh.sh. Tööprotsess võib välja näha järgmine:

1. Arendaja käivitab oma keskkonnas refresh.sh ja saab ajakohase DB struktuuri
2. Arendaja hakkab töötama määratud ülesande kallal, muutes kohaliku DB uue funktsionaalsuse vajadustele vastavaks (ALTER TABLE ... lisa veerg jne)
3. Pärast ülesande täitmist kutsub arendaja välja funktsiooni saveDump, et fikseerida VCS-is DB-s tehtud muudatused
4. Arendaja käivitab uuesti refresh.sh, seejärel verifyDump, mis nüüd näitab muudatuste nimekirja migreerimiseks
5. Arendaja kannab kõik struktuuri muudatused migratsioonifaili, käivitab uuesti refresh.sh ja verifyDump, ja kui migratsioon on korrektselt koostatud, verifyDump näitab, et kohaliku DB ja salvestatud dumpi vahel pole erinevusi.

Ülaltoodud protsess on kooskõlas gitflow põhimõtetega. Iga haru VCS-is sisaldab oma dump'i versiooni ning harude ühendamisel toimub dump'ide liitmine. Enamikul juhtudel ei ole pärast liitmist vaja mingit täiendavat tegevust, kuid kui erinevates harudes on tehtud muudatusi, näiteks samas tabelis, võib konflikt tekkida.

Vaatleme konfliktset olukorda näite abil: on haru develop, millest on harunenud kaks haru: feature1 ja feature2, mis ei ole konfliktis develop, kuid on konfliktis omavahel. Eesmärk on mõlema haru liitmine develop. Selle jaoks soovitatakse esmalt liita üks haru develop, seejärel liita develop jääkharusse, lahendades sealjuures konfliktid jäänud haru osas, pärast mida liita viimane haru develop. Konfliktide lahendamise etapis võib osutuda vajalikuks parandada migratsioonifail viimasel harul, et see vastaks lõppdump'ile, mis sisaldab liitmise tulemusi.

Kuidas turvaliselt juurutada suurem hulk muudatusi andmebaasi struktuuris tootmiskeskkonnas

Tänu VCS-is oleva aktuaalse andmebaasi struktuuri dump'ile on võimalik kontrollida production-andmebaasi täpset vastavust nõutavale struktuurile. See tagab, et kõik arendajate soovitud muudatused on edukalt toodetud andmebaasi viidud.

Kuna DDL PostgreSQL-is on tehinguline, on soovitatav järgida järgmist juurutamise järjekorda, et juhuslike vigade korral oleks võimalik "valutult" teostada ROLLBACK:

1. Alusta tehingut
2. Tehingu raames teosta kõik migratsioonid
3. Samas tehingus teosta deployDump
4. Ilma tehingut lõpetamata teosta verifyDump. Kui vigu ei ole, teosta COMMIT. Kui vigu on, teosta ROLLBACK

Need sammud on piisavalt lihtsad, et neid saaks integreerida olemasolevatesse rakenduste juurutamise lähenemistesse, sealhulgas zero-downtime.

Kokkuvõte

Ülaltoodud meetodite abil on võimalik maksimeerida "PHP + PostgreSQL" projektide jõudlust, ohverdades samal ajal suhteliselt väikese mugavuse arendamisel võrreldes kogu äri loogika rakendamisega rakenduse põhiprogrammis. Veelgi enam, andmete töötlemine PL/pgSQL näeb sageli välja läbipaistvam ja vajab vähem koodi kui sama funktsionaalsus, mis on kirjutatud PHP-s.

Allikas: habr.com