DBA bot Joe. Anatoly Stansler (Postgres.ai)

Come fa uno sviluppatore di back-end a capire che una query SQL funzionerà bene su un "prod"? Nelle aziende grandi o in rapida crescita, non tutti hanno accesso al "prodotto". E con l'accesso, non tutte le richieste possono essere controllate in modo indolore e la creazione di una copia del database spesso richiede ore. Per risolvere questi problemi, abbiamo creato un DBA artificiale: Joe. È già stato implementato con successo in diverse aziende e aiuta più di una dozzina di sviluppatori.

Video:

Ciao a tutti! Mi chiamo Anatoly Stansler. Lavoro per un'azienda postgres.ai. Ci impegniamo ad accelerare il processo di sviluppo eliminando i ritardi associati al lavoro di Postgres da parte di sviluppatori, DBA e QA.

Abbiamo ottimi clienti e oggi parte del reportage sarà dedicata ai casi che abbiamo incontrato lavorando con loro. Parlerò di come li abbiamo aiutati a risolvere problemi piuttosto seri.

Quando sviluppiamo ed eseguiamo complesse migrazioni ad alto carico, ci poniamo la domanda: "Questa migrazione decollerà?". Usiamo la revisione, usiamo la conoscenza di colleghi più esperti, esperti DBA. E possono dire se volerà o no.

Ma forse sarebbe meglio se potessimo testarlo noi stessi su copie a grandezza naturale. E oggi parleremo solo di quali sono gli approcci ai test ora e di come possono essere fatti meglio e con quali strumenti. Parleremo anche dei pro e dei contro di tali approcci e di cosa possiamo correggere qui.

Chi ha mai fatto indici direttamente su prod o apportato modifiche? Un bel po' di. E per chi questo ha portato alla perdita di dati o a tempi di inattività? Allora conosci questo dolore. Grazie a Dio ci sono i backup.

Il primo approccio è testare in prod. Oppure, quando uno sviluppatore siede su una macchina locale, ha dati di test, c'è una sorta di selezione limitata. E ci lanciamo per pungolare e otteniamo questa situazione.

Fa male, è costoso. Probabilmente è meglio non farlo.

E qual è il modo migliore per farlo?

Prendiamo la messa in scena e selezioniamo una parte della produzione lì. O nella migliore delle ipotesi, prendiamo un vero prod, tutti i dati. E dopo averlo sviluppato localmente, verificheremo anche la messa in scena.

Questo ci consentirà di rimuovere alcuni degli errori, ad es. impedire loro di essere su prod.

Quali sono i problemi?

• Il problema è che condividiamo questa messa in scena con i colleghi. E molto spesso capita di apportare una sorta di modifica, bam - e non ci sono dati, il lavoro è andato in malora. Lo staging era multi-terabyte. E devi aspettare molto tempo prima che si alzi di nuovo. E decidiamo di finalizzarlo domani. Ecco fatto, abbiamo uno sviluppo.
• E, naturalmente, abbiamo molti colleghi che lavorano lì, molti team. E deve essere fatto manualmente. E questo è scomodo.

E vale la pena dire che abbiamo un solo tentativo, uno scatto, se vogliamo apportare alcune modifiche al database, toccare i dati, modificare la struttura. E se qualcosa è andato storto, se si è verificato un errore nella migrazione, non eseguiremo rapidamente il rollback.

Questo è migliore dell'approccio precedente, ma c'è ancora un'alta probabilità che qualche tipo di errore andrà in produzione.

Cosa ci impedisce di dare a ogni sviluppatore un banco di prova, una copia a grandezza naturale? Penso che sia chiaro cosa si frappone.

Chi ha un database più grande di un terabyte? Più della metà della stanza.

Ed è chiaro che mantenere le macchine per ogni sviluppatore, quando c'è una produzione così ampia, è molto costoso e inoltre richiede molto tempo.

Abbiamo clienti che si sono resi conto che è molto importante testare tutte le modifiche su copie a grandezza naturale, ma il loro database è inferiore a un terabyte e non ci sono risorse per mantenere un banco di prova per ogni sviluppatore. Pertanto, devono scaricare i dump localmente sulla propria macchina ed eseguire il test in questo modo. Ci vuole molto tempo.

Anche se lo fai all'interno dell'infrastruttura, scaricare un terabyte di dati all'ora è già molto buono. Ma usano dump logici, scaricano localmente dal cloud. Per loro, la velocità è di circa 200 gigabyte all'ora. E ci vuole ancora tempo per voltarsi dal dump logico, arrotolare gli indici, ecc.

Ma usano questo approccio perché consente loro di mantenere affidabile il prodotto.

Cosa possiamo fare qui? Rendiamo i banchi di prova economici e diamo a ogni sviluppatore il proprio banco di prova.

E questo è possibile.

E in questo approccio, quando creiamo cloni sottili per ogni sviluppatore, possiamo condividerli su una macchina. Ad esempio, se si dispone di un database da 10 TB e si desidera assegnarlo a 10 sviluppatori, non è necessario disporre di XNUMX database da XNUMX TB. Hai solo bisogno di una macchina per creare copie isolate sottili per ogni sviluppatore che utilizza una macchina. Ti dirò come funziona un po 'più tardi.

Esempio reale:

• DB - 4,5 terabyte.

• Possiamo ottenere copie indipendenti in 30 secondi.

Non devi aspettare un banco di prova e dipendere da quanto è grande. Puoi ottenerlo in pochi secondi. Si tratterà di ambienti completamente isolati, ma che condividono dati tra loro.

Questo è fantastico. Qui stiamo parlando di magia e di un universo parallelo.

Nel nostro caso, funziona utilizzando il sistema OpenZFS.

OpenZFS è un file system copy-on-write che supporta istantanee e cloni pronti all'uso. È affidabile e scalabile. È molto facile da gestire. Può letteralmente essere schierato in due squadre.

Ci sono altre opzioni:

• lvm,

• Archiviazione (ad esempio, Pure Storage).

Il Database Lab di cui sto parlando è modulare. Può essere implementato utilizzando queste opzioni. Ma per ora ci siamo concentrati su OpenZFS, perché ci sono stati problemi specifici con LVM.

Come funziona? Invece di sovrascrivere i dati ogni volta che li modifichiamo, li salviamo semplicemente contrassegnando che questi nuovi dati provengono da un nuovo punto nel tempo, una nuova istantanea.

E in futuro, quando vogliamo eseguire il rollback o vogliamo creare un nuovo clone da una versione precedente, diciamo semplicemente: "OK, dacci questi blocchi di dati contrassegnati in questo modo".

E questo utente lavorerà con un tale set di dati. Li cambierà gradualmente, creerà le sue istantanee.

E ramificheremo. Ogni sviluppatore nel nostro caso avrà l'opportunità di avere il proprio clone che modifica e i dati condivisi saranno condivisi tra tutti.

Per implementare un tale sistema a casa, è necessario risolvere due problemi:

• Il primo è la fonte dei dati, da dove li prenderai. È possibile configurare la replica con la produzione. Puoi già utilizzare i backup che hai configurato, spero. WAL-E, WAL-G o Barman. E anche se utilizzi una sorta di soluzione cloud come RDS o Cloud SQL, puoi utilizzare i dump logici. Ma ti consigliamo comunque di utilizzare i backup, perché con questo approccio manterrai anche la struttura fisica dei file, che ti permetterà di essere ancora più vicino alle metriche che vedresti in produzione per cogliere quei problemi che esistono.

• Il secondo è dove vuoi ospitare il Database Lab. Potrebbe essere Cloud, potrebbe essere On-premise. È importante dire qui che ZFS supporta la compressione dei dati. E lo fa abbastanza bene.

Immagina che per ciascuno di questi cloni, a seconda delle operazioni che facciamo con la base, crescerà una sorta di sviluppatore. Per questo, anche dev avrà bisogno di spazio. Ma a causa del fatto che abbiamo preso una base di 4,5 terabyte, ZFS lo comprimerà a 3,5 terabyte. Questo può variare a seconda delle impostazioni. E abbiamo ancora spazio per dev.

Tale sistema può essere utilizzato per diversi casi.

• Questi sono sviluppatori, DBA per la convalida delle query, per l'ottimizzazione.

• Questo può essere utilizzato nei test QA per testare una particolare migrazione prima di implementarla in prod. E possiamo anche creare ambienti speciali per il QA con dati reali, dove possono testare nuove funzionalità. E ci vorranno secondi invece di aspettare ore, e forse giorni in alcuni altri casi in cui non vengono utilizzate copie sottili.

• E un altro caso. Se l'azienda non dispone di un sistema di analisi, possiamo isolare un clone sottile della base di prodotti e assegnarlo a query lunghe o indici speciali che possono essere utilizzati nell'analisi.

Con questo approccio:

1. Bassa probabilità di errori sul "prod", perché abbiamo testato tutte le modifiche su dati a grandezza naturale.

2. Abbiamo una cultura del test, perché ora non devi aspettare ore per il tuo stand.

3. E non c'è barriera, nessuna attesa tra i test. Puoi effettivamente andare a controllare. E sarà meglio così mentre acceleriamo lo sviluppo.

• Ci sarà meno refactoring. Meno bug finiranno in prod. Li rifattorizzeremo meno in seguito.

• Possiamo invertire i cambiamenti irreversibili. Questo non è l'approccio standard.

1. Questo è vantaggioso perché condividiamo le risorse dei banchi di prova.

Già buono, ma cos'altro potrebbe essere accelerato?

Grazie a un tale sistema, possiamo ridurre notevolmente la soglia per accedere a tali test.

Ora c'è un circolo vizioso, quando uno sviluppatore, per avere accesso a dati reali a grandezza naturale, deve diventare un esperto. Deve fidarsi di tale accesso.

Ma come crescere se non c'è. Ma cosa succede se hai a disposizione solo un set molto piccolo di dati di test? Allora non avrai nessuna vera esperienza.

Come uscire da questo cerchio? Come prima interfaccia, comoda per sviluppatori di qualsiasi livello, abbiamo scelto il bot Slack. Ma può essere qualsiasi altra interfaccia.

Cosa ti permette di fare? Puoi prendere una query specifica e inviarla a un canale speciale per il database. Distribuiremo automaticamente un thin clone in pochi secondi. Eseguiamo questa richiesta. Raccogliamo metriche e raccomandazioni. Mostriamo una visualizzazione. E poi questo clone rimarrà in modo che questa query possa essere in qualche modo ottimizzata, aggiungere indici, ecc.

E anche Slack ci offre opportunità di collaborazione fuori dagli schemi. Poiché questo è solo un canale, puoi iniziare a discutere di questa richiesta proprio lì nel thread per tale richiesta, eseguire il ping dei tuoi colleghi, DBA che si trovano all'interno dell'azienda.

Ma ci sono, ovviamente, problemi. Poiché questo è il mondo reale e stiamo utilizzando un server che ospita molti cloni contemporaneamente, dobbiamo comprimere la quantità di memoria e la potenza della CPU disponibile per i cloni.

Ma affinché questi test siano plausibili, è necessario in qualche modo risolvere questo problema.

È chiaro che il punto importante sono gli stessi dati. Ma ce l'abbiamo già. E vogliamo ottenere la stessa configurazione. E possiamo dare una configurazione così quasi identica.

Sarebbe bello avere lo stesso hardware della produzione, ma potrebbe essere diverso.

Ricordiamo come funziona Postgres con la memoria. Abbiamo due cache. Uno dal file system e uno nativo Postgres, ovvero Shared Buffer Cache.

È importante notare che la cache del buffer condiviso viene allocata all'avvio di Postgres, a seconda della dimensione specificata nella configurazione.

E la seconda cache utilizza tutto lo spazio disponibile.

E quando realizziamo diversi cloni su una macchina, si scopre che riempiamo gradualmente la memoria. E in senso positivo, la cache del buffer condiviso è il 25% della quantità totale di memoria disponibile sulla macchina.

E si scopre che se non modifichiamo questo parametro, saremo in grado di eseguire solo 4 istanze su una macchina, ad es. 4 di tutti questi cloni sottili. E questo, ovviamente, è un male, perché vogliamo averne molti di più.

Ma d'altra parte, Buffer Cache viene utilizzato per eseguire query per indici, ovvero il piano dipende da quanto sono grandi le nostre cache. E se prendiamo questo parametro e lo riduciamo, i nostri piani possono cambiare molto.

Ad esempio, se abbiamo una cache di grandi dimensioni su prod, Postgres preferirà utilizzare un indice. E se no, allora ci sarà SeqScan. E che senso avrebbe se i nostri piani non coincidessero?

Ma qui arriviamo alla conclusione che in realtà il piano in Postgres non dipende dalla dimensione specifica specificata nel Buffer condiviso nel piano, dipende da Effective_cache_size.

Effective_cache_size è la quantità stimata di cache a nostra disposizione, ovvero la somma di Buffer Cache e cache del file system. Questo è impostato dal file config. E questa memoria non è assegnata.

E a causa di questo parametro, possiamo in qualche modo ingannare Postgres, dicendo che in realtà abbiamo molti dati disponibili, anche se non li abbiamo. E così, i piani coincideranno completamente con la produzione.

Ma questo può influenzare i tempi. E ottimizziamo le query in base alla tempistica, ma è importante che la tempistica dipenda da molti fattori:

• Dipende dal carico che è attualmente su prod.

• Dipende dalle caratteristiche della macchina stessa.

E questo è un parametro indiretto, ma in realtà possiamo ottimizzare esattamente in base alla quantità di dati che questa query leggerà per ottenere il risultato.

E se vuoi che i tempi siano vicini a ciò che vedremo in prod, allora dobbiamo prendere l'hardware più simile e, possibilmente, anche di più in modo che tutti i cloni si adattino. Ma questo è un compromesso, cioè otterrai gli stessi piani, vedrai quanti dati leggerà una particolare query e sarai in grado di concludere se questa query è buona (o migrazione) o cattiva, deve ancora essere ottimizzata .

Diamo un'occhiata a come Joe è specificamente ottimizzato.

Prendiamo una richiesta da un sistema reale. In questo caso, il database è di 1 terabyte. E vogliamo contare il numero di nuovi post con più di 10 Mi piace.

Stiamo scrivendo un messaggio al canale, è stato distribuito un clone per noi. E vedremo che tale richiesta verrà completata in 2,5 minuti. Questa è la prima cosa che notiamo.

B Joe ti mostrerà consigli automatici basati sul piano e sulle metriche.

Vedremo che la query elabora troppi dati per ottenere un numero relativamente piccolo di righe. Ed è necessario un qualche tipo di indice specializzato, poiché abbiamo notato che ci sono troppe righe filtrate nella query.

Diamo un'occhiata più da vicino a quello che è successo. In effetti, vediamo di aver letto quasi un gigabyte e mezzo di dati dalla cache dei file o addirittura dal disco. E questo non va bene, perché abbiamo solo 142 righe.

E, a quanto pare, abbiamo una scansione dell'indice qui e avremmo dovuto risolverla rapidamente, ma poiché abbiamo filtrato troppe righe (abbiamo dovuto contarle), la richiesta ha funzionato lentamente.

E questo è accaduto nel piano a causa del fatto che le condizioni nella query e le condizioni nell'indice parzialmente non corrispondono.

Proviamo a rendere l'indice più preciso e vediamo come cambia l'esecuzione della query dopo.

La creazione dell'indice ha richiesto molto tempo, ma ora controlliamo la query e vediamo che il tempo invece di 2,5 minuti è di soli 156 millisecondi, il che è abbastanza buono. E leggiamo solo 6 megabyte di dati.

E ora usiamo solo la scansione dell'indice.

Un'altra storia importante è che vogliamo presentare il piano in un modo più comprensibile. Abbiamo implementato la visualizzazione utilizzando Flame Graphs.

Questa è una richiesta diversa, più intensa. E costruiamo Flame Graphs secondo due parametri: questa è la quantità di dati che un particolare nodo ha contato nel piano e la tempistica, cioè il tempo di esecuzione del nodo.

Qui possiamo confrontare nodi specifici tra loro. E sarà chiaro quale di loro richiede più o meno, cosa che di solito è difficile da fare con altri metodi di rendering.

Certo, tutti conoscono learn.depesz.com. Una buona caratteristica di questa visualizzazione è che salviamo il piano di testo e inseriamo anche alcuni parametri di base in una tabella in modo da poterli ordinare.

E gli sviluppatori che non hanno ancora approfondito questo argomento usano anche describe.depesz.com, perché è più facile per loro capire quali metriche sono importanti e quali no.

C'è un nuovo approccio alla visualizzazione: questo è describe.dalibo.com. Fanno una visualizzazione ad albero, ma è molto difficile confrontare i nodi tra loro. Qui puoi capire bene la struttura, tuttavia, se c'è una grande richiesta, allora dovrai scorrere avanti e indietro, ma anche un'opzione.

Коллаборация

E, come ho detto, Slack ci offre l'opportunità di collaborare. Ad esempio, se ci imbattiamo in una query complessa che non è chiara su come ottimizzare, possiamo chiarire questo problema con i nostri colleghi in un thread in Slack.

Ci sembra che sia importante testare su dati a grandezza naturale. Per fare ciò, abbiamo creato lo strumento Update Database Lab, disponibile in open source. Puoi usare anche il bot di Joe. Puoi prenderlo subito e implementarlo a casa tua. Tutte le guide sono disponibili lì.

È anche importante notare che la soluzione in sé non è rivoluzionaria, perché c'è Delphix, ma è una soluzione aziendale. È completamente chiuso, è molto costoso. Siamo specificamente specializzati in Postgres. Questi sono tutti prodotti open source. Unisciti a noi!

Qui è dove finisco. Grazie!

domande

Ciao! Grazie per la segnalazione! Molto interessante, soprattutto per me, perché ho risolto lo stesso problema qualche tempo fa. E quindi ho una serie di domande. Spero di prenderne almeno una parte.

Mi chiedo come calcoli il posto per questo ambiente? La tecnologia significa che in determinate circostanze, i tuoi cloni possono raggiungere le dimensioni massime. In parole povere, se si dispone di un database da dieci terabyte e 10 cloni, è facile simulare una situazione in cui ogni clone pesa 10 dati univoci. Come calcoli questo luogo, cioè quel delta di cui hai parlato, in cui vivranno questi cloni?

Buona domanda. È importante tenere traccia di cloni specifici qui. E se un clone ha un cambiamento troppo grande, inizia a crescere, quindi possiamo prima emettere un avviso all'utente su questo, o fermare immediatamente questo clone in modo da non avere una situazione di errore.

Sì, ho una domanda annidata. Cioè, come garantite il ciclo di vita di questi moduli? Abbiamo questo problema e tutta una storia a parte. Come succede?

C'è qualche ttl per ogni clone. Fondamentalmente, abbiamo un ttl fisso.

Cosa, se non un segreto?

1 ora, ad es. inattivo - 1 ora. Se non viene utilizzato, lo battiamo. Ma non c'è nessuna sorpresa qui, dal momento che possiamo aumentare il clone in pochi secondi. E se ne hai bisogno di nuovo, per favore.

Mi interessa anche la scelta delle tecnologie, perché, ad esempio, utilizziamo diversi metodi in parallelo per un motivo o per l'altro. Perché ZFS? Perché non hai usato LVM? Hai detto che c'erano problemi con LVM. Quali erano i problemi? A mio parere, l'opzione più ottimale è con l'archiviazione, in termini di prestazioni.

Qual è il problema principale con ZFS? Il fatto che devi eseguire sullo stesso host, ovvero tutte le istanze vivranno all'interno dello stesso sistema operativo. E in caso di stoccaggio, puoi collegare diverse apparecchiature. E il collo di bottiglia sono solo quei blocchi che si trovano nel sistema di archiviazione. E la questione della scelta delle tecnologie è interessante. Perché non LVM?

Nello specifico, possiamo discutere di LVM al meetup. Informazioni sull'archiviazione: è solo costoso. Possiamo implementare il sistema ZFS ovunque. Puoi distribuirlo sulla tua macchina. Puoi semplicemente scaricare il repository e distribuirlo. ZFS è installato quasi ovunque se parliamo di Linux. Cioè, otteniamo una soluzione molto flessibile. E fuori dagli schemi, ZFS dà molto. Puoi caricare tutti i dati che desideri, collegare un gran numero di dischi, ci sono istantanee. E, come ho detto, è facile da amministrare. Cioè, sembra molto piacevole da usare. È messo alla prova, ha molti anni. Ha una comunità molto grande che sta crescendo. ZFS è una soluzione molto affidabile.

Nikolai Samokhvalov: Posso commentare ulteriormente? Mi chiamo Nikolay, lavoriamo insieme ad Anatoly. Sono d'accordo che l'archiviazione è ottima. E alcuni dei nostri clienti hanno Pure Storage ecc.

Anatoly ha correttamente notato che ci concentriamo sulla modularità. E in futuro, puoi implementare un'interfaccia: scatta un'istantanea, crea un clone, distruggi il clone. È tutto facile. E l'archiviazione è interessante, se lo è.

Ma ZFS è disponibile per tutti. DelPhix è già abbastanza, hanno 300 clienti. Di questi, Fortune 100 ha 50 clienti, ad es. sono rivolti alla NASA, ecc. È ora che tutti ottengano questa tecnologia. Ed è per questo che abbiamo un Core open source. Abbiamo una parte dell'interfaccia che non è open source. Questa è la piattaforma che mostreremo. Ma vogliamo che sia accessibile a tutti. Vogliamo fare una rivoluzione in modo che tutti i tester smettano di indovinare sui laptop. Dobbiamo scrivere SELECT e vedere subito che è lento. Smetti di aspettare che il DBA te lo dica. Ecco l'obiettivo principale. E penso che arriveremo tutti a questo. E facciamo questa cosa per tutti. Quindi ZFS, perché sarà disponibile ovunque. Grazie alla comunità per la risoluzione dei problemi e per avere una licenza open source, ecc.*

Saluti! Grazie per la segnalazione! Mi chiamo Massimo. Abbiamo affrontato gli stessi problemi. Hanno deciso da soli. Come condividi le risorse tra questi cloni? Ogni clone può fare le sue cose in qualsiasi momento: uno testa una cosa, un altro un'altra, qualcuno crea un indice, qualcuno ha un lavoro pesante. E se puoi ancora dividere per CPU, quindi per IO, come dividi? Questa è la prima domanda.

E la seconda domanda riguarda la diversità delle tribune. Diciamo che ho ZFS qui e va tutto bene, ma il client su prod non ha ZFS, ma ext4, per esempio. Come in questo caso?

Le domande sono molto buone. Ho accennato un po' a questo problema con il fatto che condividiamo le risorse. E la soluzione è questa. Immagina di eseguire dei test sulla messa in scena. Puoi anche avere una situazione del genere nello stesso momento in cui qualcuno dà un carico, qualcun altro. E di conseguenza, vedi metriche incomprensibili. Anche lo stesso problema può essere con prod. Quando vuoi controllare una richiesta e vedere che c'è qualche problema con essa, funziona lentamente, quindi in realtà il problema non era nella richiesta, ma nel fatto che c'è una sorta di carico parallelo.

E quindi, è importante qui concentrarsi su quale sarà il piano, quali passi faremo nel piano e quanti dati raccoglieremo per questo. Il fatto che i nostri dischi, ad esempio, saranno caricati con qualcosa, influirà in modo specifico sui tempi. Ma possiamo stimare quanto è caricata questa richiesta in base alla quantità di dati. Non è così importante che allo stesso tempo ci sarà una sorta di esecuzione.

Ho due domande. Questa è roba molto interessante. Ci sono stati casi in cui i dati di produzione sono critici, come i numeri delle carte di credito? C'è già qualcosa di pronto o è un'attività separata? E la seconda domanda: esiste qualcosa del genere per MySQL?

A proposito dei dati. Faremo offuscamento fino a quando non lo faremo. Ma se distribuisci esattamente Joe, se non dai accesso agli sviluppatori, non c'è accesso ai dati. Perché? Perché Joe non mostra i dati. Mostra solo metriche, piani e basta. Questo è stato fatto apposta, perché questo è uno dei requisiti del nostro cliente. Volevano essere in grado di ottimizzare senza dare accesso a tutti.

A proposito di MySQL. Questo sistema può essere utilizzato per tutto ciò che memorizza lo stato su disco. E poiché stiamo facendo Postgres, ora stiamo facendo prima tutta l'automazione per Postgres. Vogliamo automatizzare il recupero dei dati da un backup. Stiamo configurando Postgres correttamente. Sappiamo come far combaciare i piani, ecc.

Ma poiché il sistema è estensibile, può essere utilizzato anche per MySQL. E ci sono esempi del genere. Yandex ha una cosa simile, ma non la pubblicano da nessuna parte. Lo usano all'interno di Yandex.Metrica. E c'è solo una storia su MySQL. Ma le tecnologie sono le stesse, ZFS.

Grazie per la segnalazione! Ho anche un paio di domande. Hai detto che la clonazione può essere utilizzata per l'analisi, ad esempio per creare indici aggiuntivi lì. Puoi dirci qualcosa in più su come funziona?

E farò subito la seconda domanda sulla somiglianza delle tribune, la somiglianza dei piani. Il piano dipende anche dalle statistiche raccolte da Postgres. Come risolvi questo problema?

Secondo l'analisi, non ci sono casi specifici, perché non l'abbiamo ancora utilizzato, ma esiste una tale opportunità. Se parliamo di indici, immagina che una query stia inseguendo una tabella con centinaia di milioni di record e una colonna che di solito non è indicizzata in prod. E vogliamo calcolare alcuni dati lì. Se questa richiesta viene inviata a prod, allora c'è la possibilità che sia semplice su prod, perché la richiesta verrà elaborata lì per un minuto.

Ok, facciamo un clone sottile che non è terribile da fermare per qualche minuto. E per rendere più comoda la lettura dell'analisi, aggiungeremo indici per quelle colonne in cui siamo interessati ai dati.

L'indice verrà creato ogni volta?

Puoi fare in modo che tocchiamo i dati, creiamo istantanee, quindi ripristineremo da questa istantanea e guideremo nuove richieste. Cioè, puoi farlo in modo da poter allevare nuovi cloni con indici già apposti.

Per quanto riguarda la domanda sulle statistiche, se ripristiniamo da un backup, se eseguiamo la replica, le nostre statistiche saranno esattamente le stesse. Poiché abbiamo l'intera struttura fisica dei dati, ovvero porteremo i dati così come sono anche con tutte le metriche statistiche.

Ecco un altro problema. Se utilizzi una soluzione cloud, lì sono disponibili solo dump logici, perché Google, Amazon non ti consentono di eseguire una copia fisica. Ci sarà un problema.

Grazie per la segnalazione. C'erano due buone domande qui su MySQL e la condivisione delle risorse. Ma, in realtà, tutto si riduce al fatto che questo non è un argomento di DBMS specifico, ma del file system nel suo insieme. E, di conseguenza, anche i problemi di condivisione delle risorse dovrebbero essere risolti da lì, non alla fine che è Postgres, ma nel file system, nel server, per esempio.

La mia domanda è un po' diversa. È più vicino al database a più livelli, dove sono presenti diversi livelli. Ad esempio, impostiamo un aggiornamento dell'immagine da dieci terabyte, lo stiamo replicando. E utilizziamo specificamente questa soluzione per i database. La replica è in corso, i dati sono in fase di aggiornamento. Ci sono 100 dipendenti che lavorano in parallelo, che lanciano costantemente questi diversi scatti. Cosa fare? Come assicurarsi che non ci siano conflitti, che ne abbiano avviato uno, quindi il file system è cambiato e queste immagini sono andate tutte?

Non andranno perché è così che funziona ZFS. Possiamo tenere separatamente in un thread le modifiche al file system dovute alla replica. E mantieni i cloni che gli sviluppatori utilizzano nelle versioni precedenti dei dati. E funziona per noi, tutto è in ordine con questo.

Si scopre che l'aggiornamento avverrà come livello aggiuntivo e tutte le nuove immagini andranno già, in base a questo livello, giusto?

Da livelli precedenti che provenivano da repliche precedenti.

I livelli precedenti cadranno, ma faranno riferimento al vecchio livello e prenderanno nuove immagini dall'ultimo livello ricevuto nell'aggiornamento?

In generale si.

Quindi di conseguenza avremo fino a un fico di strati. E nel tempo dovranno essere compressi?

Sì, è tutto corretto. C'è qualche finestra. Conserviamo istantanee settimanali. Dipende da che risorsa hai. Se hai la possibilità di archiviare molti dati, puoi archiviare istantanee per molto tempo. Non se ne andranno da soli. Non ci sarà alcun danneggiamento dei dati. Se le istantanee sono obsolete, come ci sembra, ad es. dipende dalla politica dell'azienda, allora possiamo semplicemente cancellarle e liberare spazio.

Ciao, grazie per la segnalazione! Domanda su Joe. Hai detto che il cliente non voleva dare a tutti l'accesso ai dati. A rigor di termini, se una persona ha il risultato di Explain Analyze, può sbirciare i dati.

È come questo. Ad esempio, possiamo scrivere: "SELECT FROM WHERE email = to that". Cioè, non vedremo i dati stessi, ma possiamo vedere alcuni segni indiretti. Questo deve essere compreso. Ma d'altra parte, è tutto lì. Abbiamo un controllo del registro, abbiamo il controllo di altri colleghi che vedono anche cosa stanno facendo gli sviluppatori. E se qualcuno cerca di farlo, il servizio di sicurezza verrà da loro e lavorerà su questo problema.

Buon pomeriggio Grazie per la segnalazione! Ho una breve domanda. Se l'azienda non utilizza Slack, c'è qualche legame con esso ora o è possibile per gli sviluppatori distribuire istanze per connettere un'applicazione di test ai database?

Ora c'è un collegamento a Slack, cioè non c'è nessun altro messenger, ma voglio davvero supportare anche altri messenger. Cosa sai fare? Puoi distribuire DB Lab senza Joe, andare con l'aiuto dell'API REST o con l'aiuto della nostra piattaforma e creare cloni e connetterti con PSQL. Ma questo può essere fatto se sei pronto a dare ai tuoi sviluppatori l'accesso ai dati, perché non ci sarà più alcuna schermata.

Non ho bisogno di questo livello, ma ho bisogno di una tale opportunità.

Allora sì, si può fare.

Fonte: habr.com