DBA bot Joe. Anatoly Stansler (Postgres.ai)

Cum înțelege un dezvoltator backend că o interogare SQL va funcționa bine pe un „prod”? În companiile mari sau în creștere rapidă, nu toată lumea are acces la „produs”. Și cu acces, nu toate solicitările pot fi verificate fără probleme, iar crearea unei copii a bazei de date durează adesea ore. Pentru a rezolva aceste probleme, am creat un DBA artificial - Joe. A fost deja implementat cu succes în mai multe companii și ajută mai mult de o duzină de dezvoltatori.

video:

Salutare tuturor! Numele meu este Anatoly Stansler. Lucrez pentru o companie postgres.ai. Ne angajăm să accelerăm procesul de dezvoltare prin eliminarea întârzierilor asociate cu activitatea Postgres de la dezvoltatori, DBA și QA.

Avem clienți grozavi și astăzi o parte a raportului va fi dedicată cazurilor pe care le-am întâlnit în timp ce lucrăm cu ei. Voi vorbi despre modul în care i-am ajutat să rezolve probleme destul de grave.

Când dezvoltăm și facem migrații complexe de mare sarcină, ne punem întrebarea: „Va decola această migrare?”. Folosim recenzia, folosim cunoștințele unor colegi mai experimentați, experți DBA. Și pot spune dacă va zbura sau nu.

Dar poate că ar fi mai bine dacă l-am putea testa noi înșine pe copii la dimensiune completă. Și astăzi vom vorbi doar despre ce abordări ale testării sunt acum și cum se poate face mai bine și cu ce instrumente. Vom vorbi, de asemenea, despre avantajele și dezavantajele unor astfel de abordări și despre ce putem repara aici.

Cine a făcut vreodată indici direct pe produs sau a făcut vreo modificare? Destul de puțin de. Și pentru cine a dus acest lucru la faptul că s-au pierdut datele sau au existat perioade de nefuncționare? Atunci știi această durere. Slavă Domnului că există copii de rezervă.

Prima abordare este testarea în prod. Sau, când un dezvoltator stă pe o mașină locală, are date de testare, există un fel de selecție limitată. Și ne lansăm pentru a ascunde și obținem această situație.

Doare, e scump. Probabil că e mai bine să nu o faci.

Și care este cel mai bun mod de a o face?

Să luăm în scenă și să selectăm o parte din produs acolo. Sau, în cel mai bun caz, să luăm un adevărat prod, toate datele. Și după ce l-am dezvoltat la nivel local, vom verifica suplimentar punerea în scenă.

Acest lucru ne va permite să eliminăm unele dintre erori, adică să le împiedicăm să fie pe produs.

Care sunt problemele?

• Problema este că împărtășim această punere în scenă cu colegii. Și de foarte multe ori se întâmplă să faci un fel de schimbare, bam - și nu există date, munca este pe scurgere. Staging a fost multi-terabyte. Și trebuie să aștepți mult pentru ca acesta să se ridice din nou. Și decidem să o finalizăm mâine. Gata, avem o dezvoltare.
• Și, desigur, avem mulți colegi care lucrează acolo, multe echipe. Și trebuie făcut manual. Și acest lucru este incomod.

Și merită să spunem că avem o singură încercare, o singură lovitură, dacă vrem să facem unele modificări în baza de date, atingem datele, schimbăm structura. Și dacă ceva a mers prost, dacă a existat o eroare în migrare, atunci nu vom retrage rapid înapoi.

Aceasta este mai bună decât abordarea anterioară, dar există încă o probabilitate mare ca un fel de eroare să ajungă la producție.

Ce ne împiedică să oferim fiecărui dezvoltator un banc de testare, o copie la dimensiune completă? Cred că este clar ce stă în cale.

Cine are o bază de date mai mare de un terabyte? Mai mult de jumătate din cameră.

Și este clar că păstrarea mașinilor pentru fiecare dezvoltator, atunci când există o producție atât de mare, este foarte costisitoare și, în plus, durează mult.

Avem clienți care și-au dat seama că este foarte important să testăm toate modificările pe copii la dimensiune completă, dar baza lor de date este mai mică de un terabyte și nu există resurse pentru a păstra un banc de testare pentru fiecare dezvoltator. Prin urmare, trebuie să descarce depozitele local pe mașina lor și să testeze în acest fel. Ia mult timp.

Chiar dacă o faci în interiorul infrastructurii, atunci descărcarea unui terabyte de date pe oră este deja foarte bună. Dar folosesc depozite logice, se descarcă local din cloud. Pentru ei, viteza este de aproximativ 200 de gigaocteți pe oră. Și mai este nevoie de timp pentru a se întoarce de la depozitul logic, a rula indecșii etc.

Dar folosesc această abordare pentru că le permite să păstreze produsul de încredere.

Ce putem face aici? Să facem bancurile de testare ieftine și să oferim fiecărui dezvoltator propriul banc de testare.

Și acest lucru este posibil.

Și în această abordare, atunci când facem clone subțiri pentru fiecare dezvoltator, le putem partaja pe o singură mașină. De exemplu, dacă aveți o bază de date de 10 TB și doriți să o oferiți la 10 dezvoltatori, nu trebuie să aveți baze de date de XNUMX x XNUMX TB. Aveți nevoie doar de o singură mașină pentru a face copii izolate subțiri pentru fiecare dezvoltator folosind o singură mașină. Vă voi spune cum funcționează puțin mai târziu.

Exemplu real:

• DB - 4,5 terabytes.

• Putem obține copii independente în 30 de secunde.

Nu trebuie să așteptați un stand de testare și să depindeți de cât de mare este. Îl poți obține în câteva secunde. Vor fi medii complet izolate, dar care împărtășesc date între ele.

Asta e super. Aici vorbim despre magie și un univers paralel.

În cazul nostru, acest lucru funcționează folosind sistemul OpenZFS.

OpenZFS este un sistem de fișiere copy-on-write care acceptă instantanee și clonări din cutie. Este fiabil și scalabil. Ea este foarte ușor de gestionat. Poate fi implementat literalmente în două echipe.

Există și alte opțiuni:

• lvm,

• Depozitare (de exemplu, Pure Storage).

Laboratorul de baze de date despre care vorbesc este modular. Poate fi implementat folosind aceste opțiuni. Dar deocamdată, ne-am concentrat pe OpenZFS, deoarece au existat probleme în special cu LVM.

Cum functioneaza? În loc să suprascriem datele de fiecare dată când le schimbăm, le salvăm pur și simplu marcând că aceste date noi provin dintr-un nou moment în timp, un nou instantaneu.

Și în viitor, când vrem să facem rollback sau vrem să facem o nouă clonă dintr-o versiune mai veche, spunem doar: „OK, dă-ne aceste blocuri de date care sunt marcate astfel”.

Și acest utilizator va lucra cu un astfel de set de date. Le va schimba treptat, își va face propriile instantanee.

Și vom ramifica. Fiecare dezvoltator în cazul nostru va avea posibilitatea de a avea propria sa clonă pe care o editează, iar datele care sunt partajate vor fi partajate între toată lumea.

Pentru a implementa un astfel de sistem acasă, trebuie să rezolvați două probleme:

• Prima este sursa datelor, de unde le veți lua. Puteți configura replicarea cu producția. Puteți utiliza deja backup-urile pe care le-ați configurat, sper. WAL-E, WAL-G sau Barman. Și chiar dacă utilizați un fel de soluție Cloud, cum ar fi RDS sau Cloud SQL, atunci puteți utiliza depozite logice. Dar tot te sfătuim să folosești backup-uri, pentru că cu această abordare vei păstra și structura fizică a fișierelor, ceea ce îți va permite să fii și mai aproape de metricile pe care le-ai vedea în producție pentru a prinde acele probleme care există.

• Al doilea este locul în care doriți să găzduiți Laboratorul de baze de date. Ar putea fi Cloud, ar putea fi On-premise. Este important să spunem aici că ZFS acceptă compresia datelor. Și o face destul de bine.

Imaginați-vă că pentru fiecare astfel de clonă, în funcție de operațiunile pe care le facem cu baza, va crește un fel de dev. Pentru aceasta, dev-ul va avea nevoie și de spațiu. Dar datorită faptului că am luat o bază de 4,5 terabytes, ZFS o va comprima la 3,5 terabytes. Acest lucru poate varia în funcție de setări. Și mai avem loc pentru dev.

Un astfel de sistem poate fi folosit pentru diferite cazuri.

• Aceștia sunt dezvoltatori, DBA pentru validarea interogărilor, pentru optimizare.

• Aceasta poate fi folosită în testarea QA pentru a testa o anumită migrare înainte de a o lansa la prod. De asemenea, putem crea medii speciale pentru QA cu date reale, unde pot testa noi funcționalități. Și va dura câteva secunde în loc de ore de așteptare, și poate zile în alte cazuri în care nu sunt folosite copii subțiri.

• Și încă un caz. Dacă compania nu are un sistem de analiză configurat, atunci putem izola o clonă subțire a bazei de produse și o putem oferi interogări lungi sau indecși speciali care pot fi utilizați în analiză.

Cu această abordare:

1. Probabilitate scăzută de erori la „prod”, deoarece am testat toate modificările pe date de dimensiune completă.

2. Avem o cultură a testării, pentru că acum nu trebuie să așteptați ore întregi pentru propriul stand.

3. Și nu există nicio barieră, nicio așteptare între teste. Chiar poți să te duci și să verifici. Și va fi mai bine așa, pe măsură ce grăbim dezvoltarea.

• Va fi mai puțină refactorizare. Mai puține erori vor ajunge în prod. Le vom refactoriza mai puțin mai târziu.

• Putem inversa schimbările ireversibile. Aceasta nu este abordarea standard.

1. Acest lucru este benefic pentru că împărțim resursele bancilor de testare.

Deja bine, dar ce altceva ar putea fi accelerat?

Datorită unui astfel de sistem, putem reduce foarte mult pragul de intrare în astfel de testare.

Acum există un cerc vicios în care un dezvoltator trebuie să devină un expert pentru a avea acces la date reale de dimensiune completă. El trebuie să aibă încredere cu un astfel de acces.

Dar cum să crești dacă nu este acolo. Dar ce se întâmplă dacă ai la dispoziție doar un set foarte mic de date de testare? Atunci nu vei primi nicio experiență reală.

Cum să ieși din acest cerc? Ca primă interfață, convenabilă pentru dezvoltatorii de orice nivel, am ales botul Slack. Dar poate fi orice altă interfață.

Ce vă permite să faceți? Puteți prelua o anumită interogare și o puteți trimite către un canal special pentru baza de date. Vom implementa automat o clonă subțire în câteva secunde. Să rulăm această cerere. Colectăm valori și recomandări. Să arătăm o vizualizare. Și apoi această clonă va rămâne astfel încât această interogare să poată fi cumva optimizată, să adauge indecși etc.

Și, de asemenea, Slack ne oferă oportunități de colaborare imediată. Deoarece acesta este doar un canal, puteți începe să discutați această solicitare chiar acolo în firul pentru o astfel de solicitare, trimiteți ping colegilor, DBA care sunt în interiorul companiei.

Dar există, desigur, probleme. Deoarece aceasta este lumea reală și folosim un server care găzduiește multe clone simultan, trebuie să comprimăm cantitatea de memorie și puterea procesorului disponibilă pentru clone.

Dar pentru ca aceste teste să fie plauzibile, trebuie să rezolvați cumva această problemă.

Este clar că punctul important sunt aceleași date. Dar îl avem deja. Și vrem să obținem aceeași configurație. Și putem da o astfel de configurație aproape identică.

Ar fi tare să avem același hardware ca în producție, dar poate diferi.

Să ne amintim cum funcționează Postgres cu memoria. Avem două cache-uri. Unul din sistemul de fișiere și unul nativ Postgres, adică Shared Buffer Cache.

Este important să rețineți că Shared Buffer Cache este alocat la pornirea Postgres, în funcție de dimensiunea pe care o specificați în configurație.

Iar al doilea cache folosește tot spațiul disponibil.

Și când facem mai multe clone pe o singură mașină, se dovedește că umplem treptat memoria. Și într-un sens bun, Shared Buffer Cache reprezintă 25% din cantitatea totală de memorie disponibilă pe computer.

Și se dovedește că, dacă nu modificăm acest parametru, atunci vom putea rula doar 4 instanțe pe o singură mașină, adică 4 dintre toate astfel de clone subțiri. Și asta, desigur, este rău, pentru că vrem să avem mult mai multe dintre ele.

Dar, pe de altă parte, Buffer Cache este folosit pentru a executa interogări pentru indexuri, adică planul depinde de cât de mari sunt cache-urile noastre. Și dacă luăm acest parametru și îl reducem, atunci planurile noastre se pot schimba foarte mult.

De exemplu, dacă avem un cache mare pe prod, atunci Postgres va prefera să folosească un index. Și dacă nu, atunci va exista SeqScan. Și ce rost ar avea dacă planurile noastre nu ar coincide?

Dar aici ajungem la concluzia că, de fapt, planul din Postgres nu depinde de dimensiunea specifică specificată în Shared Buffer din plan, depinde de effective_cache_size.

Effective_cache_size este cantitatea estimată de cache disponibilă pentru noi, adică suma cache-ului tampon și a cache-ului sistemului de fișiere. Acesta este setat de config. Și această memorie nu este alocată.

Și datorită acestui parametru, îl putem păcăli pe Postgres, spunând că de fapt avem o mulțime de date disponibile, chiar dacă nu avem aceste date. Și astfel, planurile vor coincide complet cu producția.

Dar acest lucru poate afecta momentul. Și optimizăm interogările în funcție de sincronizare, dar este important ca sincronizarea depinde de mulți factori:

• Depinde de sarcina care este în prezent pe produs.

• Depinde de caracteristicile mașinii în sine.

Și acesta este un parametru indirect, dar de fapt putem optimiza exact după cantitatea de date pe care o va citi această interogare pentru a obține rezultatul.

Și dacă doriți ca momentul să fie aproape de ceea ce vom vedea în prod, atunci trebuie să luăm cel mai asemănător hardware și, eventual, chiar mai mult, astfel încât toate clonele să se potrivească. Dar acesta este un compromis, adică veți obține aceleași planuri, veți vedea câte date va citi o anumită interogare și veți putea trage concluzia dacă această interogare este bună (sau migrare) sau proastă, mai trebuie să fie optimizată .

Să aruncăm o privire la modul în care Joe este optimizat în mod specific.

Să luăm o cerere de la un sistem real. În acest caz, baza de date este de 1 terabyte. Și vrem să numărăm numărul de postări noi care au avut mai mult de 10 aprecieri.

Scriem un mesaj pe canal, o clonă a fost implementată pentru noi. Și vom vedea că o astfel de solicitare se va finaliza în 2,5 minute. Acesta este primul lucru pe care îl observăm.

B Joe vă va arăta recomandări automate bazate pe plan și valori.

Vom vedea că interogarea procesează prea multe date pentru a obține un număr relativ mic de rânduri. Și este nevoie de un fel de index specializat, deoarece am observat că există prea multe rânduri filtrate în interogare.

Să aruncăm o privire mai atentă la ceea ce s-a întâmplat. Într-adevăr, vedem că am citit aproape un giga și jumătate de date din memoria cache a fișierelor sau chiar de pe disc. Și asta nu este bine, pentru că avem doar 142 de linii.

Și, se pare, avem o scanare de index aici și ar fi trebuit să funcționeze rapid, dar din moment ce am filtrat prea multe linii (a trebuit să le numărăm), cererea a funcționat încet.

Și acest lucru s-a întâmplat în plan datorită faptului că condițiile din interogare și condițiile din index nu se potrivesc parțial.

Să încercăm să facem indexul mai precis și să vedem cum se schimbă execuția interogării după aceea.

Crearea indexului a durat destul de mult, dar acum verificăm interogarea și vedem că timpul în loc de 2,5 minute este de doar 156 de milisecunde, ceea ce este suficient de bun. Și citim doar 6 megaocteți de date.

Și acum folosim doar scanarea indexului.

O altă poveste importantă este că vrem să prezentăm planul într-un mod mai ușor de înțeles. Am implementat vizualizarea folosind Flame Graphs.

Aceasta este o cerere diferită, mai intensă. Și construim Flame Graphs în funcție de doi parametri: aceasta este cantitatea de date pe care un anumit nod a numărat-o în plan și sincronizare, adică timpul de execuție al nodului.

Aici putem compara anumite noduri unele cu altele. Și va fi clar care dintre ele durează mai mult sau mai puțin, ceea ce este de obicei dificil de realizat în alte metode de randare.

Desigur, toată lumea știe explic.depesz.com. O caracteristică bună a acestei vizualizări este că salvăm planul de text și, de asemenea, punem câțiva parametri de bază într-un tabel, astfel încât să putem sorta.

Iar dezvoltatorii care nu au aprofundat încă acest subiect folosesc și explic.depesz.com, pentru că le este mai ușor să-și dea seama ce valori sunt importante și care nu.

Există o nouă abordare a vizualizării - aceasta este explica.dalibo.com. Ei fac o vizualizare a arborelui, dar este foarte greu să compari nodurile între ele. Aici puteți înțelege bine structura, totuși, dacă există o cerere mare, atunci va trebui să derulați înainte și înapoi, dar și o opțiune.

colaborare

Și, așa cum am spus, Slack ne oferă posibilitatea de a colabora. De exemplu, dacă întâlnim o interogare complexă care nu este clar cum se poate optimiza, putem clarifica această problemă cu colegii noștri într-un thread din Slack.

Ni se pare că este important să testăm pe date de dimensiune completă. Pentru a face acest lucru, am creat instrumentul Update Database Lab, care este disponibil în sursă deschisă. Puteți folosi și botul Joe. Îl poți lua chiar acum și îl poți implementa la tine. Toate ghidurile sunt disponibile acolo.

De asemenea, este important de menționat că soluția în sine nu este revoluționară, deoarece există Delphix, dar este o soluție de întreprindere. Este complet închis, este foarte scump. Suntem specializați în special în Postgres. Toate acestea sunt produse open source. Alăturaţi-ne!

Aici termin. Mulțumesc!

întrebări

Buna ziua! Multumesc pentru raport! Foarte interesant, mai ales pentru mine, pentru că am rezolvat cam aceeași problemă în urmă cu ceva timp. Și așa am o serie de întrebări. Sper că voi primi măcar o parte din el.

Mă întreb cum calculezi locul pentru acest mediu? Tehnologia înseamnă că, în anumite circumstanțe, clonele tale pot crește la dimensiunea maximă. Aproximativ vorbind, dacă aveți o bază de date de zece terabyte și 10 clone, atunci este ușor să simulați o situație în care fiecare clonă cântărește 10 date unice. Cum calculezi acest loc, adică acea deltă despre care ai vorbit, în care vor trăi aceste clone?

Buna intrebare. Este important să urmăriți anumite clone aici. Și dacă o clonă are o schimbare prea mare, începe să crească, atunci putem mai întâi să emitem un avertisment utilizatorului despre acest lucru sau să oprim imediat această clonă, astfel încât să nu avem o situație de eșec.

Da, am o întrebare imbricată. Adică, cum vă asigurați ciclul de viață al acestor module? Avem această problemă și o poveste cu totul separată. Cum se întâmplă asta?

Există câteva ttl pentru fiecare clonă. Practic, avem un ttl fix.

Ce, dacă nu un secret?

1 oră, adică inactiv - 1 oră. Dacă nu este folosit, atunci îl lovim. Dar nu este nicio surpriză aici, deoarece putem ridica clona în câteva secunde. Și dacă ai nevoie din nou, atunci te rog.

Pe mine ma intereseaza si alegerea tehnologiilor, pentru ca, de exemplu, folosim mai multe metode in paralel dintr-un motiv sau altul. De ce ZFS? De ce nu ai folosit LVM? Ai menționat că au fost probleme cu LVM. Care au fost problemele? După părerea mea, cea mai optimă variantă este cu stocarea, din punct de vedere al performanței.

Care este principala problemă cu ZFS? Faptul că trebuie să rulați pe aceeași gazdă, adică toate instanțele vor trăi în același sistem de operare. Și în cazul depozitării, puteți conecta diferite echipamente. Iar blocajul sunt doar acele blocuri care se află pe sistemul de stocare. Și întrebarea privind alegerea tehnologiilor este interesantă. De ce nu LVM?

Mai exact, putem discuta despre LVM la întâlnire. Despre depozitare - este doar scump. Putem implementa sistemul ZFS oriunde. Îl puteți implementa pe mașina dvs. Puteți pur și simplu să descărcați depozitul și să îl implementați. ZFS este instalat aproape peste tot dacă vorbim de Linux. Adică obținem o soluție foarte flexibilă. Și din cutie, ZFS oferă multe. Puteți încărca câte date doriți, puteți conecta un număr mare de discuri, există instantanee. Și, după cum am spus, este ușor de administrat. Adică pare foarte plăcut de folosit. Este testat, are mulți ani. Are o comunitate foarte mare care crește. ZFS este o soluție foarte fiabilă.

Nikolai Samokhvalov: Pot să comentez mai departe? Numele meu este Nikolay, lucrăm împreună cu Anatoly. Sunt de acord că stocarea este grozavă. Și unii dintre clienții noștri au Pure Storage etc.

Anatoly a remarcat corect că ne concentrăm pe modularitate. Și în viitor, puteți implementa o singură interfață - faceți un instantaneu, faceți o clonă, distrugeți clona. Totul este ușor. Și depozitarea este rece, dacă este.

Dar ZFS este disponibil pentru toată lumea. DelPhix este deja suficient, au 300 de clienți. Dintre aceștia, Fortune 100 are 50 de clienți, adică sunt direcționați către NASA etc. Este timpul ca toată lumea să obțină această tehnologie. Și de aceea avem un Core cu sursă deschisă. Avem o parte de interfață care nu este open source. Aceasta este platforma pe care o vom arăta. Dar ne dorim să fie accesibil tuturor. Vrem să facem o revoluție pentru ca toți testerii să nu mai ghicească pe laptopuri. Trebuie să scriem SELECT și să vedem imediat că este lent. Nu mai așteptați ca DBA să vă spună despre asta. Iată scopul principal. Și cred că toți vom ajunge la asta. Și facem acest lucru pentru ca toată lumea să o aibă. Prin urmare, ZFS, pentru că va fi disponibil peste tot. Mulțumim comunității pentru rezolvarea problemelor și pentru că deține o licență open source etc.*

Salutari! Multumesc pentru raport! Numele meu este Maxim. Ne-am ocupat de aceleași probleme. Au decis singuri. Cum împărțiți resursele între aceste clone? Fiecare clonă își poate face propriul lucru în orice moment: unul testează un lucru, altul altul, cineva construiește un index, cineva are o treabă grea. Și dacă mai poți împărți după CPU, apoi după IO, cum împărțim? Aceasta este prima întrebare.

Și a doua întrebare este despre diferența dintre tribune. Să zicem că am ZFS aici și totul este cool, dar clientul pe prod nu are ZFS, ci ext4, de exemplu. Cum in acest caz?

Întrebările sunt foarte bune. Am menționat puțin această problemă cu faptul că împărtășim resurse. Și soluția este aceasta. Imaginați-vă că testați pe scenă. Poți avea și o astfel de situație în același timp în care cineva dă o sarcină, altcineva. Și, ca rezultat, vezi valori de neînțeles. Chiar și aceeași problemă poate fi cu prod. Când doriți să verificați o solicitare și să vedeți că există o problemă cu ea - funcționează încet, atunci de fapt problema nu a fost în cerere, ci în faptul că există un fel de încărcare paralelă.

Și, prin urmare, este important aici să ne concentrăm pe care va fi planul, ce pași vom face în plan și câte date vom strânge pentru aceasta. Faptul că discurile noastre, de exemplu, vor fi încărcate cu ceva, va afecta în mod specific sincronizarea. Dar putem estima cât de încărcată este această solicitare după cantitatea de date. Nu este atât de important ca în același timp să existe un fel de execuție.

Am două întrebări. Acestea sunt lucruri foarte tari. Au existat cazuri în care datele de producție sunt critice, cum ar fi numerele de card de credit? Există deja ceva gata sau este o sarcină separată? Și a doua întrebare - există așa ceva pentru MySQL?

Despre date. Vom face ofuscare până vom face. Dar dacă implementezi exact Joe, dacă nu dai acces dezvoltatorilor, atunci nu există acces la date. De ce? Pentru că Joe nu arată date. Arată doar valori, planuri și atât. Acest lucru a fost făcut intenționat, deoarece aceasta este una dintre cerințele clientului nostru. Au vrut să poată optimiza fără a oferi acces tuturor.

Despre MySQL. Acest sistem poate fi folosit pentru orice stochează starea pe disc. Și din moment ce facem Postgres, acum facem mai întâi toată automatizarea pentru Postgres. Dorim să automatizăm obținerea datelor dintr-o copie de rezervă. Configuram corect Postgres. Știm să facem planuri potrivite etc.

Dar, deoarece sistemul este extensibil, poate fi folosit și pentru MySQL. Și există astfel de exemple. Yandex are un lucru similar, dar nu îl publică nicăieri. Îl folosesc în interiorul Yandex.Metrica. Și există doar o poveste despre MySQL. Dar tehnologiile sunt aceleași, ZFS.

Multumesc pentru raport! Am si eu cateva intrebari. Ați menționat că clonarea poate fi folosită pentru analiză, de exemplu pentru a construi indecși suplimentari acolo. Poți spune puțin mai multe despre cum funcționează?

Și voi pune imediat a doua întrebare despre asemănarea standurilor, asemănarea planurilor. Planul depinde și de statisticile culese de Postgres. Cum rezolvi această problemă?

Potrivit analizei, nu există cazuri concrete, pentru că nu am folosit-o încă, dar există o astfel de oportunitate. Dacă vorbim de indici, atunci imaginați-vă că o interogare urmărește un tabel cu sute de milioane de înregistrări și o coloană care de obicei nu este indexată în prod. Și vrem să calculăm niște date acolo. Dacă această solicitare este trimisă la prod, atunci există posibilitatea ca aceasta să fie simplă pe prod, deoarece cererea va fi procesată acolo timp de un minut.

Ok, hai să facem o clonă subțire care nu este groaznic să oprești câteva minute. Și pentru a face mai confortabilă citirea analizelor, vom adăuga indici pentru acele coloane în care ne interesează datele.

Indexul va fi creat de fiecare dată?

Puteți face astfel încât să atingem datele, să facem instantanee, apoi ne vom recupera din acest instantaneu și vom genera noi solicitări. Adică, puteți face astfel încât să puteți ridica noi clone cu indici deja atașați.

Cât despre întrebarea despre statistici, dacă restaurăm dintr-o copie de rezervă, dacă facem replicare, atunci statisticile noastre vor fi exact aceleași. Pentru că avem întreaga structură fizică a datelor, adică vom aduce și datele așa cum sunt cu toate valorile statistice.

Iată o altă problemă. Dacă utilizați o soluție cloud, atunci sunt disponibile doar depozitele logice acolo, deoarece Google, Amazon nu vă permit să luați o copie fizică. Va fi o problemă.

Multumesc pentru raport. Au fost două întrebări bune aici despre MySQL și partajarea resurselor. Dar, de fapt, totul se reduce la faptul că acesta nu este un subiect specific DBMS, ci al sistemului de fișiere în ansamblu. Și, în consecință, problemele de partajare a resurselor ar trebui rezolvate și de acolo, nu la sfârșitul că este Postgres, ci în sistemul de fișiere, în server, de exemplu.

Întrebarea mea este puțin diferită. Este mai aproape de baza de date cu mai multe straturi, unde există mai multe straturi. De exemplu, am configurat o actualizare a imaginii de zece terabyte, replicăm. Și folosim în mod special această soluție pentru baze de date. Replicarea este în curs, datele sunt actualizate. Sunt 100 de angajați care lucrează în paralel, care lansează constant aceste fotografii diferite. Ce să fac? Cum să vă asigurați că nu există niciun conflict, că au lansat unul și apoi sistemul de fișiere s-a schimbat și toate aceste imagini au dispărut?

Nu vor merge pentru că așa funcționează ZFS. Putem păstra separat într-un fir de execuție modificările sistemului de fișiere care vin din cauza replicării. Și păstrați clonele pe care dezvoltatorii le folosesc pe versiunile mai vechi ale datelor. Și la noi funcționează, totul este în ordine cu asta.

Se pare că actualizarea va avea loc ca un strat suplimentar, iar toate imaginile noi vor merge deja, pe baza acestui strat, nu?

Din straturi anterioare care au fost din replicări anterioare.

Straturile anterioare vor cădea, dar se vor referi la stratul vechi și vor lua imagini noi din ultimul strat care a fost primit în actualizare?

În general, da.

Apoi, drept consecință, vom avea până la o smochină de straturi. Și în timp vor trebui să fie comprimate?

Da totul este corect. Există o fereastră. Păstrăm instantanee săptămânale. Depinde de ce resurse ai. Dacă aveți capacitatea de a stoca o mulțime de date, puteți stoca instantanee pentru o lungă perioadă de timp. Nu vor pleca singuri. Nu va exista corupție de date. Dacă instantaneele sunt depășite, așa cum ni se pare nouă, adică depinde de politica din companie, atunci putem pur și simplu să le ștergem și să eliberăm spațiu.

Salut, multumesc pentru raport! Întrebare despre Joe. Ați spus că clientul nu a vrut să dea tuturor acces la date. Strict vorbind, dacă o persoană are rezultatul Explain Analyze, atunci el poate arunca o privire asupra datelor.

Este ca asta. De exemplu, putem scrie: „SELECT FROM WHERE email = to that”. Adică nu vom vedea datele în sine, dar putem vedea câteva semne indirecte. Acest lucru trebuie înțeles. Dar, pe de altă parte, totul este acolo. Avem un audit de jurnal, avem controlul altor colegi care văd și ce fac dezvoltatorii. Și dacă cineva încearcă să facă acest lucru, atunci serviciul de securitate va veni la ei și va lucra la această problemă.

Bună ziua Multumesc pentru raport! Am o scurtă întrebare. Dacă compania nu folosește Slack, există vreo legătură cu acesta acum sau este posibil ca dezvoltatorii să implementeze instanțe pentru a conecta o aplicație de testare la bazele de date?

Acum există o legătură către Slack, adică nu există un alt mesager, dar chiar vreau să ofer suport și pentru alți mesageri. Ce poti face? Puteți implementa DB Lab fără Joe, mergeți cu ajutorul API-ului REST sau cu ajutorul platformei noastre și creați clone și conectați-vă cu PSQL. Dar acest lucru se poate face dacă ești gata să le oferi dezvoltatorilor tăi acces la date, deoarece nu va mai exista niciun ecran.

Nu am nevoie de acest strat, dar am nevoie de o astfel de oportunitate.

Atunci da, se poate.

Sursa: www.habr.com