DBA botas Joe. Anatolijus Stansleris (Postgres.ai)

Kaip užpakalinės programos kūrėjas supranta, kad SQL užklausa gerai veiks „gamyboje“? Didelėse ar sparčiai augančiose įmonėse ne visi turi prieigą prie „produkto“. O turint prieigą, ne visas užklausas galima neskausmingai patikrinti, o duomenų bazės kopijos kūrimas dažnai užtrunka valandas. Norėdami išspręsti šias problemas, sukūrėme dirbtinį DBA - Joe. Jis jau sėkmingai įdiegtas keliose įmonėse ir padeda daugiau nei dešimčiai kūrėjų.

Vaizdo įrašas:

Sveiki visi! Mano vardas Anatolijus Stansleris. Dirbu įmonėje postgres.ai. Esame įsipareigoję paspartinti kūrimo procesą, pašalindami su „Postgres“ darbu susijusius vėlavimus iš kūrėjų, DBA ir QA.

Turime puikių klientų ir šiandien dalis ataskaitos bus skirta atvejams, su kuriais susipažinome dirbdami su jais. Pakalbėsiu apie tai, kaip padėjome jiems išspręsti gana rimtas problemas.

Kurdami ir vykdydami sudėtingas didelio krūvio migracijas, užduodame sau klausimą: „Ar ši migracija įsibėgės?“. Mes naudojame apžvalgą, naudojame labiau patyrusių kolegų, DBA ekspertų žinias. Ir jie gali pasakyti, skris ar ne.

Bet galbūt būtų geriau, jei galėtume patys tai išbandyti viso dydžio kopijose. O šiandien kalbėsime tik apie tai, kokie dabar yra testavimo metodai ir kaip tai galima padaryti geriau ir kokiais įrankiais. Taip pat kalbėsime apie tokių metodų privalumus ir trūkumus bei tai, ką čia galime pataisyti.

Kas kada nors sukūrė indeksus tiesiogiai gaminyje arba atliko kokių nors pakeitimų? Gana šiek tiek. O kam tai privedė prie duomenų praradimo ar prastovų? Tada tu žinai šį skausmą. Ačiū Dievui, yra atsarginių kopijų.

Pirmasis metodas yra bandymas gamybinėje versijoje. Arba, kai kūrėjas sėdi ant vietinės mašinos, jis turi bandymų duomenis, yra kažkoks ribotas pasirinkimas. Mes pradedame gaminti, ir gauname tokią situaciją.

Skauda, ​​brangu. Turbūt geriau to nedaryti.

Ir koks geriausias būdas tai padaryti?

Paimkime inscenizaciją ir ten pasirinkite tam tikrą produkcijos dalį. Arba geriausiu atveju paimkime tikrą gaminį, visus duomenis. O sukūrę jį vietoje, papildomai patikrinsime, ar nėra pastatymo.

Tai leis mums pašalinti kai kurias klaidas, t. y. neleisti, kad jos nebūtų gamyboje.

Kokios problemos?

• Bėda ta, kad šia inscenizacija dalijamės su kolegomis. Ir labai daznai nutinka taip, kad pasidarai kokius nors pakeitimus, bam - o duomenu nera, darbas nukrito. Pastatymas buvo kelių terabaitų. Ir reikia ilgai laukti, kol vėl pakils. Ir mes nusprendžiame jį užbaigti rytoj. Tai viskas, mes turime tobulėjimą.
• Ir, žinoma, ten dirba daug kolegų, daug komandų. Ir tai turi būti padaryta rankiniu būdu. Ir tai nepatogu.

Ir verta pasakyti, kad turime tik vieną bandymą, vieną šūvį, jei norime atlikti kokius nors pakeitimus duomenų bazėje, paliesti duomenis, pakeisti struktūrą. Ir jei kažkas nutiko ne taip, jei įvyko klaida migruojant, mes greitai neatsuksime.

Tai geriau nei ankstesnis metodas, tačiau vis tiek yra didelė tikimybė, kad gamyboje bus padaryta kokia nors klaida.

Kas neleidžia kiekvienam kūrėjui duoti bandymų stendo, viso dydžio kopijos? Manau, aišku, kas trukdo.

Kas turi didesnę nei terabaitą duomenų bazę? Daugiau nei pusė kambario.

Ir aišku, kad mašinų išlaikymas kiekvienam kūrėjui, kai yra tokia didelė gamyba, yra labai brangu, be to, tai užtrunka ilgai.

Turime klientų, kurie suprato, kad labai svarbu visus pakeitimus išbandyti viso dydžio kopijose, tačiau jų duomenų bazė yra mažesnė nei terabaitas, o kiekvienam kūrėjui nėra resursų išlaikyti testavimo stendą. Todėl jie turi atsisiųsti sąvartynus vietoje į savo mašiną ir tokiu būdu išbandyti. Tai užima daug laiko.

Net jei tai darote infrastruktūros viduje, atsisiųsti vieną terabaitą duomenų per valandą jau yra labai gerai. Bet jie naudoja loginius sąvartynus, atsisiunčia vietoje iš debesies. Jiems greitis siekia apie 200 gigabaitų per valandą. Ir dar reikia laiko apsisukti iš loginio sąvartyno, susukti indeksus ir t.t.

Tačiau jie naudoja šį metodą, nes tai leidžia išlaikyti gaminio patikimumą.

Ką mes čia galime padaryti? Padarykime bandymų stendus pigius ir kiekvienam kūrėjui suteiksime savo bandymų stendą.

Ir tai įmanoma.

Ir taikant šį metodą, kai kiekvienam kūrėjui sukuriame plonus klonus, galime juos bendrinti vienoje mašinoje. Pavyzdžiui, jei turite 10 TB duomenų bazę ir norite ją perduoti 10 kūrėjų, jums nereikia turėti XNUMX x XNUMX TB duomenų bazių. Norint padaryti plonas izoliuotas kopijas kiekvienam kūrėjui naudojant vieną įrenginį, jums reikia tik vieno įrenginio. Kaip tai veikia, papasakosiu šiek tiek vėliau.

Tikras pavyzdys:

• DB – 4,5 terabaito.

• Nepriklausomas kopijas galime gauti per 30 sekundžių.

Jums nereikia laukti bandymo stendo ir priklausyti nuo jo dydžio. Jį galite gauti per kelias sekundes. Tai bus visiškai izoliuota aplinka, kuri tarpusavyje dalijasi duomenimis.

Tai puiku. Čia mes kalbame apie magiją ir paralelinę visatą.

Mūsų atveju tai veikia naudojant OpenZFS sistemą.

„OpenZFS“ yra kopijavimo ir rašymo failų sistema, kuri palaiko momentines nuotraukas ir klonus. Jis yra patikimas ir keičiamas. Ją labai lengva valdyti. Jis tiesiogine prasme gali būti dislokuotas dviejose komandose.

Yra ir kitų variantų:

• lvm,

• Saugykla (pavyzdžiui, Pure Storage).

Duomenų bazės laboratorija, apie kurią kalbu, yra modulinė. Galima įgyvendinti naudojant šias parinktis. Tačiau šiuo metu mes sutelkėme dėmesį į OpenZFS, nes buvo problemų su LVM.

Kaip tai veikia? Užuot perrašę duomenis kiekvieną kartą, kai juos keičiame, išsaugome juos tiesiog pažymėdami, kad šie nauji duomenys yra iš naujo laiko momento, nauja momentinė nuotrauka.

Ir ateityje, kai norime atšaukti arba sukurti naują kloną iš kokios nors senesnės versijos, tiesiog sakome: „Gerai, duok mums šiuos duomenų blokus, kurie pažymėti taip“.

Ir šis vartotojas dirbs su tokiu duomenų rinkiniu. Jis pamažu juos keis, darys savo momentines nuotraukas.

Ir šakosim. Kiekvienas kūrėjas mūsų atveju turės galimybę turėti savo kloną, kurį redaguoja, o dalijami duomenys bus dalijami visiems.

Norėdami įdiegti tokią sistemą namuose, turite išspręsti dvi problemas:

• Pirmasis yra duomenų šaltinis, iš kur juos paimsite. Galite nustatyti replikaciją su gamyba. Tikiuosi, kad jau galite naudoti atsargines kopijas, kurias sukonfigūravote. WAL-E, WAL-G arba barmenas. Ir net jei naudojate kokį nors debesies sprendimą, pvz., RDS arba Cloud SQL, galite naudoti loginius iškeltus. Tačiau vis tiek patariame naudoti atsargines kopijas, nes tokiu būdu išsaugosite ir fizinę failų struktūrą, o tai leis būti dar arčiau metrikų, kurias pamatytumėte gamyboje, kad pagautumėte tas esamas problemas.

• Antrasis yra vieta, kur norite priglobti duomenų bazės laboratoriją. Tai gali būti debesis, gali būti vietoje. Čia svarbu pasakyti, kad ZFS palaiko duomenų glaudinimą. Ir tai daro gana gerai.

Įsivaizduokite, kad kiekvienam tokiam klonui, priklausomai nuo operacijų, kurias atliekame su baze, išaugs koks nors kūrėjas. Tam kūrėjui taip pat reikės vietos. Tačiau dėl to, kad paėmėme 4,5 terabaito bazę, ZFS suglaudins ją iki 3,5 terabaitų. Tai gali skirtis priklausomai nuo nustatymų. Ir dar turime vietos kūrėjams.

Tokia sistema gali būti naudojama įvairiais atvejais.

• Tai kūrėjai, DBA užklausų patvirtinimui, optimizavimui.

• Tai gali būti naudojama atliekant kokybės užtikrinimo testavimą, norint patikrinti tam tikrą perkėlimą prieš išleidžiant jį į gamybinę versiją. Taip pat galime sukurti specialias QA aplinkas su tikrais duomenimis, kur jie gali išbandyti naujas funkcijas. Ir tai užtruks kelias sekundes, o ne laukimo valandas, o galbūt ir dienų kai kuriais kitais atvejais, kai nenaudojamos plonos kopijos.

• Ir dar vienas atvejis. Jei įmonėje nėra sukurtos analitinės sistemos, galime išskirti ploną produktų bazės kloną ir pateikti jį ilgoms užklausoms ar specialiems indeksams, kuriuos galima naudoti analitikoje.

Taikant šį metodą:

1. Maža „gaminio“ klaidų tikimybė, nes visus pakeitimus išbandėme viso dydžio duomenimis.

2. Turime testavimo kultūrą, nes dabar jums nereikia valandų valandas laukti savo stendo.

3. Ir nėra jokio barjero, jokio laukimo tarp testų. Tikrai galite nueiti ir patikrinti. Ir taip bus geriau, nes paspartinsime plėtrą.

• Bus mažiau pertvarkymo. Mažiau klaidų atsiras gaminant. Vėliau juos refaktoruosime mažiau.

• Galime atšaukti negrįžtamus pokyčius. Tai nėra standartinis požiūris.

1. Tai naudinga, nes dalijamės bandymų stendų ištekliais.

Jau gerai, bet ką dar būtų galima paspartinti?

Tokios sistemos dėka galime gerokai sumažinti slenkstį norint patekti į tokį testavimą.

Dabar yra užburtas ratas, kai kūrėjas turi tapti ekspertu, kad gautų prieigą prie tikrų pilno dydžio duomenų. Jam tokia prieiga turi būti patikėta.

Bet kaip auginti, jei jo nėra. Bet ką daryti, jei turite tik labai nedidelį testo duomenų rinkinį? Tada negausite jokios tikros patirties.

Kaip ištrūkti iš šio rato? Kaip pirmąją sąsają, patogią bet kokio lygio kūrėjams, pasirinkome „Slack“ robotą. Bet tai gali būti bet kokia kita sąsaja.

Ką tai leidžia daryti? Galite paimti konkrečią užklausą ir nusiųsti ją į specialų duomenų bazės kanalą. Mes automatiškai įdiegsime ploną kloną per kelias sekundes. Vykdykime šią užklausą. Renkame metrikas ir rekomendacijas. Parodykime vizualizaciją. Ir tada šis klonas liks, kad būtų galima kažkaip optimizuoti šią užklausą, pridėti indeksų ir pan.

Be to, „Slack“ suteikia mums galimybių bendradarbiauti. Kadangi tai tik kanalas, galite pradėti diskutuoti apie šią užklausą ten pat tokio prašymo gijoje, ping savo kolegoms, DBA, kurie yra įmonės viduje.

Tačiau, žinoma, yra problemų. Kadangi tai yra realus pasaulis, o mes naudojame serverį, kuriame vienu metu yra daug klonų, turime suspausti klonams skirtą atminties kiekį ir procesoriaus galią.

Tačiau norint, kad šie testai būtų patikimi, turite kažkaip išspręsti šią problemą.

Akivaizdu, kad svarbiausia yra tie patys duomenys. Bet mes jį jau turime. Ir mes norime pasiekti tą pačią konfigūraciją. Ir mes galime pateikti tokią beveik identišką konfigūraciją.

Būtų puiku turėti tokią pat techninę įrangą kaip ir gamyboje, tačiau ji gali skirtis.

Prisiminkime, kaip Postgres veikia su atmintimi. Turime dvi talpyklas. Vienas iš failų sistemos ir vienas vietinis „Postgres“, t. y. bendro buferio talpykla.

Svarbu pažymėti, kad bendrinamo buferio talpykla paskirstoma paleidus Postgres, atsižvelgiant į tai, kokį dydį nurodote konfigūracijoje.

O antroji talpykla naudoja visą turimą vietą.

O kai vienoje mašinoje padarome kelis klonus, išeina, kad pamažu pildome atmintį. Ir gerąja prasme bendroji buferio talpykla sudaro 25% viso įrenginyje esančios atminties kiekio.

Ir pasirodo, kad jei nepakeisime šio parametro, tai vienoje mašinoje galėsime paleisti tik 4 egzempliorius, tai yra iš viso 4 iš šių plonų klonų. Ir tai, žinoma, yra blogai, nes norime jų turėti daug daugiau.

Tačiau, kita vertus, buferio talpykla naudojama indeksų užklausoms vykdyti, tai yra, planas priklauso nuo to, kokia talpyklos talpa yra mūsų. O jei tik imsime šį parametrą ir sumažinsime, mūsų planai gali labai pasikeisti.

Pavyzdžiui, jei turime didelę prod talpyklą, „Postgres“ norės naudoti indeksą. O jei ne, tada bus „SeqScan“. O kokia prasmė būtų, jei mūsų planai nesutaptų?

Bet čia mes darome išvadą, kad iš tikrųjų planas Postgres nepriklauso nuo konkretaus dydžio, nurodyto plano Shared Buffer, jis priklauso nuo efektyvaus_cache_size.

Efektyvus_cache_size yra apskaičiuotas mums prieinamos talpyklos kiekis, t. y. buferio talpyklos ir failų sistemos talpyklos suma. Tai nustato konfigūracija. Ir ši atmintis nėra skirta.

Ir dėl šio parametro galime apgauti Postgresą, sakydami, kad iš tikrųjų turime daug duomenų, net jei šių duomenų neturime. Taigi planai visiškai sutaps su gamyba.

Bet tai gali turėti įtakos laikui. Užklausas optimizuojame pagal laiką, tačiau svarbu, kad laikas priklausytų nuo daugelio veiksnių:

• Tai priklauso nuo apkrovos, kuri šiuo metu yra pagaminta.

• Tai priklauso nuo pačios mašinos savybių.

Ir tai yra netiesioginis parametras, tačiau iš tikrųjų galime optimizuoti tiksliai pagal duomenų kiekį, kurį ši užklausa nuskaitys, kad gautume rezultatą.

Ir jei norite, kad laikas būtų artimas tam, ką matysime prod, tada turime paimti labiausiai panašią aparatinę įrangą ir, galbūt, dar daugiau, kad visi klonai tilptų. Bet tai yra kompromisas, t.y. gausite tuos pačius planus, pamatysite kiek duomenų perskaitys konkreti užklausa ir galėsite daryti išvadą, ar ši užklausa gera (ar migracija) ar bloga, ją dar reikia optimizuoti .

Pažiūrėkime, kaip Joe yra specialiai optimizuotas.

Paimkime užklausą iš realios sistemos. Šiuo atveju duomenų bazė yra 1 terabaitas. Ir mes norime suskaičiuoti naujų įrašų, kurie turėjo daugiau nei 10 paspaudimų, skaičių.

Rašome žinutę į kanalą, mums buvo dislokuotas klonas. Ir pamatysime, kad toks prašymas bus įvykdytas per 2,5 min. Tai pirmas dalykas, kurį pastebime.

B Joe parodys automatines rekomendacijas pagal planą ir metrikas.

Pamatysime, kad užklausa apdoroja per daug duomenų, kad gautų palyginti mažą eilučių skaičių. Ir reikia tam tikro specializuoto indekso, nes pastebėjome, kad užklausoje yra per daug filtruotų eilučių.

Pažiūrėkime atidžiau, kas atsitiko. Iš tiesų matome, kad iš failų talpyklos ar net disko perskaitėme beveik pusantro gigabaito duomenų. Ir tai nėra gerai, nes gavome tik 142 eilutes.

Ir, atrodytų, čia turime indekso nuskaitymą ir turėjome greitai pasisekti, bet kadangi išfiltravome per daug eilučių (turėjome jas skaičiuoti), užklausa pamažu pavyko.

Ir taip nutiko plane dėl to, kad sąlygos užklausoje ir sąlygos indekse iš dalies nesutampa.

Pabandykime patikslinti indeksą ir pažiūrėkime, kaip po to pasikeis užklausos vykdymas.

Indekso sukūrimas užtruko gana ilgai, bet dabar patikriname užklausą ir matome, kad laikas vietoj 2,5 minutės yra tik 156 milisekundės, tai yra pakankamai gerai. Ir mes nuskaitome tik 6 megabaitus duomenų.

Ir dabar mes naudojame tik indekso nuskaitymą.

Kita svarbi istorija – norime planą pateikti kažkaip suprantamiau. Vizualizaciją įdiegėme naudodami „Flame Graphs“.

Tai kitoks prašymas, intensyvesnis. Ir mes kuriame „Flame Graphs“ pagal du parametrus: tai yra duomenų kiekis, kurį konkretus mazgas suskaičiavo plane ir laiku, t.y. mazgo vykdymo laikas.

Čia galime palyginti konkrečius mazgus tarpusavyje. Ir bus aišku, kurio iš jų reikia daugiau ar mažiau, o tai paprastai sunku padaryti naudojant kitus atvaizdavimo būdus.

Žinoma, visi žino, paaiškinkite.depesz.com. Gera šios vizualizacijos savybė yra ta, kad mes išsaugome teksto planą ir kai kuriuos pagrindinius parametrus įdedame į lentelę, kad galėtume rūšiuoti.

O kūrėjai, kurie dar nesigilino į šią temą, taip pat naudojasi paaiškinimu.depesz.com, nes jiems lengviau suprasti, kurie rodikliai yra svarbūs, o kurie ne.

Yra naujas požiūris į vizualizaciją – tai paaiškinama.dalibo.com. Jie atlieka medžio vizualizaciją, tačiau labai sunku palyginti mazgus tarpusavyje. Čia galite gerai suprasti struktūrą, tačiau jei yra didelė užklausa, turėsite slinkti pirmyn ir atgal, bet taip pat pasirinkti.

bendradarbiavimą

Ir, kaip sakiau, „Slack“ suteikia mums galimybę bendradarbiauti. Pavyzdžiui, jei susiduriame su sudėtinga užklausa, kurią neaišku, kaip optimizuoti, galime išsiaiškinti šią problemą su kolegomis „Slack“ gijoje.

Mums atrodo, kad svarbu išbandyti viso dydžio duomenis. Norėdami tai padaryti, sukūrėme įrankį „Update Database Lab“, kuris yra atvirojo kodo. Taip pat galite naudoti Joe robotą. Galite pasiimti tai dabar ir įgyvendinti savo vietoje. Ten rasite visus vadovus.

Taip pat svarbu pažymėti, kad pats sprendimas nėra revoliucinis, nes yra Delphix, bet tai yra įmonės sprendimas. Jis visiškai uždaras, labai brangus. Mes specialiai specializuojamės „Postgres“. Tai visi atvirojo kodo produktai. Prisijunk prie mūsų!

Čia aš baigiu. Ačiū!

Klausimai

Sveiki! Ačiū už pranešimą! Labai įdomu, ypač man, nes prieš kurį laiką išsprendžiau tą pačią problemą. Ir todėl aš turiu keletą klausimų. Tikiuosi, kad gausiu bent dalį.

Įdomu, kaip skaičiuojate vietą šiai aplinkai? Ši technologija reiškia, kad tam tikromis aplinkybėmis jūsų klonai gali išaugti iki didžiausio dydžio. Grubiai tariant, jei turite dešimties terabaitų duomenų bazę ir 10 klonų, tuomet nesunku imituoti situaciją, kai kiekvienas klonas sveria 10 unikalių duomenų. Kaip apskaičiuoti šią vietą, tai yra tą deltą, apie kurią kalbėjote, kurioje gyvens šie klonai?

Geras klausimas. Čia svarbu sekti konkrečius klonus. Ir jei klonas turi kokių nors per didelių pokyčių, jis pradeda augti, tada pirmiausia galime įspėti vartotoją apie tai arba nedelsiant sustabdyti šį kloną, kad nesusidurtume su nesėkme.

Taip, turiu įdėtą klausimą. Tai yra, kaip užtikrinate šių modulių gyvavimo ciklą? Turime šią problemą ir visiškai atskirą istoriją. Kaip tai atsitinka?

Kiekvienam klonui yra tam tikras ttl. Iš esmės mes turime fiksuotą ttl.

Kas, jei ne paslaptis?

1 valanda, t.y. tuščiąja eiga - 1 valanda. Jei jis nenaudojamas, tada sumušame. Tačiau čia nieko nuostabaus, nes kloną galime pakelti per kelias sekundes. Ir jei vėl prireiks, prašau.

Mane domina ir technologijų pasirinkimas, nes, pavyzdžiui, dėl vienokių ar kitokių priežasčių lygiagrečiai naudojame kelis metodus. Kodėl ZFS? Kodėl nepasinaudojote LVM? Minėjote, kad buvo problemų su LVM. Kokios buvo problemos? Mano nuomone, optimaliausias variantas yra su saugykla, našumo prasme.

Kokia yra pagrindinė ZFS problema? Faktas, kad turite veikti tame pačiame pagrindiniame kompiuteryje, t. y. visi egzemplioriai veiks toje pačioje OS. O saugojimo atveju galite prijungti skirtingą įrangą. Ir kliūtis yra tik tie blokai, kurie yra saugojimo sistemoje. O technologijų pasirinkimo klausimas įdomus. Kodėl ne LVM?

Konkrečiai, mes galime aptarti LVM susitikimo metu. Apie saugojimą – tai tiesiog brangu. ZFS sistemą galime įdiegti bet kur. Galite įdiegti jį savo kompiuteryje. Galite tiesiog atsisiųsti saugyklą ir ją įdiegti. ZFS yra įdiegtas beveik visur, jei kalbame apie Linux. Tai yra, gauname labai lankstų sprendimą. Ir pats ZFS duoda labai daug. Galite įkelti tiek duomenų, kiek norite, prijungti daugybę diskų, yra momentinių nuotraukų. Ir, kaip sakiau, tai lengva administruoti. Tai reiškia, kad jis atrodo labai malonus naudoti. Jis išbandytas, jam daug metų. Jis turi labai didelę bendruomenę, kuri auga. ZFS yra labai patikimas sprendimas.

Nikolajus Samokhvalovas: Ar galiu daugiau pakomentuoti? Mano vardas Nikolajus, dirbame kartu su Anatolijumi. Sutinku, kad saugojimas yra puikus. Ir kai kurie mūsų klientai turi „Pure Storage“ ir kt.

Anatolijus teisingai pažymėjo, kad mes orientuojamės į moduliškumą. Ir ateityje galėsite įdiegti vieną sąsają – padaryti momentinę nuotrauką, padaryti kloną, sunaikinti kloną. Viskas paprasta. Ir saugojimas yra šaunus, jei taip.

Tačiau ZFS yra prieinamas visiems. DelPhix jau pakanka, jie turi 300 klientų. Iš jų „Fortune 100“ turi 50 klientų, t.y. jie skirti NASA ir tt Atėjo laikas visiems gauti šią technologiją. Štai kodėl turime atvirojo kodo „Core“. Turime sąsajos dalį, kuri nėra atvirojo kodo. Tai platforma, kurią parodysime. Tačiau norime, kad ji būtų prieinama visiems. Norime padaryti revoliuciją, kad visi bandytojai nustotų spėlioti apie nešiojamuosius kompiuterius. Turime parašyti SELECT ir iš karto matyti, kad tai lėta. Nustokite laukti, kol DBA jums apie tai pasakys. Čia yra pagrindinis tikslas. Ir aš manau, kad mes visi prie to ateisime. Ir mes gaminame tai, kad kiekvienas turėtų. Todėl ZFS, nes jis bus prieinamas visur. Ačiū bendruomenei už problemų sprendimą ir atvirojo kodo licenciją ir pan.*

Sveikinimai! Ačiū už pranešimą! Mano vardas Maksimas. Mes sprendėme tuos pačius klausimus. Jie nusprendė patys. Kaip dalijatės ištekliais tarp šių klonų? Kiekvienas klonas bet kuriuo metu gali atlikti savo darbą: vienas išbando vieną, kitas kitą, kažkas sukuria indeksą, kažkas turi sunkų darbą. Ir jei vis tiek galite padalinti iš procesoriaus, tai iš IO, kaip padalinti? Tai pirmas klausimas.

O antras klausimas – apie tribūnų nepanašumą. Tarkim pas mane cia ZFS ir viskas faina, bet klientas ant prod turi ne ZFS, o pvz ext4. Kaip šiuo atveju?

Klausimai labai geri. Šią problemą šiek tiek paminėjau tuo, kad dalijamės ištekliais. Ir sprendimas yra toks. Įsivaizduokite, kad išbandote scenoje. Vienu metu gali būti ir tokia situacija, kad kažkas duoda vieną krūvį, kažkas kitas. Ir dėl to matosi nesuprantami rodikliai. Netgi ta pati problema gali kilti su prod. Kai nori patikrinti kokią nors užklausą ir pamatyti, kad su ja yra kažkokia problema - veikia lėtai, tai iš tikrųjų problema buvo ne užklausoje, o tame, kad yra kažkokia paralelinė apkrova.

Todėl čia svarbu sutelkti dėmesį į tai, koks bus planas, kokių veiksmų plane imsimės ir kiek duomenų tam surinksime. Tai, kad, pavyzdžiui, mūsų diskai bus kažkuo įkrauti, turės įtakos laikui. Tačiau galime įvertinti, kiek ši užklausa įkeliama pagal duomenų kiekį. Ne taip svarbu, kad tuo pačiu metu būtų vykdoma kokia nors egzekucija.

Turiu du klausimus. Tai labai šaunus dalykas. Ar buvo atvejų, kai gamybos duomenys yra labai svarbūs, pavyzdžiui, kredito kortelių numeriai? Ar jau kažkas paruošta, ar tai atskira užduotis? Ir antras klausimas – ar yra kažkas panašaus MySQL?

Apie duomenis. Mes darysime užmaskavimą, kol to nepadarysime. Bet jei įdiegiate tiksliai Joe, jei nesuteiksite prieigos kūrėjams, tada nėra prieigos prie duomenų. Kodėl? Nes Džo nerodo duomenų. Rodo tik metrikas, planus ir viskas. Tai buvo padaryta tyčia, nes tai yra vienas iš mūsų kliento reikalavimų. Jie norėjo turėti galimybę optimizuoti nesuteikdami visiems prieigos.

Apie MySQL. Šią sistemą galima naudoti viskam, kas išsaugo būseną diske. Kadangi atliekame Postgres, dabar visų pirma atliekame visą Postgres automatizavimą. Norime automatizuoti duomenų gavimą iš atsarginės kopijos. „Postgres“ konfigūruojame teisingai. Mes žinome, kaip suderinti planus ir pan.

Tačiau kadangi sistema yra išplečiama, ji taip pat gali būti naudojama MySQL. Ir yra tokių pavyzdžių. „Yandex“ turi panašų dalyką, bet niekur to neskelbia. Jie jį naudoja „Yandex.Metrica“. Ir yra tik istorija apie MySQL. Tačiau technologijos yra tos pačios, ZFS.

Ačiū už pranešimą! Aš taip pat turiu porą klausimų. Minėjote, kad klonavimas gali būti naudojamas analizei, pavyzdžiui, norint sukurti papildomus indeksus. Ar galite papasakoti šiek tiek daugiau apie tai, kaip tai veikia?

Ir iš karto užduosiu antrą klausimą apie stendų panašumą, planų panašumą. Planas priklauso ir nuo „Postgres“ surinktos statistikos. Kaip sprendžiate šią problemą?

Konkrečių atvejų, anot analitikos, nėra, nes dar nesinaudojome, bet tokia galimybė yra. Jei kalbame apie indeksus, įsivaizduokite, kad užklausa persekioja lentelę su šimtais milijonų įrašų ir stulpeliu, kuris paprastai neindeksuojamas prod. Ir mes norime ten paskaičiuoti kai kuriuos duomenis. Jei ši užklausa nusiųsta į prod, tai gali būti, kad prod bus paprasta, nes užklausa ten bus apdorojama minutę.

Gerai, padarykime ploną kloną, kurio nėra baisu sustoti kelioms minutėms. O kad analitiką būtų patogiau skaityti, pridėsime indeksus tiems stulpeliams, kurių duomenys mus domina.

Indeksas bus kuriamas kiekvieną kartą?

Galite padaryti taip, kad paliestume duomenis, padarytume momentines nuotraukas, tada atsigausime iš šios momentinės nuotraukos ir pateiksime naujų užklausų. Tai yra, galite tai padaryti taip, kad galėtumėte sukurti naujus klonus su jau pritvirtintais indeksais.

Kalbant apie statistiką, jei atkursime iš atsarginės kopijos, jei atliksime replikaciją, mūsų statistika bus lygiai tokia pati. Kadangi turime visą fizinių duomenų struktūrą, tai yra, pateiksime duomenis tokius, kokie jie yra, su visa statistikos metrika.

Čia yra kita problema. Jei naudojate debesies sprendimą, tada ten yra tik loginiai išmetimai, nes Google, Amazon neleidžia daryti fizinės kopijos. Bus problema.

Ačiū už pranešimą. Čia buvo du geri klausimai apie MySQL ir dalijimąsi ištekliais. Bet iš tikrųjų viskas priklauso nuo to, kad tai nėra konkrečios DBVS, o visos failų sistemos tema. Atitinkamai, išteklių dalijimosi klausimai taip pat turėtų būti sprendžiami iš ten, ne galų gale, kad tai yra „Postgres“, o failų sistemoje, pavyzdžiui, serveryje.

Mano klausimas šiek tiek kitoks. Jis yra arčiau daugiasluoksnės duomenų bazės, kur yra keli sluoksniai. Pavyzdžiui, mes nustatome dešimties terabaitų vaizdo atnaujinimą, replikuojame. Šį sprendimą mes naudojame būtent duomenų bazėms. Vyksta replikacija, duomenys atnaujinami. Čia lygiagrečiai dirba 100 darbuotojų, kurie nuolat paleidžia šiuos skirtingus kadrus. Ką daryti? Kaip įsitikinti, kad nėra konflikto, kad jie paleido vieną, o tada pasikeitė failų sistema ir visos šios nuotraukos išėjo?

Jie nevyks, nes taip veikia ZFS. Failų sistemos pakeitimus, kurie atsiranda dėl replikacijos, galime laikyti atskirai vienoje gijoje. Ir išsaugokite klonus, kuriuos kūrėjai naudoja senesnėse duomenų versijose. Ir mums tai veikia, viskas čia tvarkoje.

Pasirodo, kad atnaujinimas vyks kaip papildomas sluoksnis, o visos naujos nuotraukos jau bus, remiantis šiuo sluoksniu, tiesa?

Iš ankstesnių sluoksnių, kurie buvo iš ankstesnių replikacijų.

Ankstesni sluoksniai nukris, bet jie bus susiję su senuoju sluoksniu ir ar jie paims naujus vaizdus iš paskutinio sluoksnio, kuris buvo gautas atnaujinime?

Apskritai, taip.

Tada turėsime iki figos sluoksnių. Ir laikui bėgant juos reikės suspausti?

Taip viskas teisinga. Yra kažkoks langas. Kas savaitę darome momentines nuotraukas. Tai priklauso nuo to, kokius išteklius turite. Jei turite galimybę saugoti daug duomenų, momentines nuotraukas galite saugoti ilgą laiką. Jie savaime neišnyks. Duomenų sugadinimo nebus. Jei momentinės nuotraukos yra pasenusios, kaip mums atrodo, t.y. tai priklauso nuo įmonės politikos, galime jas tiesiog ištrinti ir atlaisvinti vietos.

Sveiki, ačiū už pranešimą! Klausimas apie Joe. Sakėte, kad klientas nenorėjo visiems suteikti prieigos prie duomenų. Griežtai tariant, jei asmuo turi paaiškinimo analizės rezultatą, jis gali peržiūrėti duomenis.

Tai taip. Pavyzdžiui, galime parašyti: „SELECT FROM WHERE email = to that“. Tai yra, mes nematysime pačių duomenų, bet galime pamatyti kai kuriuos netiesioginius ženklus. Tai reikia suprasti. Bet, kita vertus, viskas yra. Turime žurnalo auditą, kontroliuojame kitus kolegas, kurie taip pat mato, ką daro kūrėjai. Ir jei kas nors bandys tai padaryti, saugos tarnyba ateis pas juos ir dirbs šiuo klausimu.

Laba diena Ačiū už pranešimą! Turiu trumpą klausimą. Jei įmonė nenaudoja „Slack“, ar dabar ji yra įpareigota, ar kūrėjai gali įdiegti egzempliorius, norėdami prijungti bandomąją programą prie duomenų bazių?

Dabar yra nuoroda į Slack, t.y. nėra jokio kito pasiuntinio, bet labai noriu padėti ir kitiems pasiuntiniams. Ką tu gali padaryti? Galite įdiegti DB Lab be Joe, eiti su REST API arba mūsų platformos pagalba ir kurti klonus bei prisijungti prie PSQL. Bet tai galima padaryti, jei esate pasirengę suteikti kūrėjams prieigą prie duomenų, nes ekrano nebebus.

Man nereikia šio sluoksnio, bet man reikia tokios galimybės.

Tada taip, tai galima padaryti.

Šaltinis: www.habr.com