DBA-bot Joe. Anatoli Stansler (Postgres.ai)

Kuidas backend-arendaja mõistab, et SQL-päring töötab tootmises hästi? Suurtes või kiiresti kasvavates ettevõtetes ei ole juurdepääs tootmisele kõigile. Ja isegi juurdepääsuga ei saa kõiki päringuid valutult kontrollida ning andmebaasi koopia loomine võtab sageli tunde. Selle probleemiga tegelemiseks lõime tehis DBA — Joe. Ta on juba edukalt rakendatud mitmes ettevõttes ja aitab kümneid arendajaid.

Video:

Tere kõigile! Minu nimi on Anatoli Stansler. Töötab ettevõttes Postgres.ai. Meie eesmärk on kiirendada arendusprotsessi, vähendades Postgres'iga seotud viivitusi arendajatel, DBA-l ja QA-l.

Meil on toredad kliendid ja täna pühendame osa oma ettekandest juhtumitele, millega oleme nende töö käigus kokku puutunud. Räägin, kuidas aitasime neil lahendada piisavalt tõsiseid probleeme.

Kui me teeme arengut ja teeme keerulisi koormatud migratsioone, küsime endalt: 'Kas see migratsioon õnnestub?'. Kasutame ülevaateid, kasutame kogenud kolleegide ja DBA-ekspertide teadmisi. Nemad saavad öelda, kas see õnnestub või mitte.

Kuid võib-olla oleks parem, kui saaksime seda testida täiskoopiates. Täna räägime, millised on praegused testimise lähenemisviisid, kuidas neid paremini rakendada ja milliseid tööriistu kasutada. Räägime ka nende lähenemiste eeliste ja puuduste üle ning sellest, mida saame siin parandada.

Kes on kunagi otse prod-s indekseid teinud või muudatusi teinud? Tõeliselt palju inimesi. Ja kellel on see viinud andmete kadumiseni või seiskumisteni? Siis on see valu teile tuttav. Õnneks on varukoopiad olemas.

Esimene lähenemine on testimine prod-s. Kas siis, kui arendaja töötab kohalikult, kasutades testandmeid ja piiratud valikut. Siis viime selle prod-sse ja saame sellise olukorra.

See on valus, see on kallis. Tõenäoliselt ei ole seda parem teha.

Kuidas siis paremini teha?

Võtame stagingi ja suuname sinna mingi osa prod-ist. Või parimal juhul võtame tõelise prod-i, kõik andmed. Ja pärast seda, kui oleme kohalikult arendanud, kontrollime seda veel ka stagingis.

See võimaldab meil eemaldada osa vigu, st näiteks mitte lubada prod-s.

Millised on probleemid?

• Probleem on selles, et jagame seda staging keskkonda kolleegidega. Ja väga sageli juhtub, et teed mingisuguse muudatuse, ja hop – ja mingeid andmeid ei ole, töö läheb raisku. Staging oli mitme terabaidi suurune. Ja selle uuesti käivitamine võtab kaua aega. Otsustame selle homseks edasi lükata. Meie arendus on peatunud.
• Ja muidugi töötab seal palju meie kolleegi, palju meeskondi. Ja me peame käsitsi koordineerima. See on ebamugav.

Ja tuleb öelda, et meil on ainult üks katse, üks võimalus, kui soovime andmebaasis mingeid muudatusi teha, andmeid puudutada, struktuuri muuta. Ja kui midagi läheb valesti, kui migratsioonis on viga, siis me ei saa kiiresti tagasi kerida.

See on parem kui eelmine lähenemine, kuid siiski on suur tõenäosus, et mõni viga jõuab tootmisse.

Miks ei saa igale arendajale anda testkeskkonda, täiskohaga koopiat? Ma arvan, et on selge, mis takistab.

Kellel on andmebaas, mis on suurem kui terabyte? Suuremal osal rahvast.

Ja on selge, et hoida masinate infrastruktuuri iga arendaja jaoks, kui tootmine on nii suur, on väga kallis ja ka aeganõudev.

Meil on kliente, kes mõistsid, kui oluline on kõik muudatused testida täismahus koopiatel. Kuid nende andmebaas on väiksem kui tera, ning ressursid, et iga arendaja jaoks testimisstandi hoida, puuduvad. Seetõttu peavad nad laadima dump'id oma kohalikule masinale ja testima seeläbi. See võtab palju aega.

Isegi kui teete seda infrastruktuuri sees, on ühe terabaiandmete allalaadimine tunnis juba väga hea saavutus. Kuid nad kasutavad loogilisi dump'e, laadides neid pilvest kohalikule masinale. Nende allalaadimise kiirus on umbes 200 gigabaiti tunnis. Ja lisaks on vaja aega, et loogilisest dump'ist taastuda, indekseid rakendada jne.

Kuid nad kasutavad seda lähenemist, kuna see võimaldab hoida tootmiskeskkonna usaldusväärsena.

Mida me siin teha saame? Teeme nii, et testimisstandid oleksid odavad ja anname igale arendajale oma isikliku testimisstandi.

Ja see on teostatav.

Ja ja, sellise lähenemisviisi korral, kus loome iga arendaja jaoks õhukesed kloonid, saame selle jagada ühel masinal. Näiteks kui teil on nelja terabaidi andmebaas ja soovite anda selle 10 arendajale, ei pea teil olema 10 x nelja terabaiti andmebaase. Üks masin piisab selleks, et luua iga arendaja jaoks õhukesed eraldatud koopiad, kasutades ühte masinat. Kuidas see töötab, selgitan natuke hiljem.

Reaalne näide:

• Andmebaas – 4,5 terabaiti.

• Saame saada iseseisvaid koopiaid 30 sekundiga.

Te ei pea ootama testimispinda ja sõltuma selle suurusest. Saate selle sekundite jooksul. Need on täielikult eraldatud keskkonnad, kuid jagavad andmeid omavahel.

See on äge. Siin räägime maagiast ja paralleelsest universumist.

Meie puhul toimib see OpenZFS süsteemi abil.

OpenZFS on copy-on-write failisüsteem, mis toob juba välja kastist toetuse snapshot'ide ja kloonide jaoks. See on usaldusväärne ja skaleeritav. Selle haldamine on väga lihtne. Saate selle kahe käsuga käivitada.

On ka teisi võimalusi:

• LVM,

• SAN (näiteks Pure Storage).

Andmebaasi labor, millest ma räägin, on modulaarsed. Seda saab rakendada kasutades erinevaid variante. Kuid praegu keskendume OpenZFS-ile, kuna LVM-iga olid konkreetselt probleeme.

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

Ja edaspidi, kui me soovime tagasi minna või teha uue klooni mingist vanemast versioonist, ütlemeki: „Olgu, palun andke meile need andmepangad, mis on nii tähistatud.“

Ja kasutaja töötab selliste andmete kogumiga. Ta hakkab neid järk-järgult muutma, luues oma snapshots.

Ja meil on hargnemine. Igal arendajal on meie puhul võimalus omada oma kloni, mida ta redigeerib, ning üldised andmed jagatakse kõikide vahel.

Sellise süsteemi käivitamiseks tuleb lahendada kaks probleemi:

• Esimene on andmeallikas, kust te andmeid võtate. Saab seadistada replikaate production'ist. Võite kasutada juba olemasolevaid varukoopiaid, loodan, et need on olemas. WAL-E, WAL-G või Barman. Kui kasutate mõnda pilvelahendust, näiteks RDS või Cloud SQL, võite kasutada loogilisi dump'e. Siiski soovitame kasutada varukoopiaid, kuna sellisel lähenemisel säilib ka failide füüsiline struktuur, mis aitab lähemale pääseda neile meetrikaile, mida näeksite production'is, et tuvastada olemasolevad probleemid.

• Teine on koht, kus soovite Database Labi majutada. See võib olla Cloud või On-premise. Oluline on märkida, et ZFS toetab andmete tihendamist. Ja teeb seda piisavalt hästi.

Kujutage ette, et igal sellisel kloonil, sõltuvalt toimingutest, mida me andmebaasiga teeme, hakkab kogunema mingi dev. Selleks tuleb ka dev'ile ruumi. Kuid kuna me võtsime andmebaasi 4,5 terabaiti, tihendab ZFS selle 3,5 terabaidiks. Sõltuvalt seadetest saab seda varieerida. Ja meil jääb veel ruumi dev'ile.

Sellist süsteemi saab kasutada erinevate juhtumite jaoks.

• Need to optimize database queries? Our developers and DBAs are here for you.

• This can be utilized in QA testing to validate specific migrations before we deploy to production. We can also create specialized environments for QA with real data, allowing for testing of new features. This process takes seconds instead of waiting hours or even days in cases where thin clones aren’t employed.

• Additionally, if the company lacks an analytics system, we can allocate a thin clone of the production database for long queries or for special indexes that could be used in analytics.

With this approach:

1. There is a low likelihood of errors in production since all changes have been tested on full-sized data.

2. We promote a culture of testing because there's no need to wait for hours for your own environment anymore.

3. There are no barriers or waiting times between tests. You can genuinely go and check. This improves the process as we accelerate development.

• Refactoring will be reduced. Fewer bugs will reach production. We will spend less time refactoring later.

• We can revert irreversible changes. This is not available in standard approaches.

1. This is beneficial because we share resources for testing environments.

It's already good, but what else could we enhance?

With such a system, we can significantly lower the entry barrier to this type of testing.

Currently, there is a vicious circle where a developer must become an expert to access real full-scale data. They have to be trusted with such access.

But how can one grow without it? And what if you only have access to a very small set of test data? Then you won't gain real experience.

How to break out of this cycle? As the first interface, convenient for developers at any level, we chose a Slack bot. However, it can be any other interface.

Mida see võimaldab teha? Saame võtta konkreetse päringu ja saata selle andmebaasi spetsiaalsesse kanalisse. Me loome automaatselt sekunditega õhukese klooni. Käitame selle päringu. Kogume metrikad ja soovitused. Näitame visualiseerimist. Ja edasi jääb see kloon selleks, et saaksime päringut kuidagi optimeerida, lisada indekseid jne.

Slack pakub meile ka koostöövõimalusi paketi sees. Kuna see on lihtsalt kanal, saab seal päringu kohta arutelu alustada, pingsida oma kolleege, DBA-sid, kes on ettevõttes.

Kuid muidugi on ka probleeme. Kuna see on reaalses maailmas ja kasutame serverit, kus toimetame mitme klooniga, peame piirama mälu ja protsessorivõimsuse hulka, mis kloonidele on kättesaadav.

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

On selge, et oluline aspekt on andmete ühtekuuluvus. Kuid see on meil juba olemas. Soovime saavutada sama konfiguratsiooni. Ja saame anda praktiliselt sama konfiguratsiooni.

Äge oleks omada sama riistvara nagu tootmises, kuid see võib erineda.

Tuletame meelde, kuidas Postgres mälu kasutab. Meil on kaks vahemälu. Üks failisüsteemist ja teine, Postgresi enda, st Shared Buffer Cache.

Oluline on märkida, et Shared Buffer Cache eraldatakse Postgresi käivitamisel sõltuvalt sellest, millise suuruse määrate konfiguratsioonis.

Teine vahemälu kasutab kogu saadaval oleva ruumi.

Ja kui teeme mitu klooni ühel masinal, siis hakkame järk-järgult mälu täitma. Ja ideaalis peaks Shared Buffer Cache olema 25% kogu mälu mahust, mis masinal on saadaval.

Selgub, et kui me seda parameetrit ei muuda, saame ühel masinal käitada ainult 4 instantsi, st 4 üsna õhukest klooni. Ja see pole muidugi hea, sest tahame neid palju rohkem.

Teiselt poolt kasutatakse Buffer Cache'i päringute täitmiseks, indeksite jaoks, st plaan sõltub sellest, kui suured meie vahemälud on. Ja kui me lihtsalt võtame selle parameetri ja vähendame seda, siis võivad meie plaanid oluliselt muutuda.

Näiteks, kui meil on produkus suur vahemälu, siis Postgres eelistab indeksi kasutamist. Kui ei, siis kasutatakse SeqScan'i. Mis oleks mõte, kui need plaanid ei klappiks?

Kuid siin jõuame selleni, et tõeliselt ei sõltu Postgres'e plaan konkreetsest Shared Buffer suurusest, vaid sellest, mida defineerib effective_cache_size.

Effective_cache_size on eeldatav vahemälu maht, mis meile kättesaadav on, st Buffer Cache ja failisüsteemi vahemälu kogumaht. See määratakse seadistustes. Ja see mälu ei ole eraldatud.

Selle parameetri tõttu saame me Petta Postgres'e, öeldes, et meil on tegelikult palju andmeid kättesaadavad, isegi kui meil neid andmeid pole. Niiviisi kattuvad plaanid täielikult tootmisest.

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

• See sõltub hetkelisest koormusest producuses.

• See sõltub masina omadustest.

Ja see on kaudne parameeter, kuid tõeliselt saame optimeerida just andmete hulga põhjal, mida see päring loeb, et saavutada tulemus.

Ja kui soovite, et ajastus oleks lähedane sellele, mida näeme tootmises, peame võtma maksimaalselt sarnase raudvara ja võib-olla isegi rohkem, et kõik kloonid ära mahuksid. Kuid see on kompromiss, see tähendab, et saate samasugused plaanid, näete, kui palju andmeid konkreetne päring loeb, ja saate järeldada – kas see päring on hea (või migratsioon) või halb, ja seda tuleb veel optimeerida.

Analüüsime, kuidas Joe optimeerimise protsess tegelikult käib.

Võtame päringu reaalsest süsteemist. Antud juhul on andmebaas 1 terabait. Ja me tahame arvutada värskete postituste arvu, millel on üle 10 meeldimise.

Kirjutame sõnumi kanalisse, kloon avanes meie jaoks. Ja me näeme, et selline päring töötab 2,5 minuti jooksul. See on esimene, mida me märkame.

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

Me näeme, et päring töötleb liiga palju andmeid, et saada suhteliselt väike rida. Ja on vajalik mõni spetsialiseeritud indeks, kuna 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 faili vahemälust või isegi diskilt. Ja see pole hea, kuna saime kätte vaid 142 rida.

Ja tundub, et meil on siin indeksiskane ja see pidi kiiresti töötama, kuid kuna filtreerisime liiga palju ridu (me pidime neid arvestama), töötas päring aeglaselt.

Ja see juhtus plaani tõttu, kuna päringu tingimused ja indeksi tingimused ei ühtinud osaliselt.

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

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

Ja nüüd kasutame ainult indeksiskane.

Teine oluline lugu on see, et me tahame plaani esitada arusaadavamal viisil. Oleme rakendanud visualiseerimist Flame Graphs abil.

See on teine, keerukam päring. Flame Graph-e ehitame kahest parameetrist: andmete hulgast, mida konkreetne sõlm on analüüsinud, ja ajast, st sõlme täitmise ajast.

Siin saame täpselt võrrelda sõlmi. On selge, milline neist nõuab rohkem või vähem, mis on tavaliselt teistes visualiseerimise meetodites keeruline.

Muidugi, kõik tunnevad explain.depesz.com'i. Selle visualiseerimise hea omadus on see, et me salvestame tekstiplani ja toome välja mõned peamised parameetrid tabelis, et saaksime need järjestada.

Ja arendajad, kes pole veel sellesse teemasse süvenenud, kasutavad samuti explain.depesz.com'i, kuna neile on lihtsam aru saada, millised mõõdikud on olulised ja millised mitte.

On uus lähenemine visualiseerimisele – explain.dalibo.com. Nad teevad puu struktuuri visualiseerimise, kuid siin on väga keeruline sõlmi omavahel võrrelda. Siin on hea mõista struktuuri, kuid kui päring on suur, tuleb kerida edasi-tagasi, kuid 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 tundub ebaselge, saame Slackis selle küsimuse oma kolleegide seas arutada.

Me arvame, et on oluline testida täismahus andmete peal. Selleks oleme loonud tööriista Update Database Lab, mis on saadaval avatud lähtekoodiga. Samuti võite kasutada bot Joe-d. Saate selle kohe endale võtta ja rakendada. Kõik juhendid on seal saadaval.

Oluline on ka märkida, et see lahendus iseenesest ei ole revolutsiooniline, kuna Delphix on olemas, aga see on ettevõtetasandi lahendus. See on täiesti suletud ja maksab väga palju. Meie spetsialiseerume just Postgressile. Kõik meie tooted on avatud lähtekoodiga. Liituge meiega!

Sellega lõpetan. Aitäh!

Küsimused

Tere! Aitäh ettekande eest! Väga huvitav, eriti mulle, kuna ma lahendasin umbes sellise ülesande mõni aeg tagasi. Seetõttu on mul mitmeid küsimusi. Loodan, et saan vähemalt mõned neist esitada.

Kuidas te kuvatavat ruumi selle keskkonna jaoks arvutate? Tehnoloogia tähendab, et teatud asjaoludel võivad teie kloonid suureneda maksimaalse suuruseni. Lihtsalt öeldes, kui teil on kümme terabaiti andmeid ja 10 klooni, siis on kerge modelleerida olukorda, kus iga kloon kannab 10 unikaalset andmestikku. Kuidas te seda ruumi arvutate, st seda delta, millest olete rääkinud, kus need kloonid elavad?

Hea küsimus. Siin on oluline jälgida konkreetseid kloone. Ja kui kloonil toimub mõni liiga suur muutus ja see hakkab suurenema, siis saame kõigepealt kasutajale selle kohta hoiatuse anda või kohe selle klooni peatada, et meil ei tekiks tõrkeolukorda.

Jah, mul on täiendav küsimus. Kuidas te tagate nende moodulite elutsükli? Meil on see probleem ja täiesti eraldi lugu. Kuidas see toimub?

Igal kloonil on mingi ttl. Üldiselt on meil fikseeritud ttl.

Mis see on, kui saladus ei ole?

1 tund, stabiilselt – 1 tund. Kui seda ei kasutata, siis hävitame selle. Siiski pole siin üllatust, kuna saame kloone sekunditega luua. Ja kui seda taas vajatakse, siis olge lahkesti.

Mulle on tehnoloogiate valik samuti huvitav, kuna me, näiteks, kasutame paralleelselt mitmeid meetodeid erinevatel põhjustel. Miks just ZFS? Miks te ei kasutanud LVM-i? Te mainisite, et LVM-iga olid probleemid. Millised need probleemid olid? Minu arvates on kõige optimaalsem lahendus, mis põhineb südamekompleksil, arvestades jõudlust.

Mis on peamine probleem ZFS-iga? See, et peate käivitama selle ühel hostil, mis tähendab, et kõik instances elavad ühe operatsioonisüsteemi raamides. Ja südamekompleksi puhul saate erinevat riistvara ühendada. Kitsaskohad on ainult need plokid, mis on südamekompleksis. Ja huvitav on just tehnoloogiate valiku küsimus. Miks mitte LVM?

Conkreetsem LVM-i arutame kohtumisel. Andmesalvestuslahendused – see on lihtsalt kulukas. ZFS-süsteemi saame rakendada igal pool. Sa võid selle oma masinas üles seada. Lihtsalt laadi alla repositoorium ja käivita see. ZFS sobib praktiliselt kõigile, kui räägime Linuxist. See tähendab, et saame väga paindliku lahenduse. Ja ZFS annab juba iseenesest väga palju funktsioone. Sa saad laadida sinna lõpmatus koguses andmeid, ühendada palju kettaid, on olemas snapshot'id. Ja nagu ma juba ütlesin, on selle haldamine väga lihtne. See on tõeliselt mugav kasutada. See on tõestatud, tal on palju aastaid kogemust. Sellel on suur kasvav kogukond. ZFS on väga usaldusväärne lahendus.

Nikolai Samokhvalov: Kas ma saaksin veel kommenteerida? Minu nimi on Nikolai, töötan koos Anatoliiga. Olen nõus, et andmesalvestuslahendused on suurepärased. Ja mõnel meie kliendil on olemas Pure Storage jne.

Anatoli tõi õigesti esile, et meie fookus on modulaarsete lahenduste loomisel. Tulevikus saame rakendada ühe liidese – tee snapshot, tee kloon, hävita kloon. See on kõik lihtne. Ja andmesalvestuslahendus on suurepärane, kui see on olemas.

Aga ZFS on kergesti kätte saadaval. Piisab DelPhixist, neil on 300 klienti. Neist Fortune 100 seas on 50 klienti, st nad sihivad NASA-d jne. On aeg, et see tehnoloogia oleks kõikidele kergesti kättesaadav. Seetõttu on meil avatud lähtekoodiga tuum. Meil on osa liidesest, mis ei ole avatud lähtekoodiga. See on platvorm, mida me tutvustame. Aga me tahame, et kõigil oleks sellele ligipääs. Soovime teha revolutsiooni, et kõik testijad saaksid lõpetada arvutite peal spekuleerimise. Peame kirjutama SELECT ja kohe nägema, et see on aeglane. Piisab ootamisest, kuni DBA sellest räägib. See on meie peamine eesmärk. Ja ma usun, et me jõuame selleni. Ja selle ehitame, et see oleks kõigile. Seetõttu ZFS, sest see saab olema igal pool kergesti kätte saadav. Aitäh kogukonnale probleemide lahendamise eest ja avatud lähtekoodiga litsentsi eest jne.

Tere! Aitäh ettekande eest! Minu nimi on Maxim. Me lahendasime samasuguseid probleeme. Meie juures on need lahendatud. Kuidas jagate ressursse nende kloonide vahel? Iga kloon võib igal hetkel tegeleda oma asjadega: üks testib ühte, teine teist, kellelgi ehitatakse indeksit, kellelgi on käimas keeruline töö. Ja kui CPU-d saab veel jagada, siis kuidas jagate IO-d? See on esimene küsimus.

Ja teine küsimus seondub stendide erinevusele. Oletame, et mul on siin ZFS ja kõik on suurepärane, aga kliendi prod keskkonnas on ext4, näiteks. Kuidas sellisel juhul toimida?

Küsimused on tõesti head. Mainisin veidi seda probleemi, et jagame ressursse. Lahendus on järgmine. Kujutage ette, et testite staging keskkonnas. Seal võib samuti korraga tekkida olukord, kus keegi annab ühe koormuse, keegi teine teise. Ja lõpuks näete veidraid mõõdikuid. Sama probleem võib esineda ka prod keskkonnas. Kui soovite mõnda päringut testida ja näete, et sellega on mingi probleem – see töötab aeglaselt, siis tegelikult pole probleem päringus, vaid selles, et on mingi paralleelne koormus.

Seetõttu on oluline keskenduda sellele, milline on plaan, millised on sammud meie plaani raames ja kui palju andmeid me selleks tõstame. See, et meil on diskid, näiteks, koormatud millegagi, mõjutab otseselt ajakava. Kuid saame andmete hulga põhjal hinnata, kui koormav see päring on. Pole nii oluline, et samal ajal toimub veel mõni täitmine.

Mul on kaks küsimust. See on tõesti lahe asi. Kas on olnud juhtumeid, kus andmed tootmises on kriitilise tähtsusega, näiteks krediitkaardinumber? Kas on midagi valmis tehtud või on see eraldi ülesanne? Ja teine küsimus – kas MySQL jaoks on midagi sarnast?

Andmete osas. Me teeme obfuskatsiooni nii kaua, kui me seda ei tee. Aga kui te kasutate Joe'd, ja kui te ei anna arendajatele juurdepääsu, siis andmetele ligipääsu ei ole. Miks? Sest Joe ei näita andmeid. Ta näitab ainult näitajaid, plaane ja muud. Nii tehti teadlikult, kuna see on üks meie kliendi nõudmistest. Nad soovisid optimeerimise võimalust, aga samas mitte anda kõigile hoolimatult ligipääsu.

MySQL-i kohta. Seda süsteemi saab kasutada igasugusel otstarbel, mis salvestab oleku kettale. Ja kuna me tegeleme Postgres'iga, teeme praegu kõigepealt täielikku automatiseerimist Postgres'e jaoks. Me tahame automatiseerida andmete hankimist varukoopiast. Konfigureerime Postgres'i õigesti. Me teame, kuidas tagada, et plaanid kattuksid jms.

Kuna süsteem on laiendatav, saab seda kasutada ka MySQL jaoks. Selliseid näiteid leidub. Sarnane lahendus on ka Yandexil, kuid nad ei avalda seda kuskil. Nad kasutavad seda sisemiselt Yandex.Metriks. Ja seal ongi tegemist MySQL looga. Ent tehnoloogiad on samad, ZFS.

Aitäh ettekande eest! Mul on paar küsimust. Mainisite, et kloonimist saab kasutada analüütikas, näiteks täiendavate indeksite loomiseks. Kas saaksite rääkida, kuidas see töötab?

Ja esitan kohe teise küsimuse identsete standide ning plaanide osas. Aja sõltub ka Postgres'i kogutud statistikatest. Kuidas te seda probleemi lahendate?

Konkreetsete juhtumite analüütika osas meil pole veel kogemusi, kuid see võimalus on olemas. Kui räägime indeksitest, siis kujutage ette, et päringut aetakse läbi tabeli, kus on sadu miljoneid kirjeid ja veergu, mis tavaliselt prod-is ei ole indekseeritud. Ja me tahame seal andmeid arvutada. Kui seda päringut prod-is korraldada, võib esineda võimalus, et prod-is on peatus, kuna päring töötab seal minut aega.

Selge, teeme peene klooni, mida ei ole hirmus mõneks minutiks peatada. Ja et analüütikat oleks mugavam jälgida, lisame indeksid neisse veergudesse, kus meid andmed huvitavad.

Kas indeks luuakse iga kord uuesti?

Saame teha nii, et muudetud andmetest teeme snapshot'id, ja seejärel taastume sellest snapshot'ist ning edastame uusi päringuid. See tähendab, et saame luua uusi kloone juba eelnevalt määratud indeksitega.

Statistika kohta, kui taastume varukoopiast või teeme replikatsiooni, siis meie statistika jääb täpselt samaks. Sest toome tagasi kogu andmekonstruktsiooni, st andmed koos kõikide statistikamõõdikute ja metrikatega.

Siin on teine probleem. Kui kasutate pilvelahendust, on seal saadaval ainult loogilised dump'id, sest Google ja Amazon ei luba füüsilist koopiat võtta. See toob kaasa sellise probleemi.

Aitäh esituse eest. Siin kõlas kaks head küsimust MySQL ja ressursside jagamise kohta. Kuid põhimõtteliselt on see teema, mis ei puuduta ainult konkreetseid andmebaase, vaid käsitleb laiemalt failisüsteemi. Seega peaksid ka ressursside jagamise küsimused olema sealt lähtuvad, mitte alla viimase, et see on Postgres, vaid failisüsteemi tasandil. serveril, instance.

Minu küsimus on pisut teistsugune. See on lähedasem andmebaasi mitmekihilisusele, kus on mitu kihti. Näiteks oleme seadistanud kümnete terabaitide suuruse pildi uuendamise, meie replikatsioon on töös. Me kasutame selle lahendust andmebaasides. Replikatsioon toimub, andmete uuendamine aset leiab. Samal ajal töötab 100 töötajat, kes pidevalt käivitavad neid erinevaid hetkepilte. Mida teha? Kuidas vältida konflikte, et nad käivitasid ühte, kuid siis failisüsteem muudeti ja need hetkepildid kõik katki läksid?

Need ei lähe katki, sest ZFS töötab just niimoodi. Me saame hoida ühes voos eraldi failisüsteemi muudatused, mis tulevad replikatsiooni kaudu. Ja vanade andmeversioonide peal hoida kloone, mida arendajad kasutavad. Ja see töötab meil hästi, kõik on korras.

Tundub, et värskendus toimub lisakihtina, ja kõik uued pildid põhinevad just sellel kihil, eks?

Eelmised kihid, mis olid varasemate replikatsioonide käigus tehtud.

Eelmised kihid kaovad, kuid nad viitavad vanale kihile, ja uued pildid võtavad nad viimasest kihist, mis saadi värskenduse käigus?

Üldiselt, jah.

Seega, meil tuleb hulganisti kihte. Ja aja jooksul tuleb neid kokku suruda?

Jah, see on õige. On mingi aeg. Me salvestame nädalased snappid. See sõltub sellest, kui palju ressursse teil on. Kui teil on võimalus palju andmeid salvestada, saate snappe pika aja jooksul hoida. Need ei kustuta end ise. Andmete rikkumist ei toimu. Kui snappid on ajale jalgu jäänud, nagu me arvame, s.t. see sõltub ettevõtte poliitikast, siis saame need lihtsalt kustutada ja ruumi vabastada.

Tere, aitäh ettekande eest! Joe teema osas. Te ütlesite, et tellija ei tahtnud andmetele igaühel ligipääsu anda. Rangelt öeldes, kui inimesel on Explain Analyze tulemus, siis ta võib andmeid piiluda.

Just so. For example, we can write: "SELECT FROM WHERE email = some value". That is, we won't see the actual data, but we can look at some indirect signs. This needs to be understood. However, on the other hand, everything is visible. We have log auditing, and we have oversight from other colleagues who can also see what the developers are doing. If someone tries to do that, the security service will come to them and address the issue.

Good afternoon! Thank you for the presentation! I have a quick question. If Slack is not used in the company, is there any current connection to it, or can developers deploy instances to connect a test application to the databases?

Currently, there is a connection to Slack, meaning there's no other messenger being used, but we really want to support other messengers as well. What can you do? You can deploy a DB Lab without Joe, access it via REST API or our platform, create clones, and connect using PSQL. But that can only be done if you are willing to give your developers access to the data, as there won't be any screen in that case.

I don’t need this intermediary; I need that capability.

Siis – jah, see on võimalik.

Allikas: habr.com