Andmeteadus Ja Andmebaasid

Andmebaaside ränne: Röövikute muutmine liblikateks



Kasutajaid ei huvita, mida nende kasutatav tarkvara sisaldab; lihtsalt see töötab tõrgeteta, ohutult ja pealetükkimatult. Arendajad püüavad selle ellu viia ja üks probleemidest, mida nad püüavad lahendada, on see, kuidas tagada, et andmehoidla oleks toote praegusele versioonile vastavas olekus. Tarkvara areneb ja ka selle andmemudel võib aja jooksul muutuda, näiteks parandada kujundusvead . Probleemi veelgi keerulisemaks muutmiseks võib teil olla mitmeid testikeskkondi või kliente, kes migreeruvad toote uuematesse versioonidesse erinevas tempos. Te ei saa lihtsalt dokumenteerida poe struktuuri ja seda, milliseid manipuleerimisi läikiva uue versiooni kasutamiseks ühest vaatenurgast on vaja.

Andmebaaside ränne: Röövikute muutmine liblikateks



Kord liitusin mõne andmebaasiga, mille struktuure värskendati nõudmisel otse arendajate poolt. See tähendas, et struktuuri uusimale versioonile üleminekuks ei olnud ilmset viisi teada saada, milliseid muudatusi tuleb rakendada, ja versioonide kontseptsiooni polnud üldse olemas! See oli DevOpsi eelse ajastu ajal ja seda peetakse tänapäeval täielikuks segaduseks. Otsustasime töötada välja tööriista, mida kasutatakse iga muudatuse rakendamiseks antud andmebaasis. Sellel oli rändeid ja see dokumenteerib skeemi muudatused. See tegi meid kindlaks, et juhuslikke muudatusi ei toimu ja skeemi olek on prognoositav.



Selles artiklis uurime, kuidas relatsiooniandmebaasi skeemide migratsiooni rakendada ja kuidas kaasnevatest probleemidest üle saada.



Esiteks, mis on andmebaaside migreerimised? Selle artikli kontekstis a ränne on muudatuste kogum, mida tuleks andmebaasile rakendada. Tabeli, veeru või indeksi loomine või kukutamine on levinud näited üleviimistest. Teie skeemi kuju võib aja jooksul dramaatiliselt muutuda, eriti kui arendust alustati siis, kui nõuded olid veel ebamäärased. Nii et mitmete verstapostide käigus väljalaskmise ajal on teie andmemudel arenenud ja võib olla muutunud täiesti erinevaks sellest, mis oli alguses. Migratsioonid on vaid sammud sihtriiki.

Alustamiseks uurime, mida oleme oma tööriistakastis sisaldanud, et vältida juba hästi tehtud asja uuesti leiutamist.



Tööriistad

Igas laialdaselt kasutatavas keeles leidub raamatukogusid, mis aitavad andmebaaside migreerumist lihtsustada. Näiteks Java puhul on populaarsed valikud Liquibase ja Lennurada . Näidetes kasutame rohkem Liquibase'i, kuid mõisted kehtivad teiste lahenduste kohta ega ole seotud Liquibase'iga.

Miks peaks vaeva nägema eraldi skeemi migreerimise teegi kasutamisega, kui mõned ORM-id pakuvad juba võimalust skeemi automaatselt täiendada ja vastendada vastendatud klasside struktuuriga? Praktikas muudavad sellised automaatsed migreerimised ainult lihtsaid skeemimuudatusi, näiteks loovad tabeleid ja veerge ning ei saa teha potentsiaalselt hävitavaid asju, näiteks andmebaasiobjektide viskamine või ümbernimetamine. Nii et mitteautomaatsed (kuid siiski automatiseeritud) lahendused on tavaliselt parem valik, sest olete sunnitud ise migreerumisloogikat kirjeldama ja teate, mis täpselt teie andmebaasiga juhtuma hakkab.



Samuti on väga halb mõte segada automatiseeritud ja käsitsi skeemi modifikatsioone, sest võite luua unikaalseid ja ettearvamatuid skeeme, kui käsitsi tehtud muudatusi rakendatakse vales järjekorras või ei rakendata üldse, isegi kui need on vajalikud. Kui tööriist on valitud, kasutage seda kõigi skeemide migreerimiste rakendamiseks.

Tüüpilised andmebaaside migreerimised

Tüüpilised migreerimised hõlmavad järjestuste, tabelite, veergude, põhi- ja võõrvõtmete, indeksite ja muude andmebaasi objektide loomist. Enamasti levinud muudatuste jaoks pakub Liquibase selgeid deklaratiivseid elemente kirjeldamaks, mida tuleks teha. Oleks liiga igav lugeda kõigist tühistest muudatustest, mida Liquibase või muud sarnased tööriistad toetavad. Et saada aimu, kuidas muudatused välja näevad, kaaluge järgmist näidet, kus loome tabeli (XML-i nimeruumi deklaratsioonid jäetakse lühiduse huvides välja):



createTable

Nagu näete, on muudatuste loend muudatuste komplekt ja muudatuste komplektid koosnevad muudatustest. Lihtsad muudatused nagu UPDATE product SET code = 'new_' || code saab keerukamate migratsioonide rakendamiseks kombineerida; nt oletame, et peate kõigi toodete tootekoodi värskendama. Seda saab hõlpsasti saavutada järgmise muudatusega:

createTable

Toimivus halveneb, kui teil on tuhandeid tooteid. Migratsiooni kiirendamiseks võime selle ümber kirjutada järgmisteks toiminguteks:



  1. Looge PRODUCT_TMP -ga toodete jaoks uus tabel, nagu nägime varem. Selles etapis on parem luua võimalikult vähe piiranguid. Nimetagem uus tabel PRODUCT_TMP.
  2. Asustada INSERT INTO ... SELECT ... SQL-iga sql kujul kasutades addNotNullConstraint muutus.
  3. Looge kõik vajalikud piirangud (addUniqueConstraint, addForeignKeyConstraint, createIndex) ja indeksid (PRODUCT).
  4. Nimetage PRODUCT_BAK tabeli sarnane renameTable. Liquibase saab seda teha PRODUCT_TMP abil.
  5. Nimeta ümber PRODUCT kuni renameTable (uuesti kasutades PRODUCT_BAK).
  6. Soovi korral eemaldage dropTable koos ... .

Muidugi on parem selliseid rändeid vältida, kuid on hea teada, kuidas neid rakendada, kui satute mõnda neist harvadest juhtumitest, kus seda vajate.

andmete liiasus vähendab vigade võimalust.

Kui peate XML-i, JSON-i või YAML-i muudatuste kirjeldamise jaoks liiga kummaliseks, siis lihtsalt kasutage tavalist SQL-i ja kasutada kõiki andmebaaside pakkuja spetsiifilisi funktsioone. Samuti saate rakendada mis tahes kohandatud loogika lihtsas Java keeles.



See, kuidas Liquibase vabastab teid tegeliku andmebaasispetsiifilise SQL-i kirjutamisest, võib põhjustada liigset enesekindlust, kuid te ei tohiks unustada oma sihtandmebaasi veidrusi; nt kui loote võõra võtme, võidakse indeks luua või mitte, sõltuvalt konkreetsest kasutatavast andmebaasi haldussüsteemist. Selle tulemusena võite sattuda ebamugavasse olukorda. Liquibase võimaldab teil määrata, et muudatuste komplekti tuleks käivitada ainult teatud tüüpi andmebaaside jaoks, nt PostgreSQL, Oracle või MySQL. See teeb selle võimalikuks, kasutades eri andmebaaside jaoks samu müüja-agnostilisi muutmiskomplekte ja muude muudatuste komplektide puhul tarnijaspetsiifilist süntaksit ja funktsioone. Järgmine muudatuste komplekt täidetakse ainult Oracle'i andmebaasi kasutamisel:

IDX__

Lisaks Oracle'ile toetab Liquibase väheseid muud andmebaasid Karbist välja.

llc s või c corp

Andmebaasi objektide nimetamine

Iga teie loodud andmebaasiobjekt tuleb nimetada. Te ei pea teatavat tüüpi objektidele selgesõnaliselt nime andma, nt piirangute ja indeksite jaoks. Kuid see ei tähenda, et neil objektidel ei oleks nimesid; nende nimed loob andmebaas niikuinii. Probleem tekib siis, kui peate selle objekti viitamiseks selle langetamiseks või muutmiseks viitama. Seega on parem anda neile selged nimed. Kuid kas on mingeid reegleid selle kohta, milliseid nimesid anda? Vastus on lühike: ole järjekindel; nt kui otsustasite indeksid nimetada järgmiselt: CODE, siis ülalnimetatud IDX_PRODUCT_CODE veeru nimi peaks olema DATABASECHANGELOG.

Nimetamiskonventsioonid on uskumatult vastuolulised, seega ei eelda me siin põhjalikke juhiseid. Ole järjekindel, austa oma meeskonna- või projektikonventsioone või mõtle need lihtsalt välja, kui neid pole.

Muutumiskomplektide korraldamine

Kõigepealt tuleb otsustada, kuhu muudatuskomplektid salvestada. Põhimõtteliselt on kaks lähenemist:

  1. Hoidke muutmiskomplektid koos rakenduse koodiga. Seda on mugav teha, sest saate muudatuste ja rakenduskoodi koos siduda ja üle vaadata.
  2. Hoidke muudatuste komplektid ja rakenduse kood eraldi nt eraldi VCS-hoidlates. See lähenemisviis sobib siis, kui andmemudelit jagatakse mitme rakenduse vahel ja mugavam on kõiki muudatuskomplekte salvestada spetsiaalsesse hoidlasse ja mitte hajutada neid mitmesse hoidlasse, kus rakenduse kood elab.

Kõikjal, kuhu muudatused salvestate, on mõistlik jagada need järgmistesse kategooriatesse:

  1. Sõltumatud migreerimised, mis ei mõjuta jooksvat süsteemi. Uute tabelite, jadade jms loomine on tavaliselt ohutu, kui praegu juurutatud rakendus pole neist veel teadlik.
  2. Skeemi muudatused, mis muudavad poe struktuuri , nt veergude ja indeksite lisamine või kukutamine. Neid muudatusi ei tohiks rakendada, kui rakenduse vanemat versiooni veel kasutatakse, kuna see võib skeemi muudatuste tõttu põhjustada lukustusi või imelikku käitumist.
  3. Kiired migreerimised, mis sisestavad või värskendavad väikest hulka andmeid. Kui juurutatakse mitut rakendust, saab selle kategooria muudatuste komplekteerida samaaegselt, ilma et see kahjustaks andmebaasi jõudlust.
  4. Potentsiaalselt aeglane migreerimine, mis sisestab või värskendab palju andmeid. Neid muudatusi on parem rakendada, kui muid sarnaseid migratsioone ei toimu.

nelja kategooria graafiline esitus

Need migreerimiskomplektid tuleks enne rakenduse uuema versiooni juurutamist järjest käivitada. See lähenemine muutub veelgi praktilisemaks, kui süsteem koosneb mitmest eraldi rakendusest ja mõned neist kasutavad sama andmebaasi. Vastasel juhul tasub eraldada ainult need muutmiskomplektid, mida saab rakendada töötavaid rakendusi mõjutamata, ja ülejäänud muudatused võidakse rakendada koos.

Lihtsamate rakenduste korral saab rakenduse käivitamisel rakendada kogu vajalike migratsioonide komplekti. Sellisel juhul kuuluvad kõik muutmisgrupid ühte kategooriasse ja käivitatakse alati, kui rakendus initsialiseeritakse.

Ükskõik millises etapis on valitud migreerimiste rakendamine, tasub mainida, et sama andmebaasi kasutamine mitme rakenduse jaoks võib migreerimisel rakendada lukustusi. Liquibase (nagu paljud teised sarnased lahendused) kasutab metaandmete salvestamiseks kahte spetsiaalset tabelit: DATABASECHANGELOGLOCK ja runOnChange='true'. Esimest kasutatakse rakendatud muudatuskomplektide kohta teabe salvestamiseks ja teist samaaegse migreerimise vältimiseks samas andmebaasiskeemis. Niisiis, kui mitu rakendust peavad mingil põhjusel kasutama sama andmebaasiskeemi, on lukkude vältimiseks parem kasutada metaandmetabelite jaoks vaikimisi nimesid.

Nüüd, kui kõrgetasemeline struktuur on selge, peate otsustama, kuidas korraldada muudatuste komplektid igas kategoorias.

näidis muudatuste organisatsioon

See sõltub suuresti konkreetsetest rakenduse nõuetest, kuid järgmised punktid on tavaliselt mõistlikud:

  1. Hoidke muudatuste logisid rühmitatuna toote väljalasete järgi. Looge iga väljaande jaoks uus kataloog ja pange sinna vastavad muudatuste logifailid. Kas juur muutmise logi ja hõlmama väljaannetele vastavad muutmispäevikud. Väljalaske muudatuste päevikute hulka lisage ka muud selle väljaande koosseisud.
  2. Looge muudatuste logifailide ja muutmiskomplekti identifikaatorite nimetamiskord - ja järgige seda muidugi.
  3. Vältige muudatuste komplekti, kus on palju muudatusi. Eelistage ühele pikale muutekomplektile mitut muutmisrühma.
  4. Kui kasutate salvestatud protseduure ja peate neid värskendama, kaaluge createTable atribuut muutuste komplektile, kuhu see salvestatud protseduur lisatakse. Vastasel korral peate iga kord, kui seda värskendatakse, looma salvestatud protseduuri uue versiooniga uue muudatuste komplekti. Nõuded on erinevad, kuid sellise ajaloo jälgimata jätmine on sageli vastuvõetav.
  5. Enne funktsiooniharude ühendamist kaaluge üleliigsete muudatuste tühjendamist. Mõnikord juhtub, et funktsiooniharu (eriti pikaajalise) puhul täpsustavad hilisemad muudatused varasemates muudatustes tehtud muudatusi. Näiteks võite luua tabeli ja seejärel otsustada sellele veel veerge lisada. Need veerud tasub lisada algusesse context='test' muuta, kui seda funktsiooniharu veel põhiharuga ei ühendatud.
  6. Testi andmebaasi loomiseks kasutage samu muudatuste logisid. Kui proovite seda teha, võite peagi teada saada, et mitte iga muudatuskomplekt ei ole testikeskkonnas rakendatav või et selle konkreetse testikeskkonna jaoks on vaja täiendavaid muudatusi. Liquibase'i abil saab selle probleemi hõlpsasti lahendada kontekstides . Lisage lihtsalt test atribuut muudatustele, mis tuleb käivitada ainult testidega, ja seejärel lähtestage Liquibase rollback kontekst on lubatud.

Tagasi veeremine

Nagu muud sarnased lahendused, toetab ka Liquibase skeemi migreerimist üles ja alla. Kuid hoiatage: rändete tagasivõtmine ei pruugi olla lihtne ja see pole alati väärt pingutusi. Kui otsustasite oma rakenduse üleviimise tagasivõtmist toetada, siis olge järjekindel ja tehke seda kõigi muudatuste puhul, mis tuleb tagasi võtta. Liquibase'i abil saab muudatuste tühistada, lisades createTable silt, mis sisaldab tagasivõtmiseks vajalikke muudatusi. Vaatleme järgmist näidet:

addColumn

Selgesõnaline tagasipööramine on siin üleliigne, kuna Liquibase teostaks samu tagasikäigu toiminguid. Liquibase suudab automaatselt tagasi lükata enamiku oma toetatud tüüpi muudatustest, nt createIndex, DATABASECHANGELOG või DATABASECHANGELOG

Mineviku parandamine

Keegi pole täiuslik ja me kõik teeme vigu. Mõned neist võidakse avastada liiga hilja, kui rikutud muudatused on juba rakendatud. Uurime, mida saaks päeva päästmiseks teha.

Andmebaasi käsitsi värskendamine

See hõlmab DATABASECHANGELOG -ga jamamist ja teie andmebaasi järgmistel viisidel:

  1. Kui soovite vigaseid muudatusi parandada ja need uuesti käivitada, toimige järgmiselt.
    • Eemaldage read MD5SUM -st mis vastavad muutumiskomplektidele.
    • Eemaldage kõik muudatustega kaasnevad kõrvaltoimed; nt taastage tabel, kui see maha visati.
    • Parandage halvad muudatused.
    • Käivitage migratsioonid uuesti.
  2. Kui soovite vigaseid muudatusi parandada, kuid jätke need uuesti rakendamata:
    • Värskenda NULL seadistades MD5SUM välja väärtuseks runOnChange='true' nende ridade jaoks, mis vastavad halbadele muutmiskomplektidele.
    • Parandage andmebaasis valesti tehtud käsitsi. Näiteks kui veerg oli lisatud vale tüübiga, väljastage selle tüübi muutmiseks päring.
    • Parandage halvad muudatused.
    • Käivitage migratsioonid uuesti. Liquibase arvutab uue kontrollsumma ja salvestab selle kausta context Parandatud muudatuste komplekte ei käitata uuesti.

Ilmselt on neid trikke arendamise käigus lihtne teha, kuid see muutub palju raskemaks, kui muudatusi rakendatakse mitmele andmebaasile.

Kirjutage parandused

Praktikas on selline lähenemine tavaliselt sobivam. Võite mõelda, miks mitte ainult muuta algset muudatuste komplekti? Tõde on see, et see sõltub sellest, mida tuleb muuta. Liquibase arvutab kontrollsumma iga muudatushulga kohta ja keeldub uusi muudatusi rakendamast, kui kontrollsumma on uus vähemalt ühe varem rakendatud muudatuste puhul. Seda käitumist saab kohandada muudatuste kaupa, määrates runOnChange atribuut. Kui muudate, ei mõjuta kontrollsummat eeltingimused või valikulised muudatuste komplekti atribuudid (context, context='graveyard-changesets-never-run' jne).

mille jaoks Adobe xd on mõeldud

Nüüd võite mõelda, kuidas saate muudatuste komplekti lõpuks vigadega parandada?

  1. Kui soovite, et neid muudatusi ikka veel uute skeemide puhul rakendataks, lisage lihtsalt parandavad muudatuste komplektid. Näiteks kui veerg lisati vale tüübiga, muutke selle tüüpi uues muudatuste komplektis.
  2. Kui soovite teeselda, et neid halbu muudatusi pole kunagi olnud, tehke järgmist.
    • Eemaldage muutmiskomplektid või lisage changeSetExecuted atribuudi väärtusega, mis tagab, et te ei prooviks enam kunagi sellise kontekstiga migreerumisi rakendada, nt 
      •  
    • Lisage uued muudatuskomplektid, mis kas valesti tehtu ennistavad või parandavad. Neid muudatusi tuleks rakendada ainult siis, kui rakendati halbu muudatusi. Seda on võimalik saavutada eeltingimustega, näiteks 
      |_+_|
       Ärge unustage lisada kommentaari, mis selgitab, miks te seda teete.
      •  
    • Lisage uued muudatused, mis skeemi õigesti muudavad.
      •  
     
    3.  
Nagu näete, on mineviku parandamine võimalik, ehkki see ei pruugi alati sirgjooneline olla.
Kasvavate valude leevendamine
Kui teie rakendus vananeb, kasvab ka selle muutmislogi, kogudes iga skeemi muudatuse mööda teed. See on disaini järgi ja selles pole midagi olemuslikult valesti. Pikki muudatuste logisid saab muuta lühemaks, kui rännakuid korrapäraselt kokku tõmmata, näiteks pärast toote iga versiooni väljaandmist. Mõnel juhul muudaks see värske skeemi lähtestamise kiiremaks.
 illustreerib vahetuskirjade kokkusurumist
Squashing ei ole alati tühine ja võib põhjustada taandarenguid ilma palju eeliseid toomata. Teine suurepärane võimalus on lähteandmebaasi kasutamine, et vältida kõigi muudatuste käivitamist. See sobib hästi keskkondade testimiseks, kui peate andmebaasi võimalikult kiiresti valmis saama, võib-olla isegi mõne testiandmega. Võite mõelda sellest kui muutmiskomplektide kokkupõrkamise vormist: mingil hetkel (nt pärast teise versiooni väljaandmist) teete skeemi dumpingu. Pärast prügimäe taastamist rakendate migreerimisi nagu tavaliselt. Rakendatakse ainult uusi muudatusi, kuna vanemad muudatused rakendati juba enne prügikasti tegemist; seetõttu taastati nad prügimäelt.
 seemnete andmebaasi illustratsioon
Järeldus
Vältisime tahtlikult Liquibase funktsioonidesse sügavamale sukeldumist, et pakkuda artiklit, mis oleks lühike ja täpne ning keskenduks üldiselt arenevatele skeemidele. Loodetavasti on selge, milliseid eeliseid ja probleeme toob kaasa andmebaasiskeemide migreerimise automaatne rakendamine ja kui hästi see kõik sobib DevOpsi kultuur . Oluline on mitte muuta häid ideid dogmaks. Nõuded on erinevad ja nii andmebaasi insenerid , peaksid meie otsused soodustama toote edasiliikumist ja mitte ainult kellegi soovituste järgimist Internetis.
Põhitõdede mõistmine
Mida tähendab skeem andmebaasis?
Andmebaasi skeem kirjeldab, kuidas andmed on andmebaasis sees korraldatud.
Mis vahe on andmebaasil ja skeemil?
Skeem on andmebaasi osa. Andmebaas koosneb tavaliselt ühest või mitmest skeemist. Samuti on DBMS-i nimetamine andmebaasiks üsna tavaline. Tavaliselt on kontekstist selge, kas me räägime andmekonteinerist või süsteemist, mis seda konteinerit haldab.
Mis on skeemi näide?
Kui loote reisihalduse rakendust, sisaldab selle andmebaasiskeem selliseid üksusi nagu lennufirma, lend või linn. Lisaks kasutaja määratletud skeemidele on DBMS-il tavaliselt „infoskeem”, mida saab kasutada seadete ja metaandmete päringuteks.
Millised on erinevad andmebaaside tüübid?
Lisaks relatsioonandmebaasidele on olemas objekti-, dokumendikesksed ja hierarhilised andmebaasid.
Kas on võimalik päringu kiiremini käivitada?
Aeglast päringut saate optimeerida, restruktureerides seda või muutes skeemi. DBMS võib tavaliselt anda teile täitmisplaani ja aidata arvata, mis teie päringut aeglustab (nt ei kasuta indekse ega valib alaküsimustes liiga palju andmeid). PostgreSQL-is saate vale mõistmiseks kasutada seletust või seletada ANALÜÜSI.
Mis on skeem PostgreSQL-is?
PostgreSQL-is võib teil olla mitu klastrit ühes andmebaasis; skeem on andmebaasi struktuurielement. See on konteiner tabelite, vaadete, protseduuride jms jaoks. Skeeme võib pidada andmebaasis olevateks kataloogideks, kuid skeemid ei tohi sisaldada muid skeeme.

        

            

                

                    

                        

                            
Talentide sõelumise direktor

                            
Muu

                            
                        

                        

                            Talentide sõelumise direktor
                        

                    

                

                

                    

                        

                            Värvipõhise pildiotsingumootori ehitamine Ruby'sse
                        

                        

                            
Värvipõhise pildiotsingumootori ehitamine Ruby'sse

                            
Tagumine Ots