🥇 Fleiri forritarar ættu að vita þetta um gagnagrunna

Athugið. þýð.: Jaana Dogan er reyndur verkfræðingur hjá Google sem vinnur nú að sýnileika framleiðsluþjónustu fyrirtækisins sem skrifað er í Go. Í þessari grein, sem náði miklum vinsældum meðal enskumælandi áhorfenda, safnaði hún í 17 punkta mikilvægum tæknilegum upplýsingum varðandi DBMS (og stundum dreifð kerfi almennt) sem gagnlegt er að hafa í huga fyrir þróunaraðila stórra/krefjandi forrita.

Langflest tölvukerfi halda utan um ástand sitt og þurfa því einhvers konar gagnageymslukerfi. Ég safnaði þekkingu um gagnagrunna yfir langan tíma og gerði í leiðinni hönnunarmistök sem leiddu til gagnataps og truflunar. Í kerfum sem vinna mikið magn upplýsinga eru gagnagrunnar kjarninn í kerfisarkitektúrnum og virka sem lykilatriði við val á bestu lausninni. Þrátt fyrir að vel sé fylgst með vinnu gagnagrunnsins eru vandamálin sem forritarar reyna að sjá fyrir oft bara toppurinn á ísjakanum. Í þessari greinaröð deili ég nokkrum hugmyndum sem munu nýtast hönnuðum sem eru ekki sérhæfðir á þessu sviði.

Þú ert heppinn ef 99,999% tilvika veldur netkerfinu ekki vandamálum.
Sýra þýðir marga mismunandi hluti.
Hver gagnagrunnur hefur sína eigin aðferðir til að tryggja samræmi og einangrun.
Bjartsýn blokkun kemur til bjargar þegar erfitt er að viðhalda þeirri venjulegu.
Það eru önnur frávik fyrir utan óhreinan lestur og gagnatap.
Gagnagrunnurinn og notandinn eru ekki alltaf sammála um aðgerðir.
Hægt er að færa sundrun á forritastigi út fyrir forritið.
Sjálfvirk aukning getur verið hættuleg.
Gömul gögn geta verið gagnleg og þarf ekki að læsa þeim.
Bjögun er dæmigerð fyrir hvaða tímauppsprettu sem er.
Seinkun hefur margar merkingar.
Meta skal árangurskröfur fyrir ákveðin viðskipti.
Hreiður viðskipti geta verið hættuleg.
Viðskipti ættu ekki að vera bundin við umsóknarríki.
Fyrirspurnaskipuleggjendur geta sagt þér mikið um gagnagrunna.
Flutningur á netinu er erfiður en mögulegur.
Veruleg aukning gagnagrunnsins hefur í för með sér aukinn ófyrirsjáanleika.

Ég vil þakka Emmanuel Odeke, Rein Henrichs og öðrum fyrir álit þeirra á fyrri útgáfu þessarar greinar.

Þú ert heppinn ef 99,999% tilvika veldur netkerfinu ekki vandamálum.

Spurningin er enn um hversu áreiðanleg nútíma nettækni er og hversu oft kerfi liggja niðri vegna netbilunar. Upplýsingar um þetta mál eru af skornum skammti og rannsóknir eru oft áberandi af stórum stofnunum með sérhæft net, búnað og starfsfólk.

Með 99,999% framboðshlutfalli fyrir Spanner (alheimsdreifður gagnagrunnur Google), heldur Google því fram að aðeins 7,6% vandamál tengjast netkerfinu. Á sama tíma kallar fyrirtækið sérhæft net sitt „aðalstoð“ mikils framboðs. Nám Bailis og Kingsbury, sem gerð var árið 2014, skorar á eina af „ranghugmyndir um dreifða tölvuvinnslu“, sem Peter Deutsch mótaði árið 1994. Er netið virkilega áreiðanlegt?

Alhliða rannsóknir utan risafyrirtækja, gerðar fyrir víðara net, eru einfaldlega ekki til. Það eru heldur ekki næg gögn frá helstu aðilum um hversu mörg prósent af vandamálum viðskiptavina þeirra eru nettengd. Við erum vel meðvituð um truflanir í netstafla stórra skýjaveitna sem geta tekið niður heilan hluta af internetinu í nokkrar klukkustundir einfaldlega vegna þess að þeir eru áberandi atburðir sem hafa áhrif á fjölda fólks og fyrirtækja. Nettruflanir geta valdið vandræðum í mun fleiri tilfellum, jafnvel þótt ekki séu öll þessi mál í sviðsljósinu. Viðskiptavinir skýjaþjónustu vita heldur ekkert um orsakir vandamála. Ef um bilun er að ræða er nánast ómögulegt að rekja hana til netvillu hjá þjónustuveitunni. Fyrir þá eru þjónusta þriðja aðila svartir kassar. Það er ómögulegt að meta áhrifin án þess að vera stór þjónustuaðili.

Miðað við það sem stóru leikmennirnir segja frá um kerfin sín er óhætt að segja að þú sért heppinn ef neterfiðleikar eru aðeins lítill hluti af hugsanlegum niðurtímavandamálum. Netsamskipti þjást enn af svo hversdagslegum hlutum eins og vélbúnaðarbilun, staðfræðibreytingum, breytingum á stjórnunarstillingum og rafmagnsleysi. Nýlega kom mér á óvart að heyra að listi yfir hugsanleg vandamál var bætt við hákarlabit (já, þú heyrðir rétt).

Sýra þýðir mikið af mismunandi hlutum

Skammstöfunin ACID stendur fyrir Atomicity, Consistency, Isolation, Reliability. Þessum eiginleikum viðskipta er ætlað að tryggja réttmæti þeirra ef upp koma bilanir, villur, vélbúnaðarbilanir o.fl. Án ACID eða svipaðra kerfa væri erfitt fyrir forritara að greina á milli þess sem þeir bera ábyrgð á og því sem gagnagrunnurinn ber ábyrgð á. Flestir venslagagnagrunnar reyna að vera ACID samhæfðir, en nýjar aðferðir eins og NoSQL hafa gefið tilefni til margra gagnagrunna án ACID-viðskipta vegna þess að þeir eru dýrir í framkvæmd.

Þegar ég kom fyrst inn í iðnaðinn talaði tæknilegur leiðtogi okkar um hversu viðeigandi ACID hugtakið væri. Til að vera sanngjarn er ACID talin gróf lýsing frekar en strangur innleiðingarstaðall. Í dag finnst mér það aðallega gagnlegt vegna þess að það vekur sérstakan flokk mála (og stingur upp á ýmsum mögulegum lausnum).

Ekki er sérhver DBMS samhæft við ACID; Á sama tíma skilja gagnagrunnsútfærslur sem styðja ACID kröfurnar á annan hátt. Ein af ástæðunum fyrir því að ACID útfærslur eru misjafnar er vegna margra skipta sem þarf að gera til að innleiða ACID kröfur. Höfundar geta kynnt gagnagrunna sína sem ACID-samhæfða, en túlkun á jaðartilfellum getur verið mjög breytileg, sem og aðferðin til að meðhöndla „ólíklega“ atburði. Að minnsta kosti geta forritarar öðlast skilning á háu stigi á ranghala grunnútfærslum til að öðlast réttan skilning á sérstakri hegðun þeirra og hönnunarskiptum.

Umræðan um hvort MongoDB uppfylli ACID kröfur heldur áfram jafnvel eftir útgáfu útgáfu 4. MongoDB hefur ekki verið stutt í langan tíma skógarhögg, þó sjálfgefið hafi gögn verið skuldbundin á diskinn ekki oftar en einu sinni á 60 sekúndna fresti. Ímyndaðu þér eftirfarandi atburðarás: umsókn birtir tvö skrif (w1 og w2). MongoDB geymir w1 með góðum árangri en w2 tapast vegna vélbúnaðarbilunar.

Skýringarmynd sem sýnir atburðarásina. MongoDB hrynur áður en það getur skrifað gögn á diskinn

Að skuldbinda sig til disks er dýrt ferli. Með því að forðast tíðar skuldbindingar bæta verktaki upptökuafköst á kostnað áreiðanleika. MongoDB styður sem stendur skráningu, en óhrein skrif geta samt haft áhrif á gagnaheilleika þar sem annálar eru sjálfgefið teknar á 100 ms fresti. Það er, svipuð atburðarás er enn möguleg fyrir logs og þær breytingar sem fram koma í þeim, þó áhættan sé mun minni.

Hver gagnagrunnur hefur sína eigin samkvæmni og einangrunaraðferðir

Af ACID-kröfum státar samkvæmni og einangrun af flestum mismunandi útfærslum vegna þess að svið málamiðlana er breiðari. Það verður að segjast að samkvæmni og einangrun eru frekar dýrar aðgerðir. Þeir krefjast samræmingar og auka samkeppni um samræmi í gögnum. Flækjustig vandans eykst verulega þegar nauðsynlegt er að skala gagnagrunninn lárétt yfir mörg gagnaver (sérstaklega ef þau eru staðsett á mismunandi landfræðilegum svæðum). Það er mjög erfitt að ná háu samræmi þar sem það dregur einnig úr framboði og eykur skiptingu netkerfisins. Fyrir almennari skýringar á þessu fyrirbæri ráðlegg ég þér að vísa til CAP setning. Það er líka athyglisvert að forrit geta séð um lítið magn af ósamræmi og forritarar geta skilið blæbrigði vandamálsins nógu vel til að innleiða viðbótarrökfræði í forritinu til að takast á við ósamræmi án þess að treysta mikið á gagnagrunninn til að höndla það.

DBMS veitir oft mismunandi stig einangrunar. Forritaframleiðendur geta valið þann árangursríkasta út frá óskum þeirra. Lítil einangrun gerir ráð fyrir auknum hraða en eykur einnig hættuna á gagnakapphlaupi. Mikil einangrun dregur úr þessum líkum en hægir á vinnunni og getur leitt til samkeppni sem mun leiða til slíkra hemla í grunninum að bilanir hefjast.

Farið yfir núverandi samhliðalíkön og tengsl þeirra á milli

SQL staðallinn skilgreinir aðeins fjögur einangrunarstig, þó að þau séu mörg fleiri í orði og reynd. Jepson.io býður upp á frábært yfirlit yfir núverandi samhliðalíkön. Til dæmis tryggir Google Spanner ytri raðvirkni með klukkusamstillingu og þó að þetta sé strangara einangrunarlag er það ekki skilgreint í stöðluðum einangrunarlögum.

SQL staðallinn nefnir eftirfarandi einangrunarstig:

Serializeable (ströngust og dýrust): Framkvæmd sem hægt er að nota í röð hefur sömu áhrif og einhver raðbundin færsluframkvæmd. Raðbundin framkvæmd þýðir að hver síðari viðskipti hefst aðeins eftir að þeirri fyrri er lokið. Það skal tekið fram að stig Serializeable oft útfært sem svokölluð skyndimyndaeinangrun (til dæmis í Oracle) vegna mismunandi túlkunar, þó að skyndimyndaeinangrun sjálf sé ekki sýnd í SQL staðlinum.
Endurtekinn lestur: Óskuldsettar færslur í núverandi færslu eru tiltækar fyrir núverandi færslu, en breytingar gerðar af öðrum færslum (eins og nýjar línur) ekki sjáanlegt.
Lesið skuldbundið: Óbundin gögn eru ekki tiltæk fyrir viðskipti. Í þessu tilviki geta færslur aðeins séð skuldbundin gögn og fantómlestur geta átt sér stað. Ef færsla setur inn og skuldbindur nýjar línur, mun núverandi færsla geta séð þær þegar spurt er.
Lesið óskuldbundið (minnst strangt og dýrt stig): Óhrein lesning er leyfð, færslur geta séð óskuldbundnar breytingar sem gerðar eru af öðrum viðskiptum. Í reynd getur þetta stig verið gagnlegt fyrir gróft mat, svo sem fyrirspurnir COUNT(*) á borðið.

Level Serializeable lágmarkar hættuna á gagnakapphlaupum, á sama tíma og það er dýrast í framkvæmd og hefur í för með sér mesta samkeppnisálag á kerfið. Önnur einangrunarstig eru auðveldari í framkvæmd, en auka líkurnar á gagnahlaupum. Sum DBMS leyfir þér að stilla sérsniðið einangrunarstig, önnur hafa sterkar óskir og ekki eru öll stig studd.

Stuðningur við einangrunarstig er oft auglýstur í tilteknu DBMS, en aðeins nákvæm rannsókn á hegðun þess getur leitt í ljós hvað er í raun að gerast.

Farið yfir samhliða frávik á mismunandi einangrunarstigum fyrir mismunandi DBMS

Martin Kleppmann í verkefni sínu einsetukona Ber saman mismunandi einangrunarstig, talar um samhliða frávik og hvort gagnagrunnurinn geti haldið sig við tiltekið einangrunarstig. Rannsóknir Kleppmanns sýna hversu mismunandi gagnagrunnsframleiðendur hugsa um einangrunarstig.

Bjartsýn blokkun kemur til bjargar þegar erfitt er að viðhalda þeirri venjulegu.

Lokun getur verið mjög dýr, ekki bara vegna þess að hún eykur samkeppni í gagnagrunninum, heldur líka vegna þess að hún krefst þess að forritaþjónarnir séu stöðugt að tengjast gagnagrunninum. Skipting netkerfis getur aukið aðstæður á einkalás og leitt til stöðvunar sem erfitt er að bera kennsl á og leysa. Í þeim tilvikum þar sem einkalæsing hentar ekki hjálpar bjartsýn læsing.

Bjartsýnn lás er aðferð þar sem þegar strengur er lesinn tekur hann tillit til útgáfu hans, eftirlitsummu eða tíma síðustu breytinga. Þetta gerir þér kleift að tryggja að það sé engin frumeindaútgáfubreyting áður en þú breytir færslu:

UPDATE products
SET name = 'Telegraph receiver', version = 2
WHERE id = 1 AND version = 1

Í þessu tilviki, uppfærsla töflunnar products verður ekki framkvæmd ef önnur aðgerð gerði áður breytingar á þessari línu. Ef engar aðrar aðgerðir voru gerðar á þessari línu mun breytingin fyrir eina línu eiga sér stað og við getum sagt að uppfærslan hafi tekist.

Það eru önnur frávik fyrir utan óhreinan lestur og gagnatap

Þegar kemur að samkvæmni gagna er áherslan lögð á möguleikann á keppnisaðstæðum sem geta leitt til óhreina lestrar og gagnataps. Gagnafrávik hætta þó ekki þar.

Eitt dæmi um slík frávik er upptökuröskun (skrifaðu skekkjur). Erfitt er að greina röskun vegna þess að venjulega er ekki leitað að þeim. Þær stafa ekki af óhreinum lestri eða tapi á gögnum, heldur vegna brota á rökréttum skorðum sem settar eru á gögnin.

Til dæmis skulum við íhuga vöktunarforrit sem krefst þess að einn rekstraraðili sé á vakt allan tímann:

BEGIN tx1;                      BEGIN tx2;
SELECT COUNT(*)
FROM operators
WHERE oncall = true;
0                               SELECT COUNT(*)
                                FROM operators
                                WHERE oncall = TRUE;
                                0
UPDATE operators                UPDATE operators
SET oncall = TRUE               SET oncall = TRUE
WHERE userId = 4;               WHERE userId = 2;
COMMIT tx1;                     COMMIT tx2;

Í ofangreindum aðstæðum mun metspilling eiga sér stað ef bæði viðskiptin eru framin. Þrátt fyrir að það hafi ekki verið óhrein lesning eða tap á gögnum, var heilindi gagnanna í hættu: nú eru tveir einstaklingar taldir á vakt á sama tíma.

Raðaða einangrun, skemahönnun eða gagnagrunnstakmarkanir geta hjálpað til við að útrýma skrifspillingu. Hönnuðir verða að geta greint slík frávik meðan á þróun stendur til að forðast þau í framleiðslu. Á sama tíma er afar erfitt að leita að upptökuröskunum í kóðagrunninum. Sérstaklega í stórum kerfum, þegar mismunandi þróunarteymi eru ábyrgir fyrir innleiðingu aðgerða sem byggjast á sömu töflum og eru ekki sammála um sérstöðu gagnaaðgangs.

Gagnagrunnurinn og notandinn eru ekki alltaf sammála um hvað eigi að gera

Einn af lykileiginleikum gagnagrunna er trygging fyrir framkvæmdarfyrirmælum, en þessi skipun sjálf er hugsanlega ekki gagnsæ fyrir hugbúnaðarframleiðandanum. Gagnagrunnar framkvæma viðskipti í þeirri röð sem þau berast, ekki í þeirri röð sem forritarar ætla. Erfitt er að spá fyrir um röð viðskipta, sérstaklega í mjög hlaðnum samhliða kerfum.

Á meðan á þróun stendur, sérstaklega þegar unnið er með söfn sem ekki eru læst, getur lélegur stíll og lítill læsileiki valdið því að notendur trúi því að færslur séu framkvæmdar í röð, þegar þær gætu í raun borist í gagnagrunninn í hvaða röð sem er.

Við fyrstu sýn, í forritinu hér að neðan, eru T1 og T2 kallaðir í röð, en ef þessar aðgerðir eru óblokkandi og skila strax niðurstöðunni í formi loforð, þá verður röð símtala ákvörðuð af augnablikunum þegar þau fóru inn í gagnagrunninn:

niðurstaða1 = T1() // raunverulegar niðurstöður eru loforð
niðurstaða2 = T2()

Ef atomicity er krafist (þ.e. annaðhvort þarf að ljúka öllum aðgerðum eða hætta við) og röð skiptir máli, þá verður að framkvæma aðgerðir T1 og T2 í einni færslu.

Hægt er að færa sundrun á forritastigi út fyrir forritið

Sharding er aðferð til að skipta gagnagrunni lárétt. Sumir gagnagrunnar geta sjálfkrafa skipt gögnum lárétt á meðan aðrir geta það ekki eða eru ekki mjög góðir í því. Þegar gagnaarkitektar/hönnuðir geta spáð nákvæmlega fyrir um hvernig nálgast verður gögn geta þeir búið til lárétta skipting í notendarými í stað þess að framselja þessa vinnu í gagnagrunninn. Þetta ferli er kallað "kljúfur á forritastigi" (klipping á forritastigi).

Því miður skapar þetta nafn oft þann misskilning að sharding búi í umsóknarþjónustu. Reyndar er hægt að útfæra það sem sérstakt lag fyrir framan gagnagrunninn. Það fer eftir gagnavexti og endurtekningum á skema, kröfur um klippingu geta orðið ansi flóknar. Sumar aðferðir geta notið góðs af hæfileikanum til að endurtaka án þess að þurfa að endurskipuleggja forritaþjóna.

Dæmi um arkitektúr þar sem forritaþjónar eru aðskildir frá sundrunarþjónustunni

Með því að færa klippingu yfir í sérstaka þjónustu stækkar getu til að nota mismunandi klippingaraðferðir án þess að þurfa að endurdreifa forritum. Vitess er dæmi um slíkt klippikerfi á umsóknarstigi. Vitess veitir lárétta klippingu fyrir MySQL og gerir viðskiptavinum kleift að tengjast því í gegnum MySQL samskiptareglur. Kerfið skiptir gögnunum í mismunandi MySQL hnúta sem vita ekkert hver um annan.

Sjálfvirk aukning getur verið hættuleg

AUTOINCREMENT er algeng leið til að búa til aðallykla. Það eru oft tilvik þegar gagnagrunnar eru notaðir sem auðkennisframleiðendur og gagnagrunnurinn inniheldur töflur sem eru hannaðar til að búa til auðkenni. Það eru nokkrar ástæður fyrir því að það er langt frá því að búa til aðallykla með því að nota sjálfvirka aukningu:

Í dreifðum gagnagrunni er sjálfvirk aukning alvarlegt vandamál. Til að búa til auðkennið þarf alþjóðlegan læsingu. Í staðinn geturðu búið til UUID: þetta krefst ekki samskipta milli mismunandi gagnagrunnshnúta. Sjálfvirk aukning með læsingum getur leitt til deilna og dregið verulega úr afköstum á innleggjum við dreifðar aðstæður. Sumar DBMS (td MySQL) gætu krafist sérstakrar stillingar og vandlegrar athygli til að skipuleggja meistara-meistara afritun á réttan hátt. Og það er auðvelt að gera mistök við uppsetningu, sem mun leiða til upptökubilana.
Sumir gagnagrunnar hafa skiptingaralgrím sem byggjast á aðallyklum. Samfelld auðkenni geta leitt til ófyrirsjáanlegra heitra punkta og aukins álags á sumum skiptingum á meðan önnur eru aðgerðalaus.
Aðallykill er fljótlegasta leiðin til að fá aðgang að röð í gagnagrunni. Með betri leiðum til að bera kennsl á færslur geta röð auðkenni breytt mikilvægasta dálknum í töflum í gagnslausan dálk fylltan tilgangslausum gildum. Þess vegna, þegar það er mögulegt, vinsamlegast veldu einstakan og náttúrulegan aðallykil á heimsvísu (td notandanafn).

Áður en ákvörðun er tekin um nálgun skaltu íhuga áhrif sjálfvirkrar aukningar auðkenna og UUID á flokkun, skiptingu og sundrun.

Gömul gögn geta verið gagnleg og þarfnast ekki læsingar

Multiversion Concurrency Control (MVCC) útfærir margar af þeim samræmiskröfum sem voru ræddar stuttlega hér að ofan. Sumir gagnagrunnar (til dæmis Postgres, Spanner) nota MVCC til að „fæða“ viðskipti með skyndimyndum - eldri útgáfur af gagnagrunninum. Einnig er hægt að setja skyndimyndafærslur í röð til að tryggja samræmi. Þegar lesið er úr gamalli skyndimynd eru úrelt gögn lesin.

Að lesa örlítið gömul gögn getur verið gagnlegt, til dæmis þegar búið er til greiningar úr gögnunum eða reiknað út áætluð heildargildi.

Fyrsti kosturinn við að vinna með eldri gögn er lítil leynd (sérstaklega ef gagnagrunninum er dreift yfir mismunandi landsvæði). Annað er að skrifvarið viðskipti eru læsilaus. Þetta er verulegur kostur fyrir forrit sem lesa mikið, svo framarlega sem þau geta séð um gömul gögn.

Forritaþjónninn les gögn frá staðbundinni eftirmynd sem eru 5 sekúndur úrelt, jafnvel þótt nýjasta útgáfan sé fáanleg hinum megin við Kyrrahafið

DBMSs hreinsa sjálfkrafa eldri útgáfur og leyfa þér í sumum tilfellum að gera þetta sé þess óskað. Til dæmis, Postgres gerir notendum kleift að gera VACUUM sé þess óskað, og framkvæmir einnig reglulega þessa aðgerð sjálfkrafa. Spanner rekur sorphirðu til að losna við skyndimyndir eldri en klukkutíma.

Hvenær sem heimildir eru háðar brenglun

Best geymda leyndarmálið í tölvunarfræði er að öll tímasetningar API ljúga. Reyndar vita vélar okkar ekki nákvæmlega núverandi tíma. Tölvur innihalda kvarskristalla sem mynda titring sem er notaður til að halda tíma. Hins vegar eru þær ekki nógu nákvæmar og gætu verið á undan/á eftir nákvæmum tíma. Vaktin getur orðið 20 sekúndur á dag. Þess vegna verður tíminn á tölvunum okkar að vera reglulega samstilltur við netkerfið.

NTP netþjónar eru notaðir til samstillingar, en samstillingarferlið sjálft er háð nettafir. Jafnvel samstilling við NTP netþjón í sama gagnaveri tekur nokkurn tíma. Það er ljóst að vinna með opinberan NTP netþjón getur leitt til enn meiri röskunar.

Atómklukkur og GPS hliðstæður þeirra eru betri til að ákvarða núverandi tíma, en þær eru dýrar og krefjast flóknar uppsetningar, svo ekki er hægt að setja þær á alla bíla. Vegna þessa nota gagnaver stigskipt nálgun. Atóm- og/eða GPS klukkur sýna nákvæman tíma, eftir það er henni útvarpað til annarra véla í gegnum aukaþjóna. Þetta þýðir að hver vél mun upplifa ákveðna frávik frá nákvæmum tíma.

Ástandið versnar af því að forrit og gagnagrunnar eru oft staðsettir á mismunandi vélum (ef ekki í mismunandi gagnaverum). Þannig mun tíminn ekki aðeins vera mismunandi á DB hnútum sem dreift er á mismunandi vélar. Það verður líka öðruvísi á forritaþjóninum.

Google TrueTime tekur allt aðra nálgun. Flestir telja að framfarir Google í þessa átt skýrist af banal umskipti yfir í atóm- og GPS klukkur, en þetta er aðeins hluti af heildarmyndinni. Svona virkar TrueTime:

TrueTime notar tvær mismunandi heimildir: GPS og atómklukkur. Þessar klukkur eru með bilunarhami sem ekki tengist. [sjá síðu 5 fyrir nánari upplýsingar hér - ca. þýðing.), þannig að samnotkun þeirra eykur áreiðanleika.
TrueTime er með óvenjulegt API. Það skilar tíma sem bili með mæliskekkju og óvissu innbyggt í það. Raunverulegt augnablik í tíma er einhvers staðar á milli efri og neðri mörka bilsins. Spanner, dreifður gagnagrunnur Google, bíður einfaldlega þar til óhætt er að segja að núverandi tími sé utan marka. Þessi aðferð kynnir nokkra leynd inn í kerfið, sérstaklega ef óvissan á meistaranum er mikil, en tryggir réttmæti jafnvel í alþjóðlegum dreifðum aðstæðum.

Spanner íhlutirnir nota TrueTime, þar sem TT.now() skilar bili, þannig að hann sefur einfaldlega þar til hann getur verið viss um að núverandi tími sé liðinn frá ákveðnum tímapunkti

Minni nákvæmni við að ákvarða núverandi tíma þýðir aukningu á lengd Spanner-aðgerða og lækkun á afköstum. Þess vegna er mikilvægt að viðhalda sem mestri nákvæmni þó ómögulegt sé að fá fullkomlega nákvæma úr.

Seinkun hefur margar merkingar

Ef þú spyrð tugi sérfræðinga um hvað seinkun er, færðu líklega önnur svör. Í DBMS er leynd oft kölluð „gagnagrunnsleynd“ og er frábrugðin því sem viðskiptavinurinn skynjar. Staðreyndin er sú að viðskiptavinurinn fylgist með summu nettöfarinnar og seinkun gagnagrunnsins. Hæfni til að einangra tegund leynd er mikilvæg þegar kembiforrit eru vaxandi vandamál. Þegar þú safnar og sýnir mælikvarða skaltu alltaf reyna að fylgjast með báðum gerðum.

Meta skal árangurskröfur fyrir ákveðin viðskipti

Stundum eru frammistöðueiginleikar DBMS og takmarkanir þess tilgreindar með tilliti til skrif/lestrarflæðis og leynd. Þetta veitir almennt yfirlit yfir helstu kerfisfæribreytur, en þegar metið er árangur nýs DBMS er mun yfirgripsmeiri nálgun að meta sérstaklega mikilvægar aðgerðir (fyrir hverja fyrirspurn og/eða færslu). Dæmi:

Skrifaðu afköst og leynd þegar ný röð er sett inn í töflu X (með 50 milljón línum) með tilgreindum takmörkunum og línufyllingu í tengdum töflum.
Seinkun á að birta vini vina ákveðins notanda þegar meðalfjöldi vina er 500.
Seinkun á að sækja 100 efstu færslurnar úr sögu notanda þegar notandi fylgir 500 öðrum notendum með X færslum á klukkustund.

Mat og tilraunir geta falið í sér slík mikilvæg tilvik þar til þú ert viss um að gagnagrunnurinn uppfylli frammistöðukröfur. Svipuð þumalputtaregla tekur einnig tillit til þessarar sundurliðunar þegar leynd er safnað og SLOs ákvarðað.

Vertu meðvitaður um mikla virkni þegar þú safnar mæligildum fyrir hverja aðgerð. Notaðu annála, atburðasöfnun eða dreifða rakningu til að fá aflmikil villuleitargögn. Í greininni "Viltu kemba biðtíma?» þú getur kynnt þér seinkun villuleitaraðferðir.

Hreiður viðskipti geta verið hættuleg

Ekki allir DBMS styðja hreiður viðskipti, en þegar þeir gera það geta slík viðskipti leitt til óvæntra villna sem ekki er alltaf auðvelt að greina (þ.e. það ætti að vera augljóst að það er einhvers konar frávik).

Þú getur forðast að nota hreiður viðskipti með því að nota viðskiptavinasöfn sem geta greint og framhjá þeim. Ef ekki er hægt að yfirgefa hreiður færslur skal gæta sérstakrar varúðar við framkvæmd þeirra til að forðast óvæntar aðstæður þar sem lokið er við færslur fyrir slysni vegna hreiðra.

Að umlykja viðskipti í mismunandi lögum getur leitt til óvæntra hreiðra viðskipta og frá sjónarhóli kóða læsileika getur það gert það erfitt að skilja fyrirætlanir höfundar. Skoðaðu eftirfarandi forrit:

with newTransaction():
   Accounts.create("609-543-222")
   with newTransaction():
       Accounts.create("775-988-322")
       throw Rollback();

Hver verður framleiðsla ofangreinds kóða? Mun það afturkalla bæði viðskiptin, eða bara þá innri? Hvað gerist ef við treystum á mörg lög af bókasöfnum sem umlykja sköpun viðskipta fyrir okkur? Getum við greint og bætt slík tilvik?

Ímyndaðu þér gagnalag með mörgum aðgerðum (t.d. newAccount) er þegar innleitt í eigin viðskiptum. Hvað gerist ef þú keyrir þau sem hluti af viðskiptarökfræði á hærra stigi sem keyrir innan eigin viðskipta? Hver væri einangrunin og samræmið í þessu tilfelli?

function newAccount(id string) {
  with newTransaction():
      Accounts.create(id)
}

Í stað þess að leita að svörum við svona endalausum spurningum er betra að forðast hreiður viðskipti. Þegar öllu er á botninn hvolft getur gagnalagið þitt auðveldlega framkvæmt aðgerðir á háu stigi án þess að búa til eigin viðskipti. Að auki er viðskiptarökfræðin sjálf fær um að hefja viðskipti, framkvæma aðgerðir á þeim, fremja eða hætta við viðskipti.

function newAccount(id string) {
   Accounts.create(id)
}
// In main application:
with newTransaction():
   // Read some data from database for configuration.
   // Generate an ID from the ID service.
   Accounts.create(id)
   Uploads.create(id) // create upload queue for the user.

Viðskipti ættu ekki að vera bundin við umsóknarríki

Stundum er freistandi að nota umsóknarstöðu í viðskiptum til að breyta tilteknum gildum eða fínstilla fyrirspurnarfæribreytur. Mikilvægi litbrigðið sem þarf að íhuga er rétt umfang notkunar. Viðskiptavinir endurræsa oft viðskipti þegar það eru netvandamál. Ef viðskiptin eru þá háð ástandi sem verið er að breyta með einhverju öðru ferli, gæti það valið rangt gildi eftir möguleikanum á gagnakapphlaupi. Viðskipti verða að taka tillit til hættunnar á gagnakapphlaupi í umsókninni.

var seq int64
with newTransaction():
    newSeq := atomic.Increment(&seq)
    Entries.query(newSeq)
    // Other operations...

Ofangreind viðskipti munu auka raðnúmerið í hvert sinn sem það er framkvæmt, óháð lokaniðurstöðu. Ef commit mistekst vegna netvandamála verður beiðnin framkvæmd með öðru raðnúmeri þegar þú reynir aftur.

Fyrirspurnaskipuleggjendur geta sagt þér mikið um gagnagrunn

Fyrirspurnaskipuleggjendur ákveða hvernig fyrirspurn verður framkvæmd í gagnagrunni. Þeir greina einnig beiðnir og fínstilla þær áður en þær eru sendar. Skipuleggjendur geta aðeins gefið nokkrar mögulegar áætlanir byggðar á þeim merkjum sem þeir hafa yfir að ráða. Til dæmis, hver er besta leitaraðferðin fyrir eftirfarandi fyrirspurn?

SELECT * FROM articles where author = "rakyll" order by title;

Niðurstöðurnar er hægt að sækja á tvo vegu:

Full borðskönnun: Þú getur skoðað hverja færslu í töflunni og skilað greinum með samsvarandi nafni höfundar og síðan pantað þær.
Vísitalaskönnun: Þú getur notað vísitölu til að finna samsvarandi auðkenni, fá þessar línur og panta þær síðan.

Hlutverk fyrirspurnaskipuleggjanda er að ákvarða hvaða stefna er best. Það er þess virði að hafa í huga að skipuleggjendur fyrirspurna hafa aðeins takmarkaða forspárgetu. Þetta getur leitt til slæmra ákvarðana. DBA eða forritarar geta notað þau til að greina og fínstilla fyrirspurnir sem standa sig ekki vel. Nýjar útgáfur af DBMS geta stillt fyrirspurnaskipuleggjendur og sjálfsgreining getur hjálpað til við að uppfæra gagnagrunninn ef nýja útgáfan leiðir til afköstunarvandamála. Hægir fyrirspurnaskrár, skýrslur um leynd vandamál eða tölfræði um framkvæmdartíma geta hjálpað til við að bera kennsl á fyrirspurnir sem þarfnast hagræðingar.

Sumar mælikvarðar sem skipuleggjandi fyrirspurna leggur fram geta verið háð hávaða (sérstaklega þegar leynd eða örgjörvatími er metinn). Góð viðbót við tímasetningar eru verkfæri til að rekja og rekja framkvæmdarslóðina. Þeir gera þér kleift að greina slík vandamál (því miður, ekki öll DBMS bjóða upp á slík verkfæri).

Flutningur á netinu er erfiður en mögulegur

Flutningur á netinu, flutningur í beinni eða rauntímaflutningur þýðir að flytja úr einum gagnagrunni í annan án niður í miðbæ eða gagnaspillingu. Lifandi flutningur er auðveldara að framkvæma ef umskiptin eiga sér stað innan sömu DBMS/vélarinnar. Staðan verður flóknari þegar nauðsynlegt er að fara yfir í nýtt DBMS með mismunandi frammistöðu- og skemakröfur.

Það eru mismunandi flutningslíkön á netinu. Hér er ein af þeim:

Virkjaðu tvöfalda færslu í báðum gagnagrunnum. Nýi gagnagrunnurinn á þessu stigi hefur ekki öll gögnin heldur tekur aðeins við nýjustu gögnunum. Þegar þú ert viss um þetta geturðu haldið áfram í næsta skref.
Virkjaðu lestur úr báðum gagnagrunnum.
Stilltu kerfið þannig að lestur og ritun fari fyrst og fremst fram á nýja gagnagrunninum.
Hættu að skrifa í gamla gagnagrunninn á meðan þú heldur áfram að lesa gögn úr honum. Á þessu stigi er nýi gagnagrunnurinn enn laus við nokkur gögn. Þeir ættu að vera afritaðir úr gamla gagnagrunninum.
Gamli gagnagrunnurinn er skrifvarinn. Afritaðu gögnin sem vantar úr gamla gagnagrunninum yfir í þann nýja. Eftir að flutningi er lokið skaltu skipta um slóðir yfir í nýja gagnagrunninn og stöðva þann gamla og eyða honum úr kerfinu.

Fyrir frekari upplýsingar mæli ég með að hafa samband grein, sem lýsir flutningsstefnu Stripe sem byggir á þessu líkani.

Veruleg aukning gagnagrunnsins hefur í för með sér aukinn ófyrirsjáanleika

Vöxtur gagnagrunnsins leiðir til ófyrirsjáanlegra vandamála sem tengjast umfangi hans. Því meira sem við vitum um innri uppbyggingu gagnagrunns, því betur getum við spáð fyrir um hvernig hann mun stækka. Hins vegar er enn ómögulegt að sjá fyrir sum augnablik.
Eftir því sem grunnurinn stækkar geta fyrri forsendur og væntingar varðandi gagnamagn og netbandbreiddarkröfur orðið úreltar. Þetta er þegar spurningin vaknar um meiriháttar endurbætur á hönnun, stórfelldum rekstrarumbótum, endurhugsun um uppsetningu eða flutning til annarra DBMS til að forðast hugsanleg vandamál.

En ekki halda að framúrskarandi þekking á innri uppbyggingu núverandi gagnagrunns sé það eina sem er nauðsynlegt. Nýir vogir munu bera með sér nýja óþekkta hluti. Ófyrirsjáanlegir sársaukapunktar, ójöfn gagnadreifing, óvænt bandbreidd og vélbúnaðarvandamál, sívaxandi umferð og nýir nethlutar munu neyða þig til að endurskoða gagnagrunnsaðferðina þína, gagnalíkan, dreifingarlíkan og gagnagrunnsstærð.

...

Á þeim tíma sem ég fór að hugsa um að birta þessa grein voru þegar fimm atriði til viðbótar á upprunalega listanum mínum. Svo kom gríðarlegur fjöldi nýjar hugmyndir um hvað annað er hægt að fjalla um. Þess vegna snertir greinin minnst augljós vandamál sem krefjast hámarks athygli. Hins vegar þýðir þetta ekki að efnið hafi verið útrætt og ég mun ekki fara aftur að því í framtíðarefninu mínu og mun ekki gera breytingar á því sem nú er.

PS

Lestu líka á blogginu okkar:

Heimild: www.habr.com

Fleiri forritarar ættu að vita þetta um gagnagrunna