Come fa un sviluppatore backend a capire se una query SQL funzionerà bene in produzione? In aziende grandi o in rapida crescita, l'accesso alla produzione non è garantito per tutti. E anche con accesso, non tutti i query possono essere testati senza problemi, e creare una copia del database può richiedere ore. Per affrontare questi problemi, abbiamo creato un DBA artificiale — Joe. È già stato implementato con successo in diverse aziende e assiste più di una dozzina di sviluppatori.
Video:
Ciao a tutti! Mi chiamo Anatolij Stansler. Lavoro per l'azienda . Ci occupiamo di velocizzare il processo di sviluppo, eliminando le pause legate all'uso di Postgres per sviluppatori, DBA e QA.
Abbiamo clienti fantastici e oggi parte della mia presentazione sarà dedicata ai casi che abbiamo affrontato lavorando con loro. Vi parlerò di come li abbiamo aiutati a risolvere problemi piuttosto gravi.
Quando conduciamo sviluppo e facciamo migrazioni complesse e pesanti, ci poniamo la domanda: "Questa migrazione avrà successo?" Usiamo revisioni, attingiamo alla conoscenza di colleghi più esperti e DBA esperti. E possono dirci se avrà successo o meno.
Ma, forse sarebbe meglio se potessimo testarlo noi stessi su copie a grandezza naturale. E oggi discuteremo proprio dei metodi attuali di test e di come possiamo farlo al meglio e quali strumenti utilizzare. Parleremo anche dei vantaggi e svantaggi di questi approcci e di cosa possiamo migliorare.
Chi ha mai creato indici o apportato modifiche direttamente in produzione? In molti. E a chi è capitato di perdere dati o subire interruzioni? Allora conoscete questo dolore. Per fortuna, ci sono i backup.
Il primo approccio è il test in produzione. Oppure, quando uno sviluppatore lavora dalla sua macchina locale, ha dati di test e c'è un campione limitato. E distribuiamo in produzione, ottenendo una situazione del genere.
Questo è doloroso, questo è costoso. Probabilmente, sarebbe meglio non farlo.
Qual è il modo migliore per procedere?
Prendiamo un ambiente di staging e riserviamo lì una parte della produzione. O, meglio ancora, prendiamo una vera produzione, tutti i dati. E dopo aver sviluppato localmente, verificheremo ulteriormente anche su staging.
Questo ci permetterà di eliminare alcuni errori, ovvero di non farli arrivare in produzione.
Quali problemi ci sono?
- Il problema è che condividiamo questo staging con i colleghi. E molto spesso succede che fai una modifica, bam – e non ci sono dati, tutto inutile. Lo staging era di diversi terabyte. E bisogna aspettare molto perché si riparta. E decidiamo di rinviare il lavoro a domani. Insomma, lo sviluppo è bloccato.
- E, naturalmente, ci sono molti colleghi che lavorano lì, molte squadre. E bisogna coordinarsi manualmente. E questo è poco pratico.
E va detto che abbiamo solo un tentativo, un colpo, se vogliamo apportare delle modifiche al database, toccare i dati, cambiare la struttura. E se qualcosa va storto, se c'è un errore nella migrazione, non possiamo tornare indietro rapidamente.
È meglio rispetto al precedente approccio, ma c'è comunque un'alta probabilità che qualche errore vada in produzione.
Cosa ci impedisce di dare a ogni sviluppatore un ambiente di test, una copia a grandezza naturale? Penso sia chiaro cosa ci frena.
Chi ha un database più grande di un terabyte? Più della metà della sala.
È chiaro che mantenere macchine per ogni sviluppatore, quando si ha un grande ambiente di produzione, è molto costoso e richiede tempo.
Abbiamo clienti che hanno capito quanto sia importante testare tutte le modifiche su copie a grandezza naturale, ma hanno database che sono sotto il terabyte e non hanno risorse per tenere un ambiente di test per ogni sviluppatore. Quindi devono scaricare i dump localmente sul proprio computer e fare i test in questo modo. Questo richiede molto tempo.
Anche se lo fai all'interno dell'infrastruttura, scaricare un terabyte di dati in un'ora è già molto buono. Ma loro usano dump logici, scaricano localmente dal cloud. Per loro la velocità è di circa 200 gigabyte all'ora. E ci vuole tempo anche per estrarre dai dump logici, applicare gli indici, ecc.
Ma utilizzano questo approccio perché consente di mantenere il prod affidabile.
Cosa possiamo fare qui? Facciamo in modo che gli ambienti di test siano economici e diamo a ogni sviluppatore il proprio ambiente di test.
E questo è possibile.
E in questo approccio, quando facciamo clone leggeri per ogni sviluppatore, possiamo condividerlo su una sola macchina. Ad esempio, se hai un database di quattro terabyte e vuoi darlo a 10 sviluppatori, non hai bisogno di avere 10 volte il database di quattro terabyte. Ti basta una macchina per fare copie isolate e leggere per ogni sviluppatore, utilizzando una sola macchina. Come funziona te lo racconterò più tardi.
Esempio reale:
DB – 4,5 terabyte.
Possiamo ottenere copie indipendenti in 30 secondi.
Non devi aspettare un ambiente di test e dipendere dalla sua dimensione. Puoi ottenerlo in pochi secondi. Saranno ambienti completamente isolati, ma che condividono i dati tra di loro.
È fantastico. Qui parliamo di magia e universi paralleli.
Nel nostro caso funziona grazie al sistema OpenZFS.
OpenZFS è un file system copy-on-write che supporta nativamente snapshot e cloni. È affidabile e scalabile. È molto facile da gestire. Può essere implementato letteralmente con due comandi.
Ci sono altre opzioni:
LVM,
Storage di rete (ad esempio, Pure Storage).
Database Lab, di cui parlo, è modulare. Può essere implementato utilizzando tali opzioni. Ma al momento ci siamo concentrati su OpenZFS, perché abbiamo avuto problemi specifici con LVM.
Come funziona? Invece di riscrivere i dati ogni volta che li modifichiamo, li salviamo semplicemente contrassegnando i nuovi dati come appartenenti a un nuovo momento temporale, a un nuovo snapshot.
E in seguito, quando vogliamo tornare indietro o vogliamo creare un nuovo clone da una versione precedente, diciamo semplicemente: 'Ok, dammi questi blocchi di dati contrassegnati in questo modo'.
E questo utente lavorerà con questo insieme di dati. Li modificherà progressivamente, creando i propri snapshot.
E ci sarà una ramificazione. Ogni sviluppatore, nel nostro caso, avrà la possibilità di avere il proprio clone che modifica, mentre i dati condivisi saranno condivisi tra tutti.
Per implementare un sistema del genere, è necessario risolvere due problemi:
La prima è la fonte di dati da cui li prenderete. Potete configurare la replica con la produzione. Potete utilizzare già i backup che spero abbiate configurato. WAL-E, WAL-G o Barman. E anche, se state utilizzando qualche soluzione Cloud, come RDS o Cloud SQL, potete utilizzare dump logici. Ma vi consigliamo comunque di utilizzare i backup, perché con questo approccio conserverete anche la struttura fisica dei file, il che vi permetterà di essere ancora più vicini a quelle metriche che vedreste in produzione, per identificare i problemi che ci sono.
La seconda è il luogo dove desiderate ospitare Database Lab. Può essere Cloud o On-premise. Qui è importante notare che ZFS supporta la compressione dei dati. E lo fa abbastanza bene.
Immaginate che ognuno di questi cloni, a seconda delle operazioni che eseguiamo con il database, avrà una certa crescita dev. Per questo dev sarà necessario uno spazio. Ma dato che abbiamo preso un database di 4,5 terabyte, ZFS lo comprimerà a 3,5 terabyte. A seconda delle impostazioni, questo può variare. E ci rimarrà anche spazio per il dev.
Un sistema del genere può essere utilizzato per diversi casi.
È per sviluppatori, DBA per controllare le query, per l'ottimizzazione.
Può essere utilizzato nel QA-testing per verificare una migrazione specifica prima di implementarla in prod. E possiamo anche creare ambienti speciali per il QA con dati reali, dove possono testare nuove funzionalità. E questo richiederà secondi invece di aspettare ore, o forse giorni in altri casi dove non sono utilizzate copie sottili.
E un altro caso separato. Se nell'azienda non è configurato un sistema di analytics, possiamo creare un clone sottile del database di produzione e destinarlo a query lunghe o a indici speciali che possono essere utilizzati nell'analisi.
Con questo approccio:
Bassa probabilità di errori in produzione, perché abbiamo testato tutte le modifiche su dati a piena dimensione.
Sviluppiamo una cultura del testing, poiché ora non è necessario aspettare ore per il proprio stand.
E non ci sono barriere, né attese tra i test. Puoi davvero andare e verificare. E così sarà meglio, poiché accelereremo lo sviluppo.
Ci sarà meno refactoring. Meno bug arriverà in prod. Li rifattorizzeremo meno in seguito.
Possiamo gestire modifiche irreversibili. Questo non è previsto nei metodi standard.
- È vantaggioso, perché condividiamo le risorse degli ambienti di test.
Già bene, ma cosa altro potremmo velocizzare?
Grazie a questo sistema possiamo abbattere significativamente la soglia di ingresso a questo tipo di test.
Attualmente c'è un circolo vizioso, dove lo sviluppatore, per accedere a dati reali e completi, deve diventare un esperto. Deve essergli concessa tale fiducia.
Ma come può crescere se non ce l'ha? E se hai accesso solo a un piccolo set di dati di test? In questo caso, non si può acquisire esperienza reale.
Come uscire da questo circolo? Come primo interfaccia, comoda per sviluppatori di qualsiasi livello, abbiamo scelto un bot di Slack. Ma potrebbe essere qualsiasi altra interfaccia.
Cosa consente di fare? Si può prendere una richiesta specifica e inviarla in un canale speciale per il database. Espanderemo automaticamente un clone snello in pochi secondi. Eseguiamo questa richiesta. Raccoglieremo metriche e raccomandazioni. Mostreremo la visualizzazione. E poi questo clone rimarrà per ottimizzare in qualche modo questa richiesta, aggiungere indici, ecc.
E Slack ci offre anche opportunità di collaborazione. Poiché è semplicemente un canale, si può iniziare a discutere questa richiesta direttamente lì nel thread, pingando i colleghi, i DBA all'interno dell'azienda.
Tuttavia, ci sono ovviamente anche problemi. Poiché siamo nel mondo reale e usiamo un server che ospita più cloni, dobbiamo comprimere la memoria e la potenza di elaborazione disponibili per i cloni.
Ma per rendere questi test credibili, è necessario risolvere questo problema in qualche modo.
È chiaro che un elemento fondamentale sono i dati identici. Ma questo lo abbiamo già. E vogliamo ottenere una configurazione uniforme. Possiamo fornire una configurazione praticamente identica.
Sarebbe fantastico avere hardware uguale a quello di produzione, ma potrebbe differire.
Ricordiamo come Postgres gestisce la memoria. Abbiamo due cache. Una dalla file system e una propria di Postgres, cioè il Shared Buffer Cache.
È importante notare che il Shared Buffer Cache viene allocato all'avvio di Postgres in base alla dimensione che si imposta nella configurazione.
Il secondo cache utilizza tutto lo spazio disponibile.
E quando facciamo più clone su una macchina, finiamo per riempire gradualmente la memoria. Idealmente, il Shared Buffer Cache dovrebbe essere il 25% dell'intera memoria disponibile sulla macchina.
E risulta che se non cambiamo questo parametro, possiamo avviare solo 4 istanze su una macchina, cioè solo 4 di questi sottili cloni. E questo è problematico, perché vogliamo averne molti di più.
Ma dall'altro lato, il Buffer Cache è utilizzato per eseguire le query, per gli indici, cioè il piano dipende dalla dimensione dei nostri cache. E se semplicemente prendiamo questo parametro e lo riduciamo, i nostri piani potrebbero cambiare drasticamente.
Ad esempio, se su prod abbiamo un grande cache, Postgres preferirà utilizzare l'indice. Ma se no, allora si farà un SeqScan. E che senso avrebbe se i nostri piani non corrispondessero?
Ma qui arriviamo alla conclusione che in realtà il piano in Postgres non dipende dalla dimensione specificata nel Shared Buffer, bensì da effective_cache_size.
L’effective_cache_size è la dimensione presunta del cache che abbiamo a disposizione, cioè la somma del Buffer Cache e del cache del filesystem. Questo viene impostato nella configurazione. E questa memoria non viene allocata.
E grazie a questo parametro possiamo ingannare Postgres, diciamo che in realtà abbiamo accesso a molti dati, anche se non li abbiamo. In questo modo, i piani corrisponderanno perfettamente alla produzione.
Ma questo potrebbe influire sui tempi. Ottimizziamo le query basandoci sui tempi, ma è importante sapere che il timing dipende da molti fattori:
Dipende dal carico attuale su prod.
Dipende dalle caratteristiche della macchina stessa.
E questo è un parametro indiretto, ma in realtà possiamo ottimizzare in base alla quantità di dati che questa query leggerà per ottenere il risultato.
E se vogliamo che il timing sia vicino a quello che vedremo in prod, dobbiamo prendere hardware il più simile possibile e, forse, anche di più, affinché tutti i cloni possano entrare. Ma questo è un compromesso, cioè avrai gli stessi piani, vedrai quante informazioni legge una specifica query e potrai concludere: questa query è buona (o la migrazione) o cattiva, deve ancora essere ottimizzata.
Analizziamo come avviene concretamente l'ottimizzazione con Joe.
Prendiamo una query da un sistema reale. In questo caso, il database è di 1 terabyte. E vogliamo contare il numero di post freschi che hanno ricevuto più di 10 like.
Scriviamo un messaggio nel canale, si è attivato per noi un clone. E vedremo che tale query si eseguirà in 2,5 minuti. Questo è il primo aspetto che noteremo.
Joe mostrerà raccomandazioni automatiche, basate sul piano e sulle metriche.
Vedremo che la query elabora troppi dati per ottenere un numero relativamente ristretto di righe. È necessario qualche indice specializzato, poiché abbiamo notato che ci sono troppe righe filtrate nella query.
Esaminiamo più a fondo cosa è successo. Infatti, vediamo di aver letto quasi un gigabyte e mezzo di dati dalla cache dei file o addirittura dal disco. E questo non è buono, dato che abbiamo estratto solo 142 righe.
E, a prima vista, sembrerebbe che abbiamo una scansione dell'indice e dovrebbe eseguirsi rapidamente, ma poiché abbiamo filtrato troppe righe (abbiamo dovuto contarle), la query ha impiegato tempo.
E questo è accaduto nel piano a causa della parziale incongruenza tra le condizioni nella query e quelle nell'indice.
Proviamo a rendere l'indice più preciso e vediamo come cambia l'esecuzione della query dopo questo.
La creazione dell'indice ha richiesto abbastanza tempo, ma ora controlliamo la query e vediamo che il tempo è passato da 2,5 minuti a soli 156 millisecondi, il che è piuttosto buono. E stiamo leggendo solo 6 megabyte di dati.
E ora stiamo utilizzando una scansione dell'indice solo.
Un'altra questione importante è che vogliamo presentare il piano in un modo più comprensibile. Abbiamo implementato la visualizzazione tramite Flame Graphs.
Questa è un'altra query, più complessa. E costruiamo Flame Graphs in base a due parametri: la quantità di dati che un nodo specifico nel piano ha letto e il timing, cioè il tempo di esecuzione del nodo.
Qui possiamo confrontare specificamente i nodi tra loro. E sarà chiaro quale di essi occupi più o meno spazio, il che è solitamente difficile da fare con altri metodi di visualizzazione.
Certo, tutti conoscono explain.depesz.com. Una buona caratteristica di questa visualizzazione è che conserviamo il piano testuale e inoltre estraiamo alcuni parametri principali in una tabella, in modo da poter essere ordinati.
E anche gli sviluppatori che non hanno ancora approfondito questo tema utilizzano explain.depesz.com, perché è più facile per loro capire quali metriche sono importanti e quali no.
C'è un nuovo approccio alla visualizzazione: explain.dalibo.com. Fanno una visualizzazione ad albero, ma qui è molto difficile confrontare i nodi tra loro. Qui si può ben comprendere la struttura, ma se c'è una richiesta molto grande, sarà necessario scorrere avanti e indietro, ma anche questo è un'opzione.
Collaborazione
E, come ho già detto, Slack ci offre la possibilità di collaborare. Ad esempio, se ci imbattiamo in una richiesta complessa che non sappiamo come ottimizzare, possiamo chiarire questa domanda con i nostri colleghi nel thread di Slack.
Riteniamo sia importante testare su dati a piena scala. Per questo abbiamo creato lo strumento Update Database Lab, disponibile in open source. Puoi utilizzare anche il bot Joe. Puoi prenderlo adesso e integrarlo nel tuo lavoro. Tutti i guide sono disponibili lì.
È anche importante notare che la soluzione in sé non è rivoluzionaria, perché esiste Delphix, ma è una soluzione enterprise. È completamente chiusa e costa molto. Noi ci specializziamo in Postgres. Questi sono tutti prodotti open source. Unisciti a noi!
Con questo concludo. Grazie!
Domande
Buongiorno! Grazie per la presentazione! È molto interessante, soprattutto per me, perché ho risolto più o meno lo stesso problema un po' di tempo fa. Pertanto, ho una serie di domande. Spero di poterne fare almeno una parte.
È interessante vedere come calcolate lo spazio per questo ambiente? La tecnologia implica che, in determinate circostanze, i vostri cloni possano crescere fino alla dimensione massima. In parole povere, se avete un database di dieci terabyte e 10 cloni, è facile simulare una situazione in cui ogni clone pesa 10 dati unici. Come calcolate quello spazio, cioè quella delta di cui avete parlato, in cui vivranno questi cloni?
Bella domanda. Qui è importante monitorare i cloni specifici. E se ci sono cambiamenti troppo grandi in un clone, inizia a crescere, possiamo innanzitutto avvisare l'utente su questo, oppure fermare immediatamente quel clone per evitare di trovarci in una situazione di fail.
Sì, ho una domanda secondaria. Cioè, come assicurate il ciclo di vita di questi moduli? Per noi è un problema e una storia a parte. Come avviene?
Ogni clone ha un certo ttl. Fondamentalmente, abbiamo un ttl fisso.
Qual è, se non è un segreto?
1 ora, cioè idle – 1 ora. Se non viene utilizzato, lo eliminiamo. Ma qui non c'è nulla di sorprendente, poiché possiamo creare un clone in pochi secondi. E se ne avremo nuovamente bisogno, beh, siamo a disposizione.
Sono anche interessato alla scelta delle tecnologie, perché noi, ad esempio, utilizziamo diversi metodi per vari motivi. Perché proprio ZFS? Perché non avete usato LVM? Hai accennato a problemi con LVM. Quali problemi c'erano? A mio avviso, la soluzione ottimale è quella con lo storage, dal punto di vista delle prestazioni.
Qual è il principale problema con ZFS? Il fatto che devi eseguirlo su un singolo host, cioè tutti gli instances vivranno nell'ambito di un unico sistema operativo. E nel caso dello storage, puoi collegare diverse attrezzature. E il collo di bottiglia sono solo i blocchi che si trovano nello storage. È interessante la questione della scelta delle tecnologie. Perché non LVM?
Possiamo discutere specificamente di LVM al meetup. Riguardo allo storage – è semplicemente costoso. Possiamo implementare il sistema ZFS ovunque. Puoi installarlo sul tuo computer. Puoi semplicemente scaricare il repository e installarlo. ZFS può essere installato praticamente ovunque, se parliamo di Linux. Cioè, otteniamo una soluzione molto flessibile. E ZFS stesso offre già molto di per sé. Puoi caricare un'infinità di dati, collegare un gran numero di dischi, ci sono snapshot. E, come già detto, è facile da amministrare. Cioè, sembra molto piacevole da usare. È collaudato, ha molti anni. Ha una comunità molto ampia che cresce. ZFS è una soluzione molto affidabile.
Nikolaj Samokhvalov: Posso aggiungere un commento? Mi chiamo Nikolaj, lavori insieme ad Anatolij. Concordo sul fatto che lo storage sia fantastico. E alcuni dei nostri clienti hanno Pure Storage e così via.
Anatolij ha giustamente sottolineato che puntiamo sulla modularità. E in futuro possiamo implementare un'unica interfaccia: crea un snapshot, crea un clone, distruggi un clone. Tutto questo è facile. E se hai uno storage classico, è fantastico, se ce l'hai.
Ma ZFS è accessibile a tutti. È ora di basta con Delphix, hanno 300 clienti. Di questi, 50 sono nella fortune 100, cioè puntano su NASA e così via. È tempo che tutti abbiano accesso a questa tecnologia. E per questo abbiamo un Core open source. Abbiamo una parte dell'interfaccia che non è open source. Questa è la piattaforma che presenteremo. Ma vogliamo che sia accessibile a chiunque. Vogliamo fare una rivoluzione, affinché tutti i tester smettano di indovinare sui portatili. Dobbiamo scrivere SELECT e vedere immediatamente che è lento. Basta aspettare che il DBA lo racconti. Questa è la nostra principale obiettivo. E credo che ci arriveremo tutti. E questo strumento lo realizziamo affinché tutti lo possano avere. Ecco perché ZFS, perché sarà disponibile ovunque. Grazie alla community per la risoluzione dei problemi e per la licenza open source e così via.
Salve! Grazie per la relazione! Mi chiamo Maksim. Abbiamo affrontato problemi simili. Li abbiamo risolti internamente. Come dividete le risorse tra questi cloni? Ogni clone può essere occupato con qualcosa di diverso in ogni momento: uno testando qualcosa, un altro qualcos'altro, uno sta costruendo un indice, un altro sta eseguendo un lavoro pesante. E se per la CPU si può ancora dividere, come fate con l'IO? Questa è la prima domanda.
E la seconda domanda riguarda la differenza degli ambienti. Supponiamo che qui abbia ZFS e tutto vada bene, ma il cliente in produzione non ha ZFS, ma ext4, per esempio. Come vi comportate in questo caso?
Domande molto buone. Ho appena accennato a questo problema riguardante la divisione delle risorse. E la soluzione è la seguente. Immaginate di testare su staging. Potete avere una situazione simile, dove qualcuno genera un certo carico e qualcun altro un altro. E alla fine vedete metriche poco chiare. Anche problemi simili possono sorgere in produzione. Quando volete controllare una certa query e notate che ha qualche problema, come ad esempio che è lenta, in realtà il problema non era nella query, ma nel fatto che c'era un carico parallelo.
E quindi qui è importante concentrarsi su quale sarà il piano, quali passaggi seguiremo e quanti dati raccoglieremo. Il fatto che i nostri dischi, ad esempio, saranno caricati da qualcosa influenzerà specificamente il timing. Ma possiamo stimare la pesantezza di questa richiesta in base al numero di dati. Non è così importante che ci sia anche qualche esecuzione simultanea.
Ho due domande. Questa è davvero una cosa interessante. Ci sono stati casi in cui i dati in produzione sono critici, ad esempio i numeri delle carte di credito? C'è già qualcosa di pronto o è un compito separato? E la seconda domanda: c'è qualcosa del genere per MySQL?
Riguardo ai dati. Faremo obfuscazione, anche se non lo stiamo facendo ancora. Ma se stai implementando precisamente Joe, se non dai accesso agli sviluppatori, allora non ci sarà accesso ai dati. Perché? Perché Joe non mostra i dati. Mostra solo metriche, piani e così via. È stato fatto specificamente in questo modo poiché è uno dei requisiti del nostro cliente. Volevano avere la possibilità di ottimizzare, ma senza dare accesso indiscriminato a tutti.
Riguardo a MySQL. Questo sistema può essere utilizzato per qualsiasi cosa che memorizzi lo stato su disco. E poiché ci occupiamo di Postgres, stiamo innanzitutto automatizzando completamente per Postgres. Vogliamo automatizzare l'ottenimento dei dati dal backup. Configuriamo correttamente Postgres. Sappiamo come fare affinché i piani coincidano, e così via.
Ma poiché il sistema è espandibile, potrà essere utilizzato anche per MySQL. E ci sono esempi di questo. C'è una cosa simile in Yandex, ma non lo pubblicano da nessuna parte. Lo utilizzano all'interno di Yandex.Metrica. E proprio lì c'è la questione di MySQL. Ma le tecnologie sono le medesime, ZFS.
Grazie per la relazione! Ho anche un paio di domande. Hai menzionato che il cloning può essere utilizzato per analisi, ad esempio, per costruire indici aggiuntivi. Puoi spiegare un po' più in dettaglio come funziona?
E subito farò la seconda domanda riguardo all'omogeneità degli stand, all'uniformità dei piani. Il piano dipende anche dalle statistiche raccolte da Postgres. Come risolvete questo problema?
Non ci sono analisi di casi specifici, perché non li abbiamo ancora utilizzati in quel modo, ma c'è questa possibilità. Se parliamo di indici, immaginate una query che gira su una tabella con centinaia di milioni di record e su una colonna che di solito non è indicizzata in produzione. E noi vogliamo calcolare alcuni dati. Se eseguiamo questa query in produzione, c'è la possibilità che ci sia un arresto, perché la query richiederà un minuto per essere elaborata.
Ok, facciamo una copia leggera che non ci spaventa fermare per qualche minuto. E per rendere più agevole il calcolo dell'analisi, aggiungiamo indici sulle colonne di nostro interesse.
L'indice verrà creato ogni volta?
Possiamo fare in modo di toccare i dati, creare snapshot, e poi da questi snapshot recuperare e lanciare nuove query. Cioè, possiamo fare in modo di creare nuovi cloni con gli indici già impostati.
Per quanto riguarda la questione delle statistiche, se recuperiamo da un backup, se facciamo replicazione, le statistiche saranno esattamente le stesse. Perché abbiamo completamente la struttura fisica dei dati, cioè porteremo anche i dati come sono con tutte le metriche statistiche.
Qui c'è un altro problema. Se usate una soluzione cloud, solo i dump logici sono disponibili, perché Google e Amazon non consentono di prendere una copia fisica. Ci sarà un problema simile qui.
Grazie per la presentazione. Sono emerse due buone domande su MySQL e sulla separazione delle risorse. Ma, in sostanza, tutto si riduce al fatto che si tratta di un tema non specifico dei database, bensì dell'intero sistema di file. E di conseguenza, le domande sulla separazione delle risorse devono essere risolte da lì, non alla fine, come se fosse Postgres, ma nel sistema di file, server, nell'istanza.
La mia domanda è un po' diversa. È più vicina alla multi-layer architecture del database, dove ci sono più layer. Ad esempio, abbiamo impostato l'aggiornamento di un'immagine di dieci terabyte, c'è replicazione in corso. E stiamo specificamente usando questa soluzione per database. La replicazione avviene, ci sono aggiornamenti dei dati. Qui lavorano contemporaneamente 100 dipendenti, che eseguono costantemente questi diversi snapshot. Cosa fare? Come fare per evitare conflitti, quando ne avviano uno e poi il sistema dei file cambia, e tutti questi snapshot diventano obsoleti?
Non andranno, perché così funziona ZFS. Possiamo tenere separatamente in un unico flusso le modifiche al file system che arrivano grazie alla replica. E sulle versioni più vecchie dei dati tenere i cloni che gli sviluppatori utilizzano. E questo per noi funziona, tutto va bene.
Quindi, l'aggiornamento avverrà come un ulteriore strato, e tutte le nuove istantanee verranno già da questo strato, giusto?
Dai livelli precedenti, che sono stati dalle repliche precedenti.
I livelli precedenti si perderanno, ma faranno riferimento al vecchio livello, mentre le nuove immagini prenderanno dall'ultimo livello ottenuto durante l'aggiornamento?
In generale, sì.
Quindi, come conseguenza, avremo un sacco di livelli. E col tempo dovranno essere compressi?
Sì, esatto. C'è un certo intervallo. Salviamo istantanee settimanali. Questo dipende da quali sono le tue risorse. Se hai la possibilità di conservare molti dati, puoi mantenere le istantanee per molto tempo. Non si eliminano automaticamente. Non ci sarà alcuna corruzione dei dati. Se le istantanee sono obsolete, come ci sembra, cioè dipende dalla politica aziendale, possiamo semplicemente eliminarle e liberare spazio.
Buongiorno, grazie per la relazione! Riguardo alla domanda di Joe. Hai detto che il cliente non voleva dare accesso a tutti ai dati. A rigor di termini, se una persona ha il risultato dell'Explain Analyze, può visualizzare i dati.
Esatto. Ad esempio, possiamo scrivere: «SELECT FROM WHERE email = quello lì». Cioè, non vedremo i dati stessi, ma possiamo osservare alcuni segni indiretti. Questo va capito. Ma dall'altro lato, tutto ciò è visibile. Abbiamo l'audit dei log, abbiamo il controllo di altri colleghi che vedono anche cosa fanno gli sviluppatori. E se qualcuno cerca di farlo, il servizio di sicurezza interverrà e si occuperà di questo problema.
Buon pomeriggio! Grazie per la relazione! Ho una domanda breve. Se in azienda non si utilizza Slack, c'è qualche collegamento attuale o è possibile per gli sviluppatori lanciare istanze per collegare un'app di prova ai database?
Attualmente c'è un'integrazione con Slack, cioè non ci sono altri messenger, ma ci piacerebbe molto implementare il supporto per altri messenger. Cosa potete fare? Potete installare DB Lab da soli senza Joe, utilizzare il REST API o la nostra piattaforma per creare cloni e collegarvi con PSQL. Ma questa è una possibilità, se siete pronti a dare accesso ai dati ai vostri sviluppatori, poiché non ci sarà più nessuno schermo.
Non ho bisogno di questo strato, ma di questa funzionalità.
Allora – sì, si può fare.
Fonte: habr.com
