DBA bot Joe. Anatoly Stansler (Postgres.ai)

Cumu un sviluppatore di backend capisce chì una dumanda SQL hà da travaglià bè nantu à un "prod"? In l'imprese grandi o in rapida crescita, micca tutti ùn anu accessu à u "pruduttu". È cù l'accessu, micca tutte e dumande ponu esse verificate senza dolore, è a creazione di una copia di a basa di dati spessu dura ore. Per risolve questi prublemi, avemu creatu un DBA artificiale - Joe. Hè digià statu implementatu cù successu in parechje cumpagnie è aiuta più di una decina di sviluppatori.

Video:

Salut à tutti ! Mi chjamu Anatoly Stansler. U travagliu per una cumpagnia postgres.ai. Semu impegnati à accelerà u prucessu di sviluppu eliminendu i ritardi assuciati à u travagliu di Postgres da i sviluppatori, DBA è QA.

Avemu grandi clienti è oghje una parte di u rapportu serà dedicata à i casi chì avemu scontru mentre travagliendu cun elli. Parlaraghju di cumu avemu aiutatu à risolve prublemi abbastanza serii.

Quandu sviluppemu è facemu migrazioni cumplessi d'alta carica, ci dumandemu a quistione: "Sta migrazione s'incollarà?". Usemu rivista, usemu a cunniscenza di i culleghi più sperimentati, esperti DBA. È ponu dì s'ellu volarà o micca.

Ma forse saria megliu se puderemu pruvà noi stessi nantu à e copie full size. È oghje avemu da parlà solu di ciò chì l'approcciu di a prova sò avà è cumu si pò esse fattu megliu è cù quali strumenti. Parleremu ancu di i prufessi è i contra di tali approcci, è ciò chì pudemu riparà quì.

Quale hà mai fattu indici direttamente nantu à prod o hà fattu cambiamenti? Un pocu di. E per quale hà purtatu questu à u fattu chì i dati sò stati persi o ci sò stati tempi di inattività? Allora sapete stu dulore. Grazie à Diu ci sò backups.

U primu approcciu hè a prova in prod. O, quandu un sviluppatore si trova nantu à una macchina lucale, hà dati di prova, ci hè una sorta di selezzione limitata. È stendemu per pruducia, è avemu sta situazione.

Fa male, hè caru. Probabilmente hè megliu micca.

E quale hè u megliu modu per fà?

Pigliemu a messa in scena è selezziunate una parte di pruduzzione quì. O à u megliu, andemu à piglià un veru prod, tutti i dati. È dopu chì l'avemu sviluppatu in u locu, cuntrolleremu in più per staging.

Questu ci permetterà di sguassà alcune di l'errori, vale à dì impediscenu di esse in prod.

Chì sò i prublemi ?

• U prublema hè chì spartemu sta messa in scena cù i culleghi. È assai spessu succèri chì fate un tipu di cambiamentu, bam - è ùn ci hè micca dati, u travagliu hè in u drain. Staging era multi-terabyte. È ci vole à aspittà assai tempu per ch'ellu risuscite di novu. È decidemu di finalizà dumane. Eccu, avemu un sviluppu.
• È, sicuru, avemu parechji culleghi chì travaglianu quì, parechje squadre. È deve esse fattu manualmente. È questu hè inconveniente.

È vale a pena dì chì avemu solu un tentativu, un colpu, se vulemu fà qualchi cambiamenti à a basa di dati, toccu i dati, cambià a struttura. È s'è qualcosa andò male, s'ellu ci era un errore in a migrazione, allora ùn avemu micca ritruvà rapidamente.

Questu hè megliu cà l'approcciu precedente, ma ci hè sempre una alta probabilità chì qualchì tipu d'errore andarà à a produzzione.

Chì ci impedisce di dà à ogni sviluppatore un bancu di prova, una copia in grandezza? Pensu chì hè chjaru ciò chì si mette in u modu.

Quale hà una basa di dati più grande di un terabyte? Più di a mità di a stanza.

È hè chjaru chì mantene e macchine per ogni sviluppatore, quandu ci hè una produzzione cusì grande, hè assai caru, è in più, ci vole assai tempu.

Avemu clienti chì anu capitu chì hè assai impurtante per pruvà tutti i cambiamenti nantu à e copie full-size, ma a so basa di dati hè menu di un terabyte, è ùn sò micca risorse per mantene un bancu di teste per ogni sviluppatore. Per quessa, anu da scaricà i dumps in u locu à a so macchina è pruvà in questu modu. Ci vole assai tempu.

Ancu s'è vo fate in l'infrastruttura, allora scaricà un terabyte di dati per ora hè digià assai bonu. Ma usanu dumps lògichi, scaricanu in u locu da u nuvulu. Per elli, a vitezza hè di circa 200 gigabytes per ora. È ci vole ancu tempu per vultà da u dump logicu, roll up l'indici, etc.

Ma utilizanu stu approcciu perchè li permette di mantene a pruduzzione affidabile.

Chì pudemu fà quì ? Facemu banchi di prova à prezzu è dà à ogni sviluppatore u so propiu bancu di prova.

È questu hè pussibule.

È in questu approcciu, quandu facemu cloni sottili per ogni sviluppatore, pudemu sparte nantu à una macchina. Per esempiu, sè vo avete una basa di dati 10TB è vulete dà à 10 sviluppatori, ùn avete micca bisognu di XNUMX basa di dati XNUMXTB. Avete bisognu di una sola macchina per fà copie sottili isolate per ogni sviluppatore utilizendu una macchina. Vi dicu cumu funziona un pocu dopu.

Esempiu veru:

• DB - 4,5 terabytes.

• Pudemu ottene copie indipendenti in 30 seconde.

Ùn avete micca aspittà per un stand di prova è dipende da quantu hè grande. Pudete ottene in seconde. Serà ambienti cumpletamente isolati, ma chì sparte dati trà elli.

Questu hè grande. Quì si parla di magia è di un universu parallelu.

In u nostru casu, questu travaglia cù u sistema OpenZFS.

OpenZFS hè un sistema di fugliale di copia in scrittura chì supporta snapshots è cloni fora di a scatula. Hè affidabile è scalabile. Hè assai faciule di gestisce. Pò esse literalmente implementatu in duie squadre.

Ci sò altre opzioni:

• lvm,

• Storage (per esempiu, Pure Storage).

U Laboratoriu di Database chì parlu hè modulare. Pò esse implementatu cù queste opzioni. Ma per avà, avemu focu annantu à OpenZFS, perchè ci sò stati prublemi cù LVM specificamente.

Cumu funziona? Invece di riscriviri i dati ogni volta chì cambiamu, l'avemu salvatu da solu marcatu chì sta nova dati hè da un novu puntu in u tempu, una nova snapshot.

È in u futuru, quandu vulemu rollback o vulemu fà un novu clone da una versione più vechja, dicemu solu: "OK, dà noi sti blocchi di dati chì sò marcati cusì".

È questu utilizatore hà da travaglià cù un tali set di dati. Li cambierà à pocu à pocu, fà e so propiu snapshots.

È avemu ramu. Ogni sviluppatore in u nostru casu avarà l'uppurtunità di avè u so propiu clone chì edità, è e dati chì sò spartuti seranu spartuti trà tutti.

Per implementà un tali sistema in casa, avete bisognu di risolve dui prublemi:

• U primu hè a surghjente di i dati, induve vi piglià da. Pudete stabilisce a replicazione cù a produzzione. Pudete digià aduprà i backups chì avete cunfiguratu, speru. WAL-E, WAL-G o Barman. E ancu s'è vo aduprate una sorta di suluzione Cloud cum'è RDS o Cloud SQL, pudete aduprà dumps lògichi. Ma avemu sempre cunsigliatu à aduprà copia di salvezza, perchè cù questu approcciu, ancu mantene a struttura fisica di i schedari, chì vi permetterà di esse ancu più vicinu à e metriche chì vi vede in a produzzione per catturà quelli prublemi chì esistenu.

• U sicondu hè induve vulete ospitu u Laboratoriu di Database. Puderia esse Cloud, puderia esse On-premise. Hè impurtante di dì quì chì ZFS sustene a compressione di dati. È si faci abbastanza bè.

Imagine chì per ogni tali clone, secondu l'operazioni chì facemu cù a basa, un tipu di dev crescerà. Per questu, dev hà ancu bisognu di spaziu. Ma per via di u fattu chì avemu pigliatu una basa di 4,5 terabytes, ZFS cumpressa à 3,5 terabytes. Questu pò varià sicondu i paràmetri. È avemu sempre spaziu per dev.

Un tali sistema pò esse usatu per diversi casi.

• Quessi sò sviluppatori, DBA per a validazione di query, per l'ottimisazione.

• Questu pò esse usatu in a prova di QA per pruvà una migrazione particulari prima di sparghjela per prod. È pudemu ancu suscitarà ambienti speciali per QA cù dati reali, induve ponu pruvà una nova funziunalità. È piglià seconde invece d'aspittà ore, è forsi ghjorni in certi altri casi induve e copie sottili ùn sò micca aduprate.

• È un altru casu. Se a cumpagnia ùn hà micca un sistema analiticu stallatu, allora pudemu isolà un clone magre di a basa di produttu è dà à dumande longu o indici speciali chì ponu esse usatu in analitiche.

Cù stu approcciu:

1. Prubabilità bassa d'errore nantu à u "prod", perchè avemu pruvatu tutti i cambiamenti nantu à e dati full-size.

2. Avemu una cultura di teste, perchè avà ùn avete micca aspittà per ore per u vostru propiu stand.

3. È ùn ci hè nè barriera, nè aspittà trà e teste. Pudete veramente andà à verificà. È serà megliu cusì cumu acceleremu u sviluppu.

• Ci sarà menu refactoring. Meno bug finiranu in prod. Li refactoreremu menu dopu.

• Pudemu annunzià cambiamenti irreversibili. Questu ùn hè micca l'approcciu standard.

1. Questu hè benefica perchè spartemu e risorse di i banchi di prova.

Dighjà bè, ma chì altru puderia esse acceleratu?

Grazie à un tali sistema, pudemu riduce assai u sogliu per entra in tali teste.

Avà ci hè un circhiu viziosu, quandu un sviluppatore, per avè accessu à e dati reali di grandezza, deve diventà un espertu. Hè da esse fiduciale cun tali accessu.

Ma cumu cresce si ùn ci hè micca. Ma chì s'è vo avete solu una piccula serie di dati di prova dispunibuli per voi? Allora ùn uttene micca una sperienza vera.

Cumu esce da stu cerculu ? Cum'è a prima interfaccia, cunvene per i sviluppatori di ogni livellu, avemu sceltu u bot Slack. Ma pò esse qualsiasi altra interfaccia.

Chì vi permette di fà ? Pudete piglià una dumanda specifica è mandà à un canale speciale per a basa di dati. Implementaremu automaticamente un clone sottile in seconde. Facemu sta dumanda. Raccogliamu metriche è cunsiglii. Mostramu una visualizazione. E allora stu clone resterà cusì chì sta dumanda pò esse in qualchì modu ottimizzata, aghjunghje indici, etc.

È ancu Slack ci dà opportunità di cullaburazione fora di a scatula. Siccomu questu hè solu un canale, pudete inizià a discussione di sta dumanda quì in u filu per una tale dumanda, ping i vostri culleghi, DBAs chì sò in a cumpagnia.

Ma ci sò, sicuru, prublemi. Perchè questu hè u mondu reale, è usemu un servitore chì ospita parechji cloni à una volta, avemu da cumpressà a quantità di memoria è a putenza CPU dispunibile per i cloni.

Ma per queste teste per esse plausibile, avete bisognu di risolve in qualchì modu stu prublema.

Hè chjaru chì u puntu impurtante hè a stessa data. Ma l'avemu digià. È vulemu ottene a listessa cunfigurazione. È pudemu dà un tali cunfigurazione quasi identica.

Saria bellu per avè u stessu hardware cum'è in a pruduzzione, ma pò esse diversu.

Ricurdemu cumu Postgres travaglia cù a memoria. Avemu dui cache. Unu da u sistema di schedari è un Postgres nativu, vale à dì Shared Buffer Cache.

Hè impurtante di nutà chì u Cache Buffer Shared hè attribuitu quandu Postgres principia, secondu a dimensione chì specificate in a cunfigurazione.

È a seconda cache usa tuttu u spaziu dispunibule.

È quandu facemu parechji cloni nantu à una macchina, risulta chì gradualmente riempia a memoria. È in una bona manera, Shared Buffer Cache hè 25% di a quantità totale di memoria chì hè dispunibule nantu à a macchina.

È si trova chì, se ùn cambiamu micca stu paràmetru, allora pudemu eseguisce solu 4 casi nantu à una macchina, vale à dì 4 di sti cloni sottili in totale. È questu, sicuru, hè male, perchè vulemu avè assai più di elli.

Ma d'altra banda, Buffer Cache hè utilizatu per eseguisce dumande per l'indici, vale à dì, u pianu dipende da quantu grande sò i nostri cache. E s'è no pigghiamu solu stu paràmetru è riduce, allura i nostri piani ponu cambià assai.

Per esempiu, se avemu un grande cache in prod, allora Postgres preferirà aduprà un indice. È se no, allora ci sarà SeqScan. È chì saria u puntu s'è i nostri piani ùn coincidenu micca ?

Ma quì ghjunghjemu à a cunclusione chì in fattu u pianu in Postgres ùn dipende micca da a dimensione specifica specificata in u Buffer Shared in u pianu, dipende da effective_cache_size.

Effective_cache_size hè a quantità stimata di cache chì hè dispunibule per noi, vale à dì a summa di Buffer Cache è cache di u sistema di file. Questu hè stabilitu da a cunfigurazione. È sta memoria ùn hè micca attribuita.

È per via di stu paràmetru, pudemu tipu di truccu Postgres, dicendu chì avemu veramente assai dati dispunibuli, ancu s'ellu ùn avemu micca sta dati. È cusì, i piani coincideranu cumpletamente cù a produzzione.

Ma questu pò influenzà u timing. È ottimisimu e dumande per timing, ma hè impurtante chì u timing dipende di parechji fatturi:

• Dipende da a carica chì hè attualmente in prod.

• Si dipende di e caratteristiche di a macchina stessa.

È questu hè un paràmetru indirettu, ma in fatti pudemu ottimisà esattamente da a quantità di dati chì sta dumanda leghje per ottene u risultatu.

E se vulete chì u timing sia vicinu à ciò chì vedemu in prod, allora avemu bisognu di piglià l'hardware più simili è, possibbilmente, ancu di più per chì tutti i cloni si adattanu. Ma questu hè un cumprumissu, vale à dì chì uttene i stessi piani, vi vede quantu dati una dumanda particulari leghje è puderà cuncludi s'ellu sta dumanda hè bona (o migrazione) o mala, hè sempre bisognu à esse ottimizzata. .

Fighjemu un ochju à cumu Joe hè specificamente ottimizzatu.

Pigliemu una dumanda da un sistema veru. In questu casu, a basa di dati hè 1 terabyte. È vulemu cuntà u numeru di posti freschi chì avianu più di 10 Mi piace.

Scrivemu un missaghju à u canali, un clone hè statu implementatu per noi. È videremu chì una tale dumanda serà cumpletata in 2,5 minuti. Questu hè a prima cosa chì avemu nutatu.

B Joe vi mostrarà cunsiglii automatichi basati nantu à u pianu è e metriche.

Videremu chì a query processa troppu dati per ottene un numeru relativamente chjucu di fila. È un tipu d'indici specializatu hè necessariu, postu chì avemu nutatu chì ci sò troppu fila filtrata in a dumanda.

Fighjemu un ochju più vicinu à ciò chì hè accadutu. Infatti, vedemu chì avemu lettu quasi un gigabyte è mezu di dati da u cache di u schedariu o ancu da u discu. È questu ùn hè micca bonu, perchè avemu solu 142 linee.

E, pare, avemu una scansione d'indici quì è duverebbe esse travagliatu rapidamente, ma postu chì avemu filtratu troppu linee (avemu avutu a cuntà), a dumanda hà travagliatu lentamente.

E questu hè accadutu in u pianu per u fattu chì e cundizioni in a dumanda è e cundizioni in l'indici parzialmente ùn currispondenu micca.

Pruvemu di fà l'indici più precisu è vede cumu l'esekzione di a dumanda cambia dopu.

A creazione di l'indici hà pigliatu assai tempu, ma avà cuntrollamu a quistione è vede chì u tempu invece di 2,5 minuti hè solu 156 millisecondi, chì hè abbastanza bè. È avemu leghje solu 6 megabytes di dati.

È avà usemu solu scansione di index.

Un'altra storia impurtante hè chì vulemu presentà u pianu in una manera più comprensibile. Avemu implementatu a visualizazione cù Flame Graphs.

Questa hè una dumanda sfarente, più intensa. E custruemu Flame Graphs secondu dui paràmetri: questu hè a quantità di dati chì un node particulari hà cuntatu in u pianu è u timing, vale à dì u tempu d'esekzione di u node.

Quì pudemu paragunà nodi specifichi cù l'altri. È serà chjaru quale di elli piglia più o menu, chì hè di solitu difficiuli di fà in altri metudi di rendering.

Di sicuru, ognunu sapi spiega.depesz.com. Una bona funzione di sta visualizazione hè chì salvemu u pianu di testu è mette ancu parechji paràmetri basi in una tavula per pudè sorte.

È i sviluppatori chì ùn anu micca ancu sfondate in questu tema utilizanu ancu explic.depesz.com, perchè hè più faciule per elli à capisce quale metrica sò impurtanti è quali ùn sò micca.

Ci hè un novu approcciu à a visualizazione - questu hè explica.dalibo.com. Facenu una visualizazione di l'arburu, ma hè assai difficiule di paragunà i nodi cù l'altri. Quì pudete capisce bè a struttura, però, s'ellu ci hè una grande dumanda, allora avete bisognu di scorri avanti è avanti, ma ancu una opzione.

cullaburazione

È, cum'è aghju dettu, Slack ci dà l'uppurtunità di cullaburazione. Per esempiu, s'ellu ci hè una quistione cumplessa chì ùn hè micca chjaru cumu ottimisimu, pudemu chjarificà stu prublema cù i nostri culleghi in un filu in Slack.

Ci pari chì hè impurtante di pruvà nantu à dati full-size. Per fà questu, avemu fattu l'uttellu Update Database Lab, chì hè dispunibule in open source. Pudete ancu aduprà u bot Joe. Pudete piglià avà è implementà à u vostru locu. Tutte e guide sò dispunibuli quì.

Hè impurtante ancu di nutà chì a suluzione stessu ùn hè micca rivoluzionariu, perchè ci hè Delphix, ma hè una suluzione di l'impresa. Hè cumplettamente chjusu, hè assai caru. Avemu specificamente specializatu in Postgres. Quessi sò tutti i prudutti open source. Unisciti à noi!

Questu hè induve finisci. Grazie!

I vostri dumanni

Bonghjornu! Grazie per u rapportu! Moltu interessante, soprattuttu per mè, perchè aghju risoltu circa u listessu prublema qualchì tempu fà. È cusì aghju una quantità di dumande. Spergu chì ne riceveraghju almenu una parte.

Mi dumandu cumu calculà u locu per questu ambiente? A tecnulugia significa chì in certi circustanzi, i vostri cloni ponu cresce à a dimensione massima. À pocu pressu, sè vo avete una basa di dati di 10 terabyte è 10 cloni, allora hè faciule simule una situazione induve ogni clone pesa XNUMX dati unichi. Cumu calculà stu locu, vale à dì quellu delta di quale avete parlatu, in quale camparanu sti cloni ?

Bona dumanda. Hè impurtante di seguità i cloni specifichi quì. È se un clone hà un cambiamentu troppu grande, cumencia à cresce, allora pudemu prima emette un avvisu à l'utilizatore nantu à questu, o ferma immediatamente stu clone per ùn avè micca una situazione di fallimentu.

Iè, aghju una quistione nidificata. Questu hè, cumu assicuratevi u ciclu di vita di questi moduli? Avemu stu prublema è una storia tutta separata. Cumu succede questu?

Ci hè qualchì ttl per ogni clone. In fondu, avemu un ttl fissu.

Chì, se micca un sicretu?

1 ora, vale à dì idle - 1 ora. S'ellu ùn hè micca usatu, allora l'avemu bang. Ma ùn ci hè micca sorpresa quì, postu chì pudemu elevà u clone in seconde. È s'ellu avete bisognu di novu, allora per piacè.

Sò ancu interessatu in l'scelta di tecnulugii, perchè, per esempiu, usamu parechji metudi in parallelu per una ragione o un altru. Perchè ZFS? Perchè ùn avete micca usatu LVM? Avete dettu chì ci sò stati prublemi cù LVM. Chì eranu i prublemi ? In u mo parè, l'opzione più ottima hè cù u almacenamiento, in quantu à u rendiment.

Chì ghjè u prublema principali cù ZFS? U fattu chì duvete eseguisce nantu à u stessu òspite, vale à dì chì tutte e istanze camparanu in u stessu OS. È in u casu di almacenamiento, pudete cunnette diverse equipaghji. È u collu di buttiglia hè solu quelli blocchi chì sò nantu à u sistema di almacenamiento. È a quistione di a scelta di tecnulugia hè interessante. Perchè micca LVM?

In particulare, pudemu discutiri di LVM in meetingup. Circa u almacenamentu - hè solu caru. Pudemu implementà u sistema ZFS in ogni locu. Pudete implementà nantu à a vostra macchina. Pudete simpricimenti scaricà u repository è implementà. ZFS hè stallatu quasi in ogni locu se parlemu di Linux. Questu hè, avemu una suluzione assai flexible. È ZFS stessu dà assai fora di a scatula. Pudete cullà quant'è dati chì vulete, cunnette un gran numaru di discu, ci sò snapshots. È, cum'è aghju dettu, hè faciule d'amministrari. Questu hè, pare assai piacevule à aduprà. Hè pruvatu, hà parechji anni. Hà una cumunità assai grande chì cresce. ZFS hè una suluzione assai affidabile.

Nikolai Samokhvalov: Possu cummentà più? Mi chjamu Nikolay, travagliammu inseme cù Anatoly. Sò d'accordu chì u almacenamentu hè grande. È alcuni di i nostri clienti anu Pure Storage etc.

Anatoly hà nutatu currettamente chì simu focu annantu à a modularità. È in u futuru, pudete implementà una interfaccia - pigliate una foto, fate un clone, distrugge u clone. Hè tuttu faciule. È l'almacenamiento hè frescu, s'ellu hè.

Ma ZFS hè dispunibule per tutti. DelPhix hè digià abbastanza, anu 300 clienti. Di questi, a fortuna 100 hà 50 clienti, vale à dì chì sò destinati à a NASA, etc. Hè u tempu per tutti per uttene sta tecnulugia. È hè per quessa chì avemu un core open source. Avemu una parte di l'interfaccia chì ùn hè micca open source. Questa hè a piattaforma chì mustraremu. Ma vulemu chì sia accessibile à tutti. Vulemu fà una rivoluzione per chì tutti i testatori cessanu di indovinà nantu à i laptops. Avemu da scrive SELECT è immediatamente vede chì hè lentu. Smetti di aspittà chì u DBA vi dilla. Eccu u scopu principale. E pensu chì tutti veneremu à questu. È facemu sta cosa per tutti. Dunque ZFS, perchè serà dispunibule in ogni locu. Grazie à a cumunità per risolve i prublemi è per avè una licenza open source, etc.*

Saluti ! Grazie per u rapportu! Mi chjamu Maxim. Avemu trattatu i stessi prublemi. Anu decisu per sè stessu. Cumu sparte e risorse trà questi cloni? Ogni clone pò fà u so propiu in ogni mumentu: unu prova una cosa, un altru altru, qualchissia custruisce un indice, qualchissia hà un travagliu pesante. È se pudete ancu divide per CPU, dopu per IO, cumu si divide? Questa hè a prima quistione.

È a seconda quistione hè nantu à a dissimilarità di i stands. Diciamu chì aghju ZFS quì è tuttu hè bellu, ma u cliente nantu à prod ùn hà micca ZFS, ma ext4, per esempiu. Cumu in questu casu?

E dumande sò assai boni. Aghju menzionatu stu prublema un pocu cù u fattu chì spartemu risorse. È a suluzione hè questu. Imaginate chì site teste nantu à a messa in scena. Pudete ancu avè una tale situazione à u stessu tempu chì qualchissia dà una carica, un altru. È in u risultatu, vede metriche incomprensibili. Ancu u listessu prublema pò esse cù prod. Quandu vulete cuntrollà una certa dumanda è vede chì ci hè qualchì prublema cù questu - travaglia lentamente, allora in fattu u prublema ùn era micca in a dumanda, ma in u fattu chì ci hè un tipu di carica parallela.

È per quessa, hè impurtante quì per fucalizza nantu à ciò chì u pianu serà, chì passi avemu da piglià in u pianu è quantu dati avemu da suscitarà per questu. U fattu chì i nostri dischi, per esempiu, seranu carricati cù qualcosa, affettarà specificamente u timing. Ma pudemu stimà quantu hè caricata sta dumanda da a quantità di dati. Ùn hè micca cusì impurtante chì à u stessu tempu ci sarà qualchì tipu d'esekzione.

Aghju duie dumande. Questa hè una roba assai fresca. Ci sò stati casi induve i dati di produzzione sò critichi, cum'è i numeri di carte di creditu? Ci hè digià qualcosa pronta o hè un compitu separatu? È a seconda quistione - ci hè qualcosa cusì per MySQL?

Circa i dati. Facemu l'obfuscazione finu à fà. Ma se implementate esattamente Joe, se ùn dà micca accessu à i sviluppatori, ùn ci hè micca accessu à e dati. Perchè? Perchè Joe ùn mostra micca dati. Mostra solu metriche, piani è basta. Questu hè statu fattu apposta, perchè questu hè unu di i bisogni di u nostru cliente. Vulìanu esse capace di ottimisà senza dà accessu à tutti.

À propositu di MySQL. Stu sistema pò esse usatu per tuttu ciò chì guarda u statu nantu à u discu. E postu chì facemu Postgres, facemu prima tutta l'automatizazione per Postgres. Vulemu automatizà ottene dati da una copia di salvezza. Avemu cunfigurà Postgres currettamente. Sapemu cumu fà i piani match, etc.

Ma postu chì u sistema hè estensibile, pò ancu esse usatu per MySQL. È ci sò tali esempii. Yandex hà una cosa simili, ma ùn a publicanu in ogni locu. L'utilizanu in Yandex.Metrica. È ci hè solu una storia nantu à MySQL. Ma e tecnulugia sò listessi, ZFS.

Grazie per u rapportu! Aghju ancu un paru di dumande. Avete citatu chì a clonazione pò esse usata per l'analitiche, per esempiu per custruisce indici supplementari. Pudete dì un pocu di più nantu à cumu funziona?

È aghju da dumandà subitu a seconda quistione nantu à a similitudine di i stands, a similarità di i piani. U pianu dipende ancu di e statistiche raccolte da Postgres. Cumu risolve stu prublema?

Sicondu l'analitiche, ùn ci sò micca casi specifichi, perchè ùn avemu micca usatu ancu, ma ci hè una tale opportunità. Se parlemu di indici, allora imagine chì una dumanda persegue una tavula cù centinaie di milioni di registri è una colonna chì ùn hè di solitu micca indiziata in prod. È vulemu calculà qualchi dati quì. Se sta dumanda hè mandata à prod, allora ci hè a pussibilità chì serà simplice nantu à prod, perchè a dumanda serà trattata quì per un minutu.

Ok, facemu un clone magre chì ùn hè micca terribili per piantà per uni pochi di minuti. È per fà più còmode di leghje l'analitiche, aghjunghje indici per quelli culonni in quale avemu interessatu in dati.

L'indici serà creatu ogni volta?

Pudete fà cusì chì avemu toccu i dati, fate snapshots, allora avemu da ricuperà da sta snapshot è guidà novi richieste. Questu hè, pudete fà cusì chì pudete suscitarà novi cloni cù indici digià affissi.

In quantu à a quistione di statistiche, se restaurà da una copia di salvezza, se facemu a replicazione, allora e nostre statistiche seranu esattamente u listessu. Perchè avemu tutta a struttura di dati fisichi, vale à dì, purteremu e dati cum'è cù tutte e statistiche metriche ancu.

Eccu un altru prublema. Sè vo aduprate una suluzione nuvola, allura solu dumps lògichi sò dispunibuli quì, perchè Google, Amazon ùn permettenu micca di piglià una copia fisica. Ci sarà un prublema.

Grazie per u rapportu. Ci era duie dumande bè quì nantu à MySQL è spartera di risorse. Ma, in fattu, tuttu vene à u fattu chì questu ùn hè micca un tema di DBMS specificu, ma di u sistema di fugliale in generale. È, per quessa, i prublemi di spartera di risorse anu da esse risolti ancu da quì, micca à a fine chì hè Postgres, ma in u sistema di schedari, in u servitore, per esempiu.

A mo dumanda hè un pocu sfarente. Hè più vicinu à a basa di dati multi-layered, induve ci sò parechji strati. Per esempiu, avemu stabilitu un aghjurnamentu di l'imaghjini di deci terabyte, avemu riplicatu. È avemu specificamente aduprà sta suluzione per basa di dati. A replicazione hè in corso, i dati sò aghjurnati. Ci sò 100 impiegati chì travaglianu in parallelu quì, chì lancianu in permanenza sti diversi colpi. Chì fà ? Cumu assicurà chì ùn ci hè micca un cunflittu, chì anu lanciatu unu, è dopu u sistema di schedari hà cambiatu, è sti ritratti sò tutti andati?

Ùn andaranu micca perchè hè cusì chì ZFS travaglia. Pudemu mantene separatamente in un filu i cambiamenti di u sistema di schedari chì venenu per a replicazione. È mantene i cloni chì i sviluppatori utilizanu in versioni più vechje di e dati. È travaglia per noi, tuttu hè in ordine cù questu.

Risulta chì l'aghjurnamentu serà fattu cum'è una strata supplementu, è tutte e foto novi andaranu digià, basatu annantu à questu stratu, nò?

Da strati precedenti chì eranu da riplicazioni precedenti.

I strati precedenti cascanu, ma si riferiranu à a vechja capa, è piglianu novi imagine da l'ultima capa chì hè stata ricevuta in l'aghjurnamentu?

In generale, sì.

Allora, in cunseguenza, averemu finu à un ficu di strati. È cù u tempu, anu da esse cumpressu?

Iè tuttu hè currettu. Ci hè una finestra. Tenemu snapshots settimanali. Dipende da quale risorse avete. Se avete a capacità di almacenà assai dati, pudete almacenà snapshots per un bellu pezzu. Ùn andaranu micca da soli. Ùn ci sarà micca corruzzione di dati. Sì i snapshots sò obsoleti, cum'è ci pare à noi, vale à dì dipende di a pulitica in a cumpagnia, allora pudemu solu sguassà è liberà u spaziu.

Hola, grazie per u rapportu! Quistione nantu à Joe. Avete dettu chì u cliente ùn vulia micca dà à tutti l'accessu à i dati. Strictly speaking, s'è una persona hà u risultatu di Spiega Analyse, allura pò peep i dati.

Hè cusì. Per esempiu, pudemu scrive: "SELECT FROM WHERE email = à quellu". Questu hè, ùn avemu micca vede i dati stessu, ma pudemu vede qualchi signali indiretti. Questu deve esse capitu. Ma da l'altra banda, ci hè tuttu. Avemu un auditu di log, avemu u cuntrollu di l'altri culleghi chì vedenu ancu ciò chì i sviluppatori facenu. È s'è qualcunu prova à fà questu, allora u serviziu di sicurità vene à elli è travaglià nantu à sta questione.

Bonghjornu Grazie per u rapportu! Aghju una breve dumanda. Se a cumpagnia ùn usa micca Slack, ci hè un ligame avà, o hè pussibule per i sviluppatori di implementà istanze per cunnette una applicazione di prova à e basa di dati?

Avà ci hè un ligame à Slack, vale à dì chì ùn ci hè micca altru messageru, ma vogliu veramente fà un supportu per altri messageri ancu. Chì pudete fà ? Pudete implementà DB Lab senza Joe, andate cù l'aiutu di l'API REST o cù l'aiutu di a nostra piattaforma è creà cloni è cunnette cù PSQL. Ma questu pò esse fattu s'è vo site prontu à dà i vostri sviluppatori accessu à i dati, perchè ùn ci sarà più schermu.

Ùn aghju micca bisognu di sta strata, ma aghju bisognu di una tale opportunità.

Allora sì, si pò fà.

Source: www.habr.com