DBA-bot Joe. Anatoli Stanşler (Postgres.ai)

Kuidas backend-arendaja mõistab, et SQL-päring töötab hästi "produs"? Suurtes või kiiresti kasvavates ettevõtetes ei ole juurdepääs "prodile" kaugeltki kõigil. Ja isegi juurdepääsuga ei saa kõiki päringuid valutult kontrollida ning andmebaasi koopia loomine võtab sageli tunde. Nende probleemide lahendamiseks lõime tehisliku DBA - Joe. Ta on juba edukalt rakendatud mitmes ettevõttes ja aitab rohkem kui kümnel arendajal.

Video:

Tere kõigile! Minu nimi on Anatoli Stancler. Töötan ettevõttes Postgres.ai. Me tegeleme sellega, et kiirendada arendamisprotsessi, eemaldades arendajate, DBA-de ja QA-de hilinemised, mis on seotud Postgresiga.

Meil on suurepärased kliendid ja täna on osa ettekandest pühendatud juhtumitele, millega me oleme kohtunud. Räägin, kuidas me aitasime neil lahendada üsna tõsiseid probleeme.

Kui me viibime arenduses ja teeme keerulisi, suurt koormust nõudvaid migreerimisi, küsime endalt: "Kas see migratsioon õnnestub?". Me kasutame ülevaateid, me kasutame kogenumate kolleegide ja DBA-spetsialistide teadmisi. Nad suudavad öelda – kas see õnnestub või mitte.

Ent võib-olla oleks parem, kui saaksime seda ise testida täiskopeerimiste peal. Täna räägimegi lähenemistest testimisele ning kuidas seda paremini teha ja milliseid tööriistu kasutada. Räägime ka nende lähenemiste plussidest ja miinustest ning mida me saame siin parandada.

Kes on kunagi produl indeksid või mõningaid muudatusi teinud? Üsna palju inimesi. Ja kellel see viis andmete kadumiseni või seisakute tekkimiseni? Siis on see valu teile tuttav. Õnneks on varukoopiad olemas.

Esimene lähenemine – testimine produ. Või kui arendaja istub oma kohalikul masinal, tal on testandmed, on olemas mingisugune piiratud valik. Ja me viime selle produ ja saame sellise olukorra.

See on valus, see on kallis. Ilmselt oleks parem mitte nii teha.

Kuidas oleks parem teha?

Võtame stseeni ja eraldame sinna osa produs. Või parimal juhul võtame ehtsa produ, kõik andmed. Ja pärast seda, kui oleme kohapeal arendanud, kontrollime täiendavalt ka stseenis.

See võimaldab meil teatavad vead eemaldada, st mitte lasta neid produsse.

Millised probleemid on?

• Probleem on selles, et jagame seda stagingut kolleegidega. Ja sageli juhtub nii, et teed muudatuse ja bum – andmed on kadunud, töö on raisku läinud. Staging oli mitme terabaidi suurune. Ja tuleb kaua oodata, kuni see taas tööle hakkab. Otsustasime, et täiendame seda homme. Kõik, arendus on seisma jäänud.
• Ja muidugi töötab seal palju meie kolleege, palju meeskondi. Ja peab käsitsi kooskõlastama. See on ebamugav.

Ja tuleb märkida, et meil on ainult üks katse, üks lask, kui soovime andmebaasi teha mingeid muudatusi, andmeid kätte võtta või struktuuri muuta. Ja kui midagi läheb valesti, kui migratsioonis on viga, siis me ei saa enam kiirelt tagasi minna.

See on parem kui eelmine lähenemine, aga tõenäosus, et mõni viga läheb productionisse, on endiselt suur.

Mis takistab meil anda igale arendajale testimistendi, täismahulise koopia? Ma arvan, et on selge, mis seda takistab.

Kellel on andmebaas, mis on suurem kui terabait? Rohkem kui pooltel saalist.

Ja on selge, et hoida masinad iga arendaja jaoks, kui production on nii suur, on väga kallis ja võtab ka aega.

Meil on kliente, kes on aru saanud, et kõik muudatused tuleb testida täismahuliste koopiatega, kuid nende andmebaas on väiksem kui terabait ning ressurssi, et igale arendajale hoida testimistendi, ei ole. Seetõttu peavad nad andme dump'e oma kohalikku arvutisse alla laadima ja nii testima. See võtab tohutult aega.

Isegi kui teete seda infrastruktuuri sees, on üks terabait andmete allalaadimine tunnis juba väga hea. Kuid nad kasutavad loogilisi dump'e, nad laadivad kohalikult alla cloud'ist. Nende jaoks on kiirus umbes 200 gigabitti tunnis. Ja lisaks on vajalik aeg, et loogilisest dump'ist üles ehitada, indekseid rakendada jne.

Aga nad kasutavad seda lähenemist, sest see võimaldab hoida prod'i usaldusväärsena.

Mida me siin teha saame? Teeme nii, et testimistendid oleksid odavad ja anname igale arendajale tema enda testimistendi.

Ja sedasi on võimalik.

Ja selle lähenemisega, kus loome iga arendaja jaoks õhukesed kloonid, saame selle ühe masina peale jagada. Näiteks kui teie andmebaas on neli terabaiti ja soovite selle anda kümnele arendajale, ei pea teil olema kümme nelja terabaiti andmebaasi. Ühe masina olemasolu piisab, et teha iga arendaja jaoks õhukesed isoleeritud koopiad, kasutades ühte masina. Kuidas see toimib, räägin veidi hiljem.

Tegelik näide:

• Andmebaas – 4,5 terabaiti.

• Saame sõltumatud koopiad 30 sekundi jooksul.

Te ei pea ootama testimise seadet ja sõltuma selle suurusest. Te saate selle sekunditega. Need saavad olema täielikult isoleeritud keskkonnad, kuid jagavad omavahel andmeid.

See on lahe. Siin räägime maagisest ja paralleelsest universumist.

Meie puhul töötab see OpenZFS süsteemi kaudu.

OpenZFS on copy-on-write failisüsteem, mis toetab juba alguses äratarnimist momentfotode ja kloonide jaoks. See on usaldusväärne ja skaleeritav. Selle haldamine on äärmiselt lihtne. Selle saab sõna otseses mõttes kahe käsuga juurutada.

On ka teisi variante:

• LVM,

• Storage Array (näiteks Pure Storage).

Database Lab, millest ma räägin, on modulaarne. Seda on võimalik rakendada, kasutades selliseid variante. Kuid seni oleme keskendunud OpenZFS-ile, kuna LVM-iga olid probleemid.

Kuidas see töötab? Selle asemel, et andmeid iga kord, kui me neid muudame, uuesti kirjutada, salvestame need, märkides lihtsalt, et need uued andmed kuuluvad uue ajamomendi, uue momentfotod juurde.

Ja siis, kui tahame tagasi minna või teha uue klooni mingi vanema versiooniga, ütleme lihtsalt: "Olgu, andke meile need andmeplokid, mis on nii märgistatud."

Ja see kasutaja töötab sellise andmestiku kogumiga. Ta muudab neid järk-järgult, luues oma momentfotod.

Ja meil tekib hargnemine. Igal arendajal meie puhul on võimalus omada oma klooni, mida ta toimetab, ja need andmed, mis on ühised, jagatakse kõigi vahel.

Selle süsteemi juurutamiseks tuleb lahendada kaks probleemi:

• Esimene on andmeallikas, kust te neid võtate. Saate seadistada replikeerimise produktsiooniga. Saate kasutada juba backup'e, mis teil on loodud, ma loodan. WAL-E, WAL-G või Barman. Isegi kui kasutate mingisugust Cloud-lahendust, näiteks RDS-i või Cloud SQL-i, võite kasutada loogilisi dump'e. Kuid soovitame siiski kasutada backup'e, sest selle lähenemise korral säilitate ka failide füüsilise struktuuri, mis aitab teil hoida lähedust nendele mõõdikutele, mida näeksite produktsioonis, et avastada olemasolevaid probleeme.

• Teine on koht, kus soovite Database Labi hostida. See võib olla Cloud või On-premise. Siin on oluline öelda, et ZFS toetab andmete tihendamist. Ja teeb seda üsna hästi.

Kujutage ette, et igal sellisel kloonil, sõltuvalt nendest toimingutest, mida me andmebaasiga teeme, hakkab kuhjuma mingi dev. Selle dev jaoks on samuti vajalik ruum. Kuid kuna me võtsime andmebaasi, mis on 4,5 terabaiti, suudab ZFS selle tihendada 3,5 terabaitini. Sõltuvalt seadistustest võib seda varieerida. Ja meil on veel dev jaoks ruumi.

Sellist süsteemi saab kasutada erinevates juhtumites.

• Need on arendajad, DBA, kes kontrollivad päringuid, et optimeerida.

• Seda saab kasutada QA-testimisel konkreetse migratsiooni kontrollimiseks enne, kui me selle produktsiooni lükkame. Samuti saame luua spetsiaalse keskkonna QA jaoks reaalsete andmetega, kus nad saavad uusi funktsioone testida. Ja see võtab sekundeid, mitte tunde või isegi päevi, nagu mõnes teises olukorras, kus õhukesi kloone ei kasutata.

• Ja veel üks erijuhtum. Kui ettevõttes ei ole analüüsisüsteemi seadistatud, saame välja tuua õhukese klooni tootmisandmebaasist ja anda selle pikaajalistele päringutele või spetsiaalsetele indeksitele, mida analüüsis võib kasutada.

Sellega lähenemisega:

1. On madal vigade tõenäosus "produksioonis", sest me oleme kõik muudatused testinud täismahus andmetel.

2. Köitub testimise kultuur, kuna nüüd ei pea te tundide kaupa ootama omaenda keskkonda.

3. Ja pole takistusi, pole ootamist testimiste vahel. Sa saad tõesti minna ja kontrollida. Ja nii on parem, sest me kiirendame arendust.

• Refaktoreerimist on vähem. Vigu satub prod'i vähem. Me refaktoreerime neid hiljem vähem.

• Me saame teha pöördumatuid muudatusi. Seda standardsetes lähenemisviisides ei ole.

1. See on kasulik, kuna jagame testakeskuste ressursse.

See on juba hea, aga mida veel saaks kiirendada?

Sellise süsteemi tõttu saame oluliselt vähendada sisenemise takistust sellisesse testimisse.

Praegu on kinni ring, kus arendaja peab, et saada juurdepääs tõelistele täismõõtmetele, muutuma eksperdiks. Talle peab selline juurdepääs olema usaldatud.

Aga kuidas kasvada, kui seda ei ole. Aga mida teha, kui sul on juurdepääs ainult väga väikesele testandmete kogumile? Siis ei saa tõelist kogemust.

Kuidas sellest ringist välja tulla? Esimese liidese jaoks, mis sobib igasuguste arendajate tasemele, valisime Slack-boti. Aga see võib olla ka mõni muu liides.

Mida see võimaldab teha? Sa saad võtta konkreetse päringu ja saata selle spetsiaalsesse kanalisse andmebaasi. Me deploy'ime automaatselt sekundite jooksul õhukese klooni. Käivitame selle päringu. Kogume metriika ja soovitusi. Näitame visualiseerimist. Ja see kloon jääb edasi, et seda päringut saaks kuidagi optimeerida, lisada indekseid jne.

Ja Slack annab meile samuti välja pakutud koostöö võimalused. Kuna see on lihtsalt kanal, saab otse seal thread'is selle päringu arutelu alustada, pingida oma kolleege, DBA'sid, kes on ettevõtte sees.

Aga loomulikult on ka probleeme. Kuna see on tõeline maailm ja me kasutame serverit, millel hostime korraga palju kloone, peame piirama mälu ja protsessorivõimsuse koguseid, mis on kloonidele kättesaadavad.

Aga et need testid oleksid usutavad, tuleb see probleem kuidagi lahendada.

On selge, et oluline punkt on samad andmed. Aga seda meil juba on. Ja me tahame saavutada sama konfiguratsiooni. Ja me saame anda praktiliselt sama konfiguratsiooni.

Oleks lahe omada sama riistvara nagu tootmises, kuid see võib erineda.

Mäletagem, kuidas Postgres mälu kasutab. Meil on kaks vahemälu. Üks failisüsteemist ja teine omalt poolt Postgres, st Shared Buffer Cache.

Oluline on märkida, et Shared Buffer Cache eraldatakse Postgresi käivitamisel vastavalt sellele, millise suuruse te konfiguratsioonis määrate.

Ja teine ​​päringukäivitus kasutab kogu saadaval ruumi.

Ja kui me teeme mitmeid kloone ühel masinal, siis täitame järk-järgult mälu. Ja ideaalis peaks Shared Buffer Cache olema 25% kogu masinas saadaval olevast mälu mahust.

Ja selgub, et kui me seda parameetrit ei muuda, saame ühel masinal käivitada vaid 4 instantsi, st kokku 4 sellist õhukest klooni. Ja see on muidugi halb, sest tahaksime neid palju rohkem omada.

Aga teisest küljest kasutatakse Buffer Cache'i päringute täitmiseks, indeksite jaoks, st plaan sõltub sellest, kui suured meie kased on. Ja kui me lihtsalt võtame selle parameetri ja vähendame, võivad meie plaanid oluliselt muutuda.

Näiteks kui prod-s on meil suur vahemälu, siis Postgres eelistab indeksit. Aga kui pole, siis on SeqScan. Mis mõte oleks, kui meie plaanid ei ühtiks?

Aga siin jõuame sellise lahenduseni, et tegelikult plaan Postgresis ei sõltu konkreetsest Shared Bufferi suurusest plaanis, vaid see sõltub effective_cache_size'ist.

Effective_cache_size on eeldatav vahemälu maht, mis meile kätte saadaval on, st Buffer Cache ja failisüsteemi vahemälu kokku. See määratakse konfiguratsiooni kaudu. Ja seda mälu ei eraldata.

Ja selle parameetri tõttu saame Postgrest natuke petta, öeldes, et meile on tegelikult palju andmeid kätte saadaval, isegi kui neid andmeid meil ei ole. Ja seega plaanid vastavad täpselt produktsioonile.

Aga see võib mõjutada ajastust. Ja optimeerime päringud ajastuse järgi, kuid oluline on, et ajastus sõltub paljuski erinevatest teguritest:

• Sõltub hetkel toimuvast koormusest produktiivses keskkonnas.

• Sõltub masina omadustest.

Ja see on kaudne parameeter, kuid tegelikult saame optimeerida just selle põhjal, kui palju andmeid see päring loeb, et saada tulemus.

Ja kui soovite, et ajastus oleks võimalikult sarnane sellele, mida näeme prod-is, peame valima võimalikult sarnase riistvara ja võib-olla isegi rohkem, et kõik kloonid mahtuda. Kuid see on kompromiss, st saate sarnased plaanid, näete, kui palju andmeid konkreetne päring loeb, ja saate teha järelduse – on see päring hea (või migratsioon) või halb, seda tuleb veel optimeerida.

Vaatame, kuidas Joe optimeerimine täpsemalt käib.

Võtame päringu reaalsest süsteemist. Antud juhul on andmebaas – 1 terabyte. Ja me soovime arvutada värskete postituste arvu, millel on rohkem kui 10 meeldimist.

Me saadame sõnumi kanalisse, kloon lahti. Ja me näeme, et selline päring kulgeb 2,5 minutiga. See on esimene asi, mida me märkame.

B Joe näitab automaatseid soovitusi, mis põhinevad plaanil ja mõõtmetel.

Me näeme, et päring töötleb liiga palju andmeid, et saada suhteliselt vähe ridu. Ja vajalik on mingi spetsialiseeritud indeks, kuna me oleme märganud, et päringus on liiga palju filtreeritud ridu.

Vaatame lähemalt, mis juhtus. Tõepoolest, me näeme, et lugesime peaaegu poolteist gigabaiti andmeid failiküst või isegi kettalt. Ja see pole hea, kuna saime vaid 142 rida.

Ja näiliselt on meil siin indeksiskann ja see peaks olema kiiresti täidetud, kuid kuna me filtreerisime liiga palju ridu (me pidime neid arvestama), kulges päring aeglaselt.

Ja see juhtus plaanis, kuna päringu ja indeksi tingimused ei ühtinud osaliselt.

Vaatame, kas suudame indeksi täpsemaks teha ja vaatame, kuidas päringu täitmine pärast seda muutub.

Indeksi loomine võttis palju aega, kuid nüüd kontrollime päringut ja näeme, et aeg 2,5 minutist on nüüd vaid 156 millisekundit, mis on piisavalt hea. Ja loeme vaid 6 megabaiti andmeid.

Ja nüüd kasutame ainult indeksi skannimist.

Teine oluline teema on see, et soovime plaani esitada selgemal viisil. Oleme rakendanud visuaali koos Flame Graphsiga.

See on teine päring, rikkalikum. Ja Flame Graphs'i ehitame kahe parameetri põhjal: see on andmete hulk, mida konkreetne sõlm plaanis luges, ja ajastus, st sõlme täitmise aeg.

Siin saame konkreetselt sõlmede vahel võrrelda. Ja on selge, milline neist võtab rohkem või vähem ruumi, mida tavaliselt on keeruline teha teiste visualiseerimismeetodite puhul.

Loomulikult teavad kõik explain.depesz.com. Selle visualiseerimise hea omadus on see, et salvestame tekstiplaani ja toome välja mõned olulised parameetrid tabelisse, et oleks võimalik sorteerida.

Ja arendajad, kes ei ole sellesse teemasse süvenenud, kasutavad samuti explain.depesz.com, kuna neile on lihtsam mõista, millised mõõdikud on olulised ja millised mitte.

On olemas uus visuaaliseerimise lähenemine – explain.dalibo.com. Nad teevad puu-struktuuri visualiseerimise, kuid siin on sõlmede omavaheline võrdlemine väga keeruline. Siin on võimalik hästi mõista struktuuri, tõsi, kui päring on suur, tuleb skrullida edasi-tagasi, aga see on ka variant.

Koostöö

Ja nagu ma juba ütlesin, annab Slack meile koostöö võimaluse. Näiteks kui me kohtame keerulist päringut, mille optimeerimine ei ole selge, saame Slackis selle küsimuse oma kolleegidega arutada.

Meie arvates on oluline katsetada täismõõdus andmetega. Selleks oleme loonud tööriista Update Database Lab, mis on avatud allikaga. Saate kasutada ka Joe bot'i. Saate selle otse praegu võtta ja endale rakendada. Kõik juhendid on seal saadaval.

Oluline on märkida, et lahendus ise ei ole revolutsiooniline, kuna on olemas Delphix, kuid see on ettevõtte lahendus. See on täielikult suletud ja maksab väga palju. Me spetsialiseerume Postgres'ile. Need on kõik avatud allika tooted. Liituge meiega!

Sellega lõpetan. Aitäh!

Küsimused

Tere! Aitäh ettekande eest! Väga huvitav, eriti minu jaoks, kuna ma olen mõni aeg tagasi lahendanud sarnase ülesande. Seetõttu on mul terve hulk küsimusi. Loodan, et suudan vähemalt osa nendest esitada.

Huvitav, kuidas te selle keskkonna jaoks ruumi arvutate? Tehnoloogia eeldab, et teatud tingimustes võivad teie kloonid kasvada maksimaalsesse suurusesse. Ükskõik kui palju, kui teil on kümme terabaidi andmebaas ja 10 klooni, on lihtne simuleerida olukorda, kus iga kloon kaalub 10 unikaalset andmestikku. Kuidas te seda ruumi arvutate, st seda delta, millest rääkisite, kus need kloonid elavad?

Hea küsimus. Siin on oluline jälgida konkreetseid kloone. Kui mõni kloon muutub liiga suureks ja hakkab kasvama, saame kõigepealt kasutajale selle kohta hoiatuse anda või kohe selle klooni peatada, et meil ei tekiks ebaõnnestumise olukorda.

Jah, mul on seotud küsimus. Ehk siis, kuidas te tagate nende moodulite elutsükli? Meil on see probleem ja eraldi lugu. Kuidas see toimub?

Iga klooni puhul on mingisugune ttl. Põhimõtteliselt on meil fikseeritud ttl.

Kui kaua, kui saladus ei ole?

1 tund, st kui see on mitteaktiivne – 1 tund. Kui seda ei kasutata, siis me hävitame selle. Aga siin pole midagi üllatavat, sest me saame klooni tõsta sekunditega. Ja kui see uuesti vajalikuks osutub, siis – palun.

Technoloogiate valik huvitab mind ka, sest näiteks kasutame me paralleelselt mitmeid viise erinevatel põhjusel. Miks just ZFS? Miks te ei kasutanud LVM-i? Te mainisite, et LVM-iga oli probleeme. Millised need probleemid olid? Minu arvates on kõige optimaalsem variant SCSI puhul, tootlikkuse mõttes.

Mis on ZFS-i peamine probleem? See, et pead töötama ühel hostil, st kõik instantsid elavad ühe operatsioonisüsteemi raames. SCSI puhul saad aga ühenduda erinevate seadmetega. Kitsaskohad on ainult need blokid, mis on SCSI-l. Ja küsimus on just tehnoloogiate valikus. Miks mitte LVM?

LVM-i kohta saame rääkida kohtumisel. SCSI osas – see on lihtsalt kallis. ZFS-i süsteemi saame juurutada kus iganes. Sa võid selle oma masinas seadistada. Sa saad lihtsalt alla laadida repot ja selle üles seada. ZFS töötab praktiliselt igal pool, kui me räägime Linuxist. Ehk saame väga paindliku lahenduse. Ja ZFS ise on karbist välja väga palju pakkuda. Sa saad sinna laadida piiramatult andmeid, ühendada palju kettaid, seal on snapshots. Ja nagu ma juba mainisin, on seda lihtne administreerida. Ehk siis see paistab kasutamisel väga mugav. See on testitud, see on olemas olnud juba kaua. Sellel on väga suur kogukond, mis kasvab. ZFS on väga usaldusväärne lahendus.

Nikolai Samohvalov: Kas ma võin veel kommenteerida? Minu nimi on Nikolai, me töötame koos Anatoliiga. Olen nõus, et SCSI on suurepärane. Ja mõnedel meie klientidel on näiteks Pure Storage jne.

Anatoli õigesti märkis, et meie eesmärk on modulaarne lähenemine. Tulevikus võib realiseerida ühe liidese – tee snapshot, tee kloon, hävita kloon. See kõik on lihtne. Ja salvestusseade on suurepärane, kui see on olemas.

Aga ZFS on kõigile kättesaadav. Alates DelPhix'ist on neid juba piisavalt, neil on 300 klienti. Neist Fortune 100 is on 50 klienti, see tähendab, et nad sihivad NASA-d jne. On aeg, et see tehnoloogia oleks kätte saadav kõigile. Seetõttu on meil avatud lähtekoodiga põhituum. Meil on osa liidest, mis ei ole avatud lähtekoodiga. See on platvorm, mida me näitame. Aga me tahame, et see oleks kätte saadav igaühele. Me soovime teha revolutsiooni, et kõik testijad lõpetaksid aimamise sülearvutites. Me peame kirjutama SELECT ja kohe nägema, et see on aeglane. Ei ole enam aega oodata, et DBA sellest räägib. See on meie peamine eesmärk. Ja ma arvan, et me jõuame sinna kõik. Ja seda me teeme, et see oleks kõigile kätte saadav. Seetõttu ZFS, sest see saab olema kättesaadav igal pool. Aitäh kogukonnale probleemide lahendamise eest ja selle eest, et seal on avatud lähtekoodi litsents jne.

Tere! Aitäh ettekande eest! Minu nimi on Maksim. Me lahendasime samu probleeme. Meil endal on see lahendatud. Kuidas te jagate ressursse nende kloonide vahel? Iga kloon võib igal ajahetkel tegeleda oma asjadega: üks testib ühte, teine teist, kellelgi on indeks ehitamisel, kellelgi on raskem töö. Ja kui CPU on võimalik jagada, siis kuidas te jagate IO-d?

Teine küsimus ebaühtlike keskkondade kohta. Oletame, et mul on siin ZFS ja kõik on suurepärane, aga kliendil tootmises on ext4, näiteks. Kuidas sellisel juhul käib?

Küsimused on väga head. Mainisin veidi seda probleemi seoses ressursside jagamisega. Lahendus on järgmine. Kujutage ette, et te testite stagingus. Ka seal võib samal ajal tekkida olukord, kus keegi toob ühe koormuse, keegi teine teise. Ja lõpuks te näete arusaamatuid mõõdikuid. Sama probleem võib olla tootmises. Kui soovite kontrollida mingit päringut ja näete, et sellega on mingi probleem – see töötab aeglaselt, siis tegelikult ei olnud probleem päringus, vaid see, et mõni teine koormus on paralleelselt käimas.

Seetõttu on oluline keskenduda sellele, milline plaan on, kuidas me plaanis edasi liigume ja kui palju andmeid me selleks üles tõstame. Kui näiteks meie kettad on millegagi koormatud, mõjutab see kindlasti ajakava. Ent me saame andmete arvu põhjal hinnata, kui koormatud see päring on. Ei ole nii tähtis, et samal ajal on ka mõni muu täitmine.

Mul on kaks küsimust. See on väga äge asi. Kas on olnud juhtumeid, kus andmed tootmises on kriitilise tähtsusega, näiteks krediitkaardinumbrid? Kas on juba midagi valmis või on see eraldi ülesanne? Ja teine küsimus – kas MySQL jaoks on midagi sellist olemas?

Andmete osas. Me teeme obfuskeeringut, seni kuni me ei tee seda. Kuid kui te käitate Joe't, kui te ei anna arendajatele juurdepääsu, siis ligipääsu andmetele ei ole. Miks? Sest Joe ei näita andmeid. Ta näitab ainult mõõdikuid, plaane ja kõik. See tehti spetsiaalselt, kuna see on üks meie kliendi nõuetest. Nad soovisid võimalust optimeerida, kuid mitte anda kõigile juurdepääsu.

MySQL-i osas. Seda süsteemi saab kasutada igasuguste asjade jaoks, mis salvestavad olekut kettale. Ja kuna me tegeleme Postgres'iga, siis esmalt teeme me täielikult automatiseerimise Postgres'ile. Me tahame automatiseerida andmete saamist varukoopiast. Me konfigureerime Postgres'i õigesti. Me teame, kuidas teha nii, et plaanid kattuksid jne.

Kuna süsteem on skaleeritav, saab seda kasutada ka MySQL-i jaoks. Sellised näited on olemas. Sarnane asi on Yandexil, aga nad ei avalda seda kuskil. Nad kasutavad seda Yandex.Metrixis. Seal on just MySQL-i lugu. Kuid tehnoloogiad on samad, ZFS.

Aitäh ettekande eest! Mul on ka paar küsimust. Te mainisite, et kloonimist saab kasutada analüüsiks, näiteks seal lisaindeksite koostamiseks. Kas saaksite veidi lähemalt rääkida, kuidas see töötab?

Ja annan kohe teise küsimuse seoses ühtlasele seadmestikule ja ühtlasele plaanile. Plaan sõltub ka statistikatest, mida Postgres kogub. Kuidas te selle probleemi lahendate?

Konkreetsete juhtumite analüüsist ei ole midagi, kuna me pole veel seda kasutanud, kuid selline võimalus on olemas. Kui räägime indeksitest, siis kujutage ette, et tabelis, kus on sadu miljoneid kirjeid, tehakse päringud veerule, mis tavaliselt ei ole tootmises indekseeritud. Ja me tahame seal mingid andmed välja lugeda. Kui see päring tootmises käivitada, on võimalus, et tootmises tekib seiskumine, kuna päring võib seal kesta minuteid.

Olgu, teeme peene klooni, mida pole hirmus paariks minutiks peatada. Ja et oleks mugavam analüütikat arvutada, lisame indeksid neile veergudele, mis meid huvitavad.

Kas indeks luuakse iga kord uuesti?

Saame teha nii, et puutume andmete külge, teeme snapshot'id ning taastume seejärel nendelt snapshot'idelt ja käivitame uued päringud. Ehk saame tõsta uusi kloone juba olemasolevate indeksitega.

Mis puutub statistika küsimusse, siis kui me taastume varukoopiast, kui me teeme replikatsiooni, siis meie statistika on kindlasti sama. Sest me toome kogu füüsilise andmestruktuuri, ehk andmed koos kõigi statistika meetritega.

Siin on teine probleem. Kui teie jaoks on kasutuses pilve lahendus, siis seal on saadaval vaid loogilised dump'id, sest Google ja Amazon ei luba võtta füüsilist koopiat. See tekitab probleemi.

Aitäh ettekande eest. Siin kõlas kaks head küsimust MySQL'i ja ressursside jagamise kohta. Kuid põhimõtteliselt, kõik kokkuvõttes viib meid sellele, et see teema ei ole seotud konkreetsete andmebaasimootorite, vaid üldiselt failisüsteemiga. Seega, ressursside jagamise küsimused tuleks lahendada sealt, mitte lõpus, et see on Postgres, vaid failisüsteemis. serveris, instantsis.

Minu küsimus on veidi erinev. See on rohkem suunatud andmebaasi mitmekihilisusele, kus on mitu kihti. Näiteks, me oleme seadnud ülesande kümnete terabaitide pildi värskendamiseks, mille puhul toimub replikatsioon. Ja me kasutame seda lahendust konkreetselt andmebaaside jaoks. Replikatsioon toimub, andmed uuendatakse. Samal ajal töötab 100 töötajat, kes pidevalt käivitavad erinevaid snapshot'e. Mida teha? Kuidas vältida konflikti, et nad käivitasid ühe ja siis failisüsteem muutus ning need snapshot'id kõik läksid segamini?

Nad ei sõida, kuna ZFS töötab nii. Saame hoida eraldi ühes voos failisüsteemi muudatusi, mis tänu replikatsioonile tulevad. Ja hoida klone vanadel andmeversioonidel, mida arendajad kasutavad. See töötab meil, sellega on kõik korras.

Tuleb välja, et uuendus toimub nagu täiendav kiht ja kõik uued haarangud tulevad juba selle kihi põhjal, jah?

Eelmiste kihtide põhjal, mis tulid eelmiste replikatsioonidega.

Eelmised kihid kukuvad ära, aga nad viitavad vanale kihile, ja uued pildid saavad olema viimase kihi põhjal, mis saadi uuendamise käigus?

Üldiselt, jah.

Seejärel on meil palju kihte. Ja aja jooksul tuleb neid tihendada?

Jah, täiesti õige. On mingi aken. Hoidame nädalasi haaranguid. See sõltub, milline ressurss teil on. Kui teil on võimalus hoida palju andmeid, siis saab haaranguid pikka aega hoida. Need ei kustuta ennast. Andmete rikkumist ei toimu. Kui haarangud on vananenud, nagu me arvame, st see sõltub ettevõtte poliitikast, siis saame need lihtsalt kustutada ja ruumi vabastada.

Tere, aitäh ettekande eest! Joe küsimuse kohta. Te ütlesite, et kliendile ei soovitud andmetele juurdepääsu anda. Täpselt öeldes, kui inimesel on Explain Analyze tulemus, siis ta võib andmeid vaadata.

Just nii. Näiteks võime kirjutada: "SELECT FROM WHERE email = kellelegi". St me ei näe andmeid, aga mõningaid kaudseid märke saame vaadata. Seda tuleb mõista. Aga teisest küljest on see kõik nähtav. Meil on logide audit, meil on kolleegide kontroll, kes samuti näevad, millega arendajad tegelevad. Ja kui keegi proovib nii teha, siis turvateenistus tuleb tema juurde ja tegeleb selle küsimusega.

Tere päevast! Aitäh ettekande eest! Mul on lühike küsimus. Kui ettevõttes Slacki ei kasutata, kas sellega on praegu mingisugune seos olemas või on arendajatele võimalik käivitada instantsid, et testrakendus saaks andmebaasidega ühendada?

Hetkel on ainult Slacki tugi, st ei ole ühtegi muud messengerit, kuid oleks väga mõnus toetada ka teisi messengerite. Mida te saate teha? Saate välja arendada oma DB Lab'i ilma Joe'ita, kasutada REST API-t või meie platvormi ning luua kloone ning ühendada PSQL-iga. Kuid seda saab teha, kui olete valmis andma oma arendajatele juurdepääsu andmetele, kuna siin ei ole enam mingit ekraani.

Mulle ei ole see vahekiht vajalik, vaid mul on vaja sellist võimalust.

Siis - jah, seda on võimalik teha.

Allikas: habr.com