Kuidas saab taustaarendaja aru, et SQL-päring töötab tootes hästi? Suurtes või kiiresti kasvavates ettevõtetes ei ole kõigil "tootele" ligipääsu. Ja juurdepääsuga ei saa kõiki taotlusi valutult kontrollida ja andmebaasi koopia loomine võtab sageli tunde. Nende probleemide lahendamiseks lõime kunstliku DBA - Joe. Seda on edukalt rakendatud juba mitmes ettevõttes ja see aitab rohkem kui tosinat arendajat.
Video:
Tere kõigile! Minu nimi on Anatoli Stansler. Töötan ettevõttes . Oleme pühendunud arendusprotsessi kiirendamisele, kõrvaldades Postgresi tööga seotud viivitused arendajatelt, andmebaasidelt ja kvaliteedikontrollidelt.
Meil on suurepärased kliendid ja täna on osa aruandest pühendatud juhtumitele, millega kohtusime nendega töötades. Räägin sellest, kuidas aitasime neil lahendada päris tõsiseid probleeme.
Kui töötame välja ja teeme keerulisi suure koormusega migratsioone, esitame endale küsimuse: "Kas see migratsioon läheb hoogu?". Kasutame ülevaadet, kasutame kogenumate kolleegide, DBA ekspertide teadmisi. Ja nad võivad öelda, kas see lendab või mitte.
Aga võib-olla oleks parem, kui saaksime seda ise täissuuruses koopiatel katsetada. Ja täna räägime lihtsalt sellest, millised lähenemised testimisele on praegu olemas ja kuidas seda paremini teha ja milliste vahenditega. Räägime ka selliste lähenemisviiside plussidest ja miinustest ning sellest, mida saame siin parandada.
Kes on kunagi teinud indekseid otse tootes või teinud mingeid muudatusi? Üsna vähe. Ja kelle jaoks see tõi kaasa andmete kadumise või seisakuid? Siis sa tead seda valu. Jumal tänatud, et varukoopiaid on.
Esimene lähenemisviis on testimine tootes. Või kui arendaja istub kohalikus masinas, on tal testiandmed, on mingi piiratud valik. Ja me hakkame tootma ja saame sellise olukorra.
See on valus, see on kallis. Tõenäoliselt on parem mitte.
Ja mis on parim viis seda teha?
Võtame lavastuse ja valime sealt mõne tooteosa. Või parimal juhul võtame tõelise toote, kõik andmed. Ja pärast seda, kui oleme selle kohapeal välja töötanud, kontrollime täiendavalt lavastust.
See võimaldab meil eemaldada mõned vead, st takistada nende tootmist.
Millised on probleemid?
- Probleem on selles, et me jagame seda lavastust kolleegidega. Ja väga tihti juhtub nii, et teed mingisuguse muudatuse, bam – ja andmeid pole, töö läheb tühjaks. Lavastus oli mitme terabaidi pikkune. Ja sa pead kaua ootama, et see uuesti tõuseks. Ja me otsustame selle homme lõpule viia. See on kõik, meil on areng.
- Ja loomulikult töötab meil seal palju kolleege, palju meeskondi. Ja seda tuleb teha käsitsi. Ja see on ebamugav.
Ja tasub öelda, et meil on ainult üks katse, üks võte, kui tahame teha andmebaasis mingeid muudatusi, puudutada andmeid, muuta struktuuri. Ja kui midagi läks valesti, kui migratsioonis oli viga, siis me ei veere kiiresti tagasi.
See on parem kui eelmine lähenemine, kuid siiski on suur tõenäosus, et mingi viga läheb tootmisse.
Mis takistab meil andmast igale arendajale katsestendi, täissuuruses koopiat? Ma arvan, et on selge, mis segab.
Kellel on terabaidist suurem andmebaas? Rohkem kui pool tuba.
Ja on selge, et masinate pidamine iga arendaja jaoks, kui on nii suur toodang, on väga kulukas ja pealegi võtab see kaua aega.
Meil on kliente, kes on mõistnud, et väga oluline on testida kõiki muudatusi täissuuruses koopiatel, kuid nende andmebaas on alla terabaidi ja iga arendaja jaoks pole ressurssi testistendi hoidmiseks. Seetõttu peavad nad prügimäed kohapeal oma masinasse alla laadima ja sel viisil testima. See võtab palju aega.
Isegi kui teha seda infrastruktuuri sees, siis ühe terabaidi andmemahtu tunnis allalaadimine on juba väga hea. Kuid nad kasutavad loogilisi dumpe, laadivad pilvest alla. Nende jaoks on kiirus umbes 200 gigabaiti tunnis. Ja loogikaprügilt ringi keeramine, indeksite kokku kerimine jne võtab ikka aega.
Kuid nad kasutavad seda lähenemisviisi, kuna see võimaldab neil hoida toote usaldusväärsena.
Mida me siin teha saame? Teeme katsestendid odavaks ja anname igale arendajale oma katsestendi.
Ja see on võimalik.
Ja selle lähenemisviisi korral, kui teeme iga arendaja jaoks õhukesed kloonid, saame seda jagada ühes masinas. Näiteks kui teil on 10TB andmebaas ja soovite anda selle 10 arendajale, ei pea teil olema XNUMX x XNUMXTB andmebaase. Teil on vaja ainult ühte masinat, et teha õhukesi isoleeritud koopiaid iga arendaja jaoks, kasutades ühte masinat. Ma räägin teile veidi hiljem, kuidas see töötab.
Tõeline näide:
-
DB - 4,5 terabaiti.
-
Me saame iseseisvad koopiad 30 sekundiga.
Sa ei pea ootama katsestendit ja sõltuma selle suurusest. Saate selle mõne sekundiga kätte. Need on täiesti isoleeritud keskkonnad, mis jagavad omavahel andmeid.
See on hea. Siin räägime maagiast ja paralleeluniversumist.
Meie puhul töötab see OpenZFS-süsteemi kasutades.
OpenZFS on kirjutamisel kopeeritav failisüsteem, mis toetab hetktõmmiste ja kloonide tegemist. See on usaldusväärne ja skaleeritav. Teda on väga lihtne hallata. Seda saab sõna otseses mõttes kasutada kahes meeskonnas.
On ka teisi valikuid:
-
lvm,
-
Salvestus (näiteks Pure Storage).
Database Lab, millest ma räägin, on modulaarne. Neid võimalusi saab rakendada. Kuid praegu oleme keskendunud OpenZFS-ile, kuna probleeme oli konkreetselt LVM-iga.
Kuidas see töötab? Selle asemel, et andmeid iga kord muutes üle kirjutada, salvestame need lihtsalt märgistades, et need uued andmed pärinevad uuest ajahetkest, uuest hetkest.
Ja tulevikus, kui tahame tagasi võtta või mõnest vanemast versioonist uue klooni teha, ütleme lihtsalt: "OK, andke meile need andmeplokid, mis on nii märgitud."
Ja see kasutaja töötab sellise andmekogumiga. Ta muudab neid järk-järgult, teeb ise pilte.
Ja me hargneme. Meie puhul on igal arendajal võimalus saada oma kloon, mida ta redigeerib, ja jagatud andmeid jagatakse kõigi vahel.
Sellise süsteemi kodus juurutamiseks peate lahendama kaks probleemi:
-
Esimene on andmete allikas, kust te need võtate. Saate seadistada replikatsiooni tootmisega. Loodan, et saate juba konfigureeritud varukoopiaid kasutada. WAL-E, WAL-G või Barman. Ja isegi kui kasutate mõnda pilvelahendust, näiteks RDS-i või Cloud SQL-i, saate kasutada loogilisi dumpe. Kuid soovitame teil siiski kasutada varukoopiaid, sest selle lähenemisviisiga säilitate ka failide füüsilise struktuuri, mis võimaldab teil olemasolevate probleemide tabamiseks olla veelgi lähemal mõõdikutele, mida näete tootmises.
-
Teine on koht, kus soovite andmebaasilabori majutada. See võib olla Cloud, see võib olla kohapealne. Siinkohal on oluline öelda, et ZFS toetab andmete tihendamist. Ja teeb seda päris hästi.
Kujutage ette, et iga sellise klooni jaoks kasvab olenevalt toimingutest, mida baasiga teeme, mingisugune arendaja. Selleks vajab arendaja ka ruumi. Kuid kuna võtsime aluseks 4,5 terabaidi, tihendab ZFS selle 3,5 terabaidiks. See võib olenevalt sätetest erineda. Ja meil on veel ruumi arendajatele.
Sellist süsteemi saab kasutada erinevatel juhtudel.
-
Need on arendajad, DBA-d päringu valideerimiseks ja optimeerimiseks.
-
Seda saab kasutada kvaliteedikontrolli testimisel, et testida konkreetset migratsiooni, enne kui selle tooteks välja anname. Samuti saame luua reaalsete andmetega kvaliteedikontrolli erikeskkondi, kus nad saavad testida uusi funktsioone. Ja ootetundide asemel kulub sekundeid ja mõnel muul juhul, kui õhukesi koopiaid ei kasutata, võib-olla päevi.
-
Ja veel üks juhtum. Kui ettevõttel puudub analüütikasüsteem, saame eraldada tootebaasist õhukese klooni ja anda selle pikkadele päringutele või spetsiaalsetele indeksitele, mida saab analüütikas kasutada.
Selle lähenemisviisiga:
-
Madal vigade tõenäosus tootes, kuna testisime kõiki muudatusi täissuuruses andmetega.
-
Meil on testimise kultuur, sest nüüd ei pea te oma stendi tunde ootama.
-
Ja testide vahel pole barjääri ega ootamist. Tegelikult võite minna ja kontrollida. Ja see on nii parem, kui me arengut kiirendame.
-
Refaktoreerimist tehakse vähem. Tootmisse jõuab vähem vigu. Hiljem refaktoreerime neid vähem.
-
Me saame pöördumatud muutused tagasi pöörata. See ei ole standardne lähenemine.
- See on kasulik, sest jagame katsestendi ressursse.
Juba hea, aga mida veel saaks kiirendada?
Tänu sellisele süsteemile saame oluliselt vähendada sellisele testimisele sisenemise künnist.
Nüüd on tekkinud nõiaring, kus arendaja peab tegelikele täissuuruses andmetele ligi pääsemiseks hakkama eksperdiks. Talle tuleb selline juurdepääs usaldada.
Aga kuidas kasvatada, kui seda pole. Aga mis siis, kui teie käsutuses on vaid väga väike kogum testandmeid? Siis ei saa te tõelist kogemust.
Kuidas sellest ringist välja tulla? Esimese liidesena, mis on mugav iga taseme arendajatele, valisime Slacki roboti. Kuid see võib olla mis tahes muu liides.
Mida see võimaldab teil teha? Võite võtta konkreetse päringu ja saata selle andmebaasi spetsiaalsesse kanalisse. Me juurutame õhukese klooni sekunditega automaatselt. Käivitame selle taotluse. Kogume mõõdikuid ja soovitusi. Näitame visualiseerimist. Ja siis jääb see kloon alles, et saaks seda päringut kuidagi optimeerida, indekseid lisada jne.
Ja ka Slack annab meile koostöövõimalused karbist väljas. Kuna see on lihtsalt kanal, võite hakata seda taotlust arutama sealsamas sellise päringu lõimes, pingida oma kolleege, ettevõtte sees olevaid DBA-sid.
Kuid loomulikult on probleeme. Kuna see on reaalne maailm ja me kasutame serverit, mis majutab korraga palju kloone, peame kloonidele saadaolevat mälumahtu ja protsessorivõimsust kokku suruma.
Kuid selleks, et need testid oleksid usutavad, peate selle probleemi kuidagi lahendama.
On selge, et oluline on samad andmed. Aga meil on see juba olemas. Ja me tahame saavutada sama konfiguratsiooni. Ja me saame anda sellise peaaegu identse konfiguratsiooni.
Oleks lahe, kui oleks sama riistvara, mis tootmises, aga see võib erineda.
Meenutagem, kuidas Postgres mäluga töötab. Meil on kaks vahemälu. Üks failisüsteemist ja üks natiivne Postgres, st jagatud puhvri vahemälu.
Oluline on märkida, et jagatud puhvri vahemälu eraldatakse Postgresi käivitumisel, olenevalt konfiguratsioonis määratud suurusest.
Ja teine vahemälu kasutab kogu vaba ruumi.
Ja kui teeme ühes masinas mitu klooni, selgub, et me täidame mälu järk-järgult. Ja heas mõttes on Shared Buffer Cache 25% kogu masinas saadaolevast mälumahust.
Ja selgub, et kui me seda parameetrit ei muuda, saame ühes masinas käivitada ainult 4 eksemplari, see tähendab kokku 4 neist õhukestest kloonidest. Ja see on muidugi halb, sest me tahame, et neid oleks palju rohkem.
Kuid teisest küljest kasutatakse puhvri vahemälu indeksite päringute täitmiseks, see tähendab, et plaan sõltub sellest, kui suured on meie vahemälud. Ja kui me lihtsalt võtame selle parameetri ja vähendame seda, siis võivad meie plaanid palju muutuda.
Näiteks kui meil on tootes suur vahemälu, eelistab Postgres kasutada indeksit. Ja kui ei, siis tuleb SeqScan. Ja mis mõtet oleks, kui meie plaanid kokku ei langeks?
Kuid siit jõuame järeldusele, et tegelikult ei sõltu Postgres olev plaan konkreetsest plaanis Shared Bufferis määratud suurusest, vaid see sõltub efektiivsest_cache_size-st.
Efektiivne_vahemälu_suurus on meile saadaoleva vahemälu hinnanguline maht, st puhvri vahemälu ja failisüsteemi vahemälu summa. Selle määrab konfiguratsioon. Ja seda mälu ei eraldata.
Ja selle parameetri tõttu saame Postgresi petta, öeldes, et meil on tegelikult saadaval palju andmeid, isegi kui meil neid andmeid pole. Ja seega kattuvad plaanid tootmisega täielikult.
Kuid see võib ajastust mõjutada. Ja me optimeerime päringuid ajastuse järgi, kuid on oluline, et ajastus sõltub paljudest teguritest.
-
See oleneb koormusest, mis parasjagu tootmisvõimsusel on.
-
See sõltub masina enda omadustest.
Ja see on kaudne parameeter, kuid tegelikult saame tulemuse saamiseks optimeerida täpselt andmete hulga järgi, mida see päring loeb.
Ja kui soovite, et ajastus oleks lähedane sellele, mida näeme tootes, siis peame võtma kõige sarnasema riistvara ja võib-olla isegi rohkem, et kõik kloonid ära mahuksid. Kuid see on kompromiss, st saate samad plaanid, näete, kui palju andmeid konkreetne päring loeb ja saate teha järelduse, kas see päring on hea (või migratsioon) või halb, see vajab veel optimeerimist .
Vaatame, kuidas Joe on konkreetselt optimeeritud.
Võtame päringu reaalsest süsteemist. Sellisel juhul on andmebaasi suurus 1 terabait. Ja me tahame kokku lugeda värskete postituste arvu, millel on rohkem kui 10 meeldimist.
Kirjutame kanalile sõnumit, meie jaoks on kasutusele võetud kloon. Ja me näeme, et selline taotlus täidetakse 2,5 minutiga. See on esimene asi, mida märkame.
B Joe näitab teile plaani ja mõõdikute põhjal automaatseid soovitusi.
Näeme, et päring töötleb liiga palju andmeid, et saada suhteliselt vähe ridu. Ja vaja on mingit spetsiaalset indeksit, kuna märkasime, et päringus on liiga palju filtreeritud ridu.
Vaatame juhtunut lähemalt. Tõepoolest, me näeme, et oleme faili vahemälust või isegi kettalt lugenud peaaegu poolteist gigabaiti andmeid. Ja see pole hea, sest meil on ainult 142 rida.
Ja tundub, et meil on siin indeksi skaneerimine ja see oleks pidanud kiiresti toimima, kuid kuna filtreerisime liiga palju ridu (need pidime loendama), läks taotlus aeglaselt täide.
Ja see juhtus plaanis tänu sellele, et päringu tingimused ja indeksi tingimused ei ühti osaliselt.
Proovime indeksit täpsemaks muuta ja vaadata, kuidas päringu täitmine pärast seda muutub.
Indeksi loomine võttis päris kaua aega, kuid nüüd kontrollime päringut ja näeme, et aeg on 2,5 minuti asemel vaid 156 millisekundit, mis on piisavalt hea. Ja me loeme ainult 6 megabaiti andmeid.
Ja nüüd kasutame ainult indeksiga skannimist.
Teine oluline lugu on see, et tahame kava kuidagi arusaadavamalt esitada. Oleme rakendanud visualiseerimist Flame Graphsi abil.
See on teistsugune taotlus, intensiivsem. Ja me ehitame Flame Graphs kahe parameetri järgi: see on andmete hulk, mille konkreetne sõlm plaanis ja ajastuses loendas, st sõlme täitmise aeg.
Siin saame konkreetseid sõlme omavahel võrrelda. Ja saab selgeks, milline neist võtab rohkem või vähem, mida teiste renderdusmeetodite puhul on tavaliselt raske teha.
Muidugi teavad kõik selgitust.depesz.com. Selle visualiseerimise hea omadus on see, et salvestame tekstiplaani ja paneme ka mõned põhiparameetrid tabelisse, et saaksime sorteerida.
Ja arendajad, kes pole veel sellesse teemasse süvenenud, kasutavad ka aadressi selgitus.depesz.com, sest neil on lihtsam aru saada, millised mõõdikud on olulised ja millised mitte.
Visualiseerimisel on uus lähenemine – see on selgitus.dalibo.com. Nad teevad puu visualiseerimist, kuid sõlmede võrdlemine on väga raske. Siin saate struktuurist hästi aru, aga kui on suur taotlus, peate kerima edasi-tagasi, aga ka valikut.
koostöö
Ja nagu ma ütlesin, annab Slack meile võimaluse koostööd teha. Näiteks kui puutume kokku keerulise päringuga, mida pole selge, kuidas optimeerida, saame seda probleemi kolleegidega Slacki lõimes selgitada.
Meile tundub, et oluline on testida täissuuruses andmetega. Selleks tegime tööriista Update Database Lab, mis on saadaval avatud lähtekoodiga. Võite kasutada ka Joe robotit. Saate selle kohe kätte võtta ja omal kohal rakendada. Kõik juhendid on seal saadaval.
Samuti on oluline märkida, et lahendus ise ei ole revolutsiooniline, sest Delphix on olemas, kuid see on ettevõtte lahendus. See on täiesti suletud, see on väga kallis. Oleme spetsiaalselt spetsialiseerunud Postgresele. Need on kõik avatud lähtekoodiga tooted. Liitu meiega!
Siin ma lõpetan. Aitäh!
küsimused
Tere! Täname raporti eest! Väga huvitav, eriti minu jaoks, kuna lahendasin umbes sama probleemi mõni aeg tagasi. Ja nii on mul mitmeid küsimusi. Loodetavasti saan sellest vähemalt osa.
Huvitav, kuidas sa selle keskkonna koha välja arvutad? Tehnoloogia tähendab, et teatud tingimustel võivad teie kloonid kasvada maksimaalse suuruseni. Jämedalt öeldes, kui teil on kümne terabaidine andmebaas ja 10 klooni, on lihtne simuleerida olukorda, kus iga kloon kaalub 10 unikaalset andmeid. Kuidas arvutate selle koha, st selle delta, millest te rääkisite, kus need kloonid elama hakkavad?
Hea küsimus. Siin on oluline jälgida konkreetseid kloone. Ja kui kloonil on mõni liiga suur muutus, siis see hakkab kasvama, siis saame selle eest kasutajale esmalt hoiatuse teha või selle klooni kohe peatada, et meil ei tekiks tõrkeolukorda.
Jah, mul on pesastatud küsimus. Ehk kuidas tagate nende moodulite elutsükli? Meil on see probleem ja täiesti omaette lugu. Kuidas see juhtub?
Iga klooni jaoks on mingi ttl. Põhimõtteliselt on meil fikseeritud ttl.
Mis siis, kui mitte saladus?
1 tund, st tühikäik - 1 tund. Kui seda ei kasutata, siis paugutame. Kuid siin pole üllatust, kuna saame klooni sekunditega üles tõsta. Ja kui teil on seda uuesti vaja, siis palun.
Mind huvitab ka tehnoloogiate valik, sest näiteks kasutame ühel või teisel põhjusel mitut meetodit paralleelselt. Miks ZFS? Miks sa LVM-i ei kasutanud? Mainisite, et LVM-iga oli probleeme. Millised olid probleemid? Minu arvates on jõudluse mõttes kõige optimaalsem variant koos ladustamisega.
Mis on ZFS-i peamine probleem? Asjaolu, et peate töötama samas hostis, st kõik eksemplarid elavad samas OS-is. Ja ladustamise puhul saate ühendada erinevaid seadmeid. Ja kitsaskohaks on ainult need plokid, mis on salvestussüsteemis. Ja tehnoloogiate valiku küsimus on huvitav. Miks mitte LVM?
Täpsemalt saame LVM-i arutada kohtumisel. Ladustamise kohta – see on lihtsalt kallis. Saame ZFS-süsteemi rakendada kõikjal. Saate selle oma masinasse juurutada. Saate lihtsalt hoidla alla laadida ja juurutada. ZFS on installitud peaaegu kõikjale, kui me räägime Linuxist. See tähendab, et saame väga paindliku lahenduse. Ja karbist välja võttes annab ZFS palju. Saate üles laadida nii palju andmeid kui soovite, ühendada suure hulga kettaid, seal on hetktõmmised. Ja nagu ma ütlesin, on seda lihtne manustada. See tähendab, et seda tundub väga meeldiv kasutada. Ta on testitud, ta on mitu aastat vana. Tal on väga suur kogukond, mis kasvab. ZFS on väga töökindel lahendus.
Nikolai Samohvalov: Kas ma tohin veel kommenteerida? Minu nimi on Nikolai, me töötame koos Anatoliga. Olen nõus, et ladustamine on suurepärane. Ja mõnel meie kliendil on Pure Storage jne.
Anatoli märkis õigesti, et oleme keskendunud modulaarsusele. Ja tulevikus saate rakendada ühte liidest - teha hetktõmmis, teha kloon, hävitada kloon. Kõik on lihtne. Ja ladustamine on lahe, kui on.
Kuid ZFS on kõigile kättesaadav. DelPhix on juba piisav, neil on 300 klienti. Neist Fortune 100-l on 50 klienti, st need on suunatud NASA-le jne. Kõigil on aeg see tehnoloogia endale hankida. Ja sellepärast on meil avatud lähtekoodiga Core. Meil on liidese osa, mis pole avatud lähtekoodiga. See on platvorm, mida me näitame. Kuid me tahame, et see oleks kõigile kättesaadav. Tahame teha revolutsiooni, et kõik testijad lõpetaksid sülearvutite oletamise. Peame kirjutama SELECT ja kohe nägema, et see on aeglane. Ärge oodake, kuni DBA teile sellest räägib. Siin on peamine eesmärk. Ja ma arvan, et me kõik jõuame selleni. Ja me teeme selle asja kõigile. Seetõttu ZFS, sest see on saadaval kõikjal. Täname kogukonda probleemide lahendamise ja avatud lähtekoodiga litsentsi jms eest.*
Tervitused! Täname raporti eest! Minu nimi on Maxim. Oleme samade probleemidega tegelenud. Nad otsustasid ise. Kuidas te nende kloonide vahel ressursse jagate? Iga kloon võib igal ajahetkel teha oma asja: üks testib üht, teine teist, keegi koostab indeksi, kellelgi on raske töö. Ja kui ikka saab jagada CPU järgi, siis IO järgi, kuidas siis jagada? See on esimene küsimus.
Ja teine küsimus puudutab tribüünide erinevust. Oletame, et mul on siin ZFS ja kõik on lahe, aga prod-i kliendil pole ZFS, vaid näiteks ext4. Kuidas antud juhul?
Küsimused on väga head. Mainisin seda probleemi veidi sellega, et me jagame ressursse. Ja lahendus on see. Kujutage ette, et testite lavastust. Sul võib olla samal ajal ka selline olukord, et keegi annab ühe koormuse, keegi teine. Ja selle tulemusena näete arusaamatuid mõõdikuid. Isegi sama probleem võib olla tootega. Kui tahad mingit päringut kontrollida ja näed, et sellega on mingi probleem - töötab aeglaselt, siis tegelikult ei olnud probleem päringus, vaid selles, et mingi paralleelkoormus on.
Ja seetõttu on siin oluline keskenduda sellele, milline plaan saab olema, milliseid samme plaanis astume ja kui palju andmeid selleks kogume. Asjaolu, et näiteks meie kettad laaditakse millegagi, mõjutab konkreetselt ajastust. Kuid me saame andmemahu järgi hinnata, kui koormatud see päring on. See pole nii oluline, et samal ajal toimub mingi hukkamine.
Mul on kaks küsimust. See on väga lahe kraam. Kas on olnud juhtumeid, kus tootmisandmed, näiteks krediitkaardinumbrid, on kriitilised? Kas midagi on juba valmis või on see eraldi ülesanne? Ja teine küsimus - kas MySQL jaoks on midagi sellist?
Andmete kohta. Me teeme hägustamist seni, kuni me seda teeme. Kuid kui juurutate täpselt Joe, kui te ei anna arendajatele juurdepääsu, pole andmetele juurdepääsu. Miks? Sest Joe ei näita andmeid. See näitab ainult mõõdikuid, plaane ja kõik. Seda tehti meelega, sest see on üks meie kliendi nõudmistest. Nad tahtsid optimeerida ilma kõigile juurdepääsu andmata.
MySQL-i kohta. Seda süsteemi saab kasutada kõige jaoks, mis salvestab oleku kettale. Ja kuna me teeme Postgresi, teeme nüüd esmalt kogu Postgresi automatiseerimise. Soovime automatiseerida andmete hankimist varukoopiast. Seadistame Postgresi õigesti. Me teame, kuidas plaane sobitada jne.
Kuid kuna süsteem on laiendatav, saab seda kasutada ka MySQL-i jaoks. Ja selliseid näiteid on. Yandexil on sarnane asi, kuid nad ei avalda seda kuskil. Nad kasutavad seda Yandex.Metrica sees. Ja seal on lihtsalt lugu MySQL-ist. Kuid tehnoloogiad on samad, ZFS.
Täname raporti eest! Mul on ka paar küsimust. Mainisite, et kloonimist saab kasutada analüütika jaoks, näiteks ehitada sinna täiendavaid indekseid. Kas saate natuke rohkem rääkida, kuidas see töötab?
Ja kohe esitan teise küsimuse tribüünide sarnasuse, plaanide sarnasuse kohta. Plaan oleneb ka Postgresi kogutud statistikast. Kuidas te seda probleemi lahendate?
Analüütika järgi konkreetseid juhtumeid ei ole, sest me pole seda veel kasutanud, aga selline võimalus on. Kui me räägime indeksitest, siis kujutage ette, et päring jahib sadade miljonite kirjetega tabelit ja veergu, mida tavaliselt prod-is ei indekseerita. Ja me tahame seal mõned andmed arvutada. Kui see päring saadetakse prod-ile, siis on võimalus, et prod-is on see lihtne, sest seal töödeldakse päringut minuti jooksul.
Ok, teeme õhukese klooni, mida pole kohutav mõneks minutiks peatuda. Ja selleks, et analüütikat oleks mugavam lugeda, lisame nende veergude jaoks, mille andmed meid huvitavad, indeksid.
Kas indeks luuakse iga kord?
Saate teha nii, et puudutame andmeid, teeme hetktõmmiseid, siis taastume sellest hetkeseisust ja esitame uusi taotlusi. See tähendab, et saate teha nii, et saate juba kinnitatud indeksiga uusi kloone kasvatada.
Mis puutub statistikasse, siis kui taastame varukoopiast, kui teeme replikatsiooni, on meie statistika täpselt sama. Kuna meil on kogu füüsiline andmestruktuur, see tähendab, et toome andmed nii, nagu need on, ka kõigi statistikamõõdikutega.
Siin on veel üks probleem. Kui kasutada pilvelahendust, siis seal on ainult loogilised prügimäed, sest Google, Amazon ei luba füüsilist koopiat teha. Tekib probleem.
Täname raporti eest. Siin oli kaks head küsimust MySQL-i ja ressursside jagamise kohta. Kuid tegelikult taandub see kõik asjaolule, et see pole konkreetse DBMS-i, vaid failisüsteemi kui terviku teema. Ja vastavalt sellele tuleks ka ressursside jagamise küsimused lahendada sealt, mitte lõpuks, et see on Postgres, vaid failisüsteemis, näiteks serveris.
Minu küsimus on veidi erinev. See on lähemal mitmekihilisele andmebaasile, kus on mitu kihti. Näiteks seadistame kümne terabaidise pildiuuenduse, me paljundame. Ja me kasutame seda lahendust spetsiaalselt andmebaaside jaoks. Replikatsioon on pooleli, andmeid värskendatakse. Siin töötab paralleelselt 100 töötajat, kes pidevalt neid erinevaid võtteid käivitavad. Mida teha? Kuidas veenduda, et pole konflikti, et nad käivitasid selle ja seejärel failisüsteem muutus ja need pildid läksid kõik?
Nad ei lähe, sest ZFS töötab nii. Saame hoida ühes lõimes eraldi replikatsioonist tulenevaid failisüsteemi muudatusi. Ja säilitage kloonid, mida arendajad kasutavad andmete vanemates versioonides. Ja see töötab meie jaoks, sellega on kõik korras.
Selgub, et uuendus toimub lisakihina ja kõik uued pildid lähevad juba, selle kihi põhjal, eks?
Eelmistest kihtidest, mis olid eelmistest replikatsioonidest.
Eelmised kihid kukuvad maha, kuid viitavad vanale kihile ja kas nad võtavad uusi pilte viimasest värskenduses saadud kihist?
Üldiselt jah.
Siis on meil kuni viigi jagu kihte. Ja aja jooksul tuleb need kokku suruda?
Jah, kõik on õige. Seal on mingi aken. Teeme iganädalasi hetktõmmiseid. See sõltub sellest, mis ressurss teil on. Kui teil on võimalus salvestada palju andmeid, saate hetktõmmiseid pikka aega salvestada. Nad ei kao iseenesest. Andmete rikkumist ei toimu. Kui hetktõmmised on aegunud, nagu meile tundub, st see sõltub ettevõtte poliitikast, siis saame need lihtsalt kustutada ja ruumi vabastada.
Tere, täname aruande eest! Küsimus Joe kohta. Ütlesite, et klient ei soovi kõigile andmetele juurdepääsu anda. Rangelt võttes, kui inimesel on Explain Analüüsi tulemus, saab ta neid andmeid piiluda.
See on nii. Näiteks võime kirjutada: "SELECT FROM WHERE email = to that". See tähendab, et me ei näe andmeid ise, kuid võime näha mõningaid kaudseid märke. Seda tuleb mõista. Kuid teisest küljest on see kõik olemas. Meil on logiaudit, meil on kontroll teiste kolleegide üle, kes ka näevad, mida arendajad teevad. Ja kui keegi proovib seda teha, siis tuleb turvateenistus tema juurde ja tegeleb selle teemaga.
Tere päevast Täname raporti eest! Mul on lühike küsimus. Kui ettevõte Slacki ei kasuta, siis kas see on nüüd seotud või on arendajatel võimalik testrakenduse andmebaasidega ühendamiseks eksemplare juurutada?
Nüüd on link Slackile, st muud messengerit pole, aga ma tõesti tahan toetada ka teisi messengereid. Mida sa teha saad? Saate juurutada DB Labi ilma Joe-ta, minna REST API või meie platvormi abil ning luua kloone ja ühendada PSQL-iga. Kuid seda saab teha, kui olete valmis andma oma arendajatele andmetele juurdepääsu, sest ekraani ei ole enam.
Ma ei vaja seda kihti, aga mul on vaja sellist võimalust.
Siis jah, saab hakkama.
Allikas: www.habr.com