DBA bot Joe. Anatoly Stansler (Postgres.ai)

Com entén un desenvolupador de fons que una consulta SQL funcionarà bé en un "prod"? A les empreses grans o de ràpid creixement, no tothom té accés al "producte". I amb l'accés, no totes les sol·licituds es poden comprovar sense dolor, i crear una còpia de la base de dades sovint porta hores. Per resoldre aquests problemes, vam crear un DBA artificial: Joe. Ja s'ha implementat amb èxit en diverses empreses i ajuda a més d'una dotzena de desenvolupadors.

Vídeo:

Hola a tots! Em dic Anatoly Stansler. Treballo per a una empresa postgres.ai. Ens comprometem a accelerar el procés de desenvolupament eliminant els retards associats al treball de Postgres dels desenvolupadors, DBA i QA.

Tenim grans clients i avui una part de l'informe es dedicarà als casos que hem conegut mentre treballem amb ells. Parlaré de com els hem ajudat a resoldre problemes força greus.

Quan estem desenvolupant i fent migracions complexes d'alta càrrega, ens fem la pregunta: "Aquesta migració s'enlairarà?". Utilitzem la revisió, fem servir el coneixement de col·legues més experimentats, experts en DBA. I poden dir si volarà o no.

Però potser seria millor si ho poguéssim provar nosaltres mateixos en còpies a mida completa. I avui només parlarem de quins enfocaments de prova són ara i de com es pot fer millor i amb quines eines. També parlarem dels avantatges i els contres d'aquests enfocaments i del que podem solucionar aquí.

Qui ha fet mai índexs directament al producte o ha fet canvis? Una mica de. I per a qui això va provocar que es perdessin dades o hi hagués temps d'inactivitat? Llavors coneixeu aquest dolor. Gràcies a Déu hi ha còpies de seguretat.

El primer enfocament és provar en prod. O, quan un desenvolupador s'asseu en una màquina local, té dades de prova, hi ha algun tipus de selecció limitada. I ens encarreguem d'impulsar, i tenim aquesta situació.

Fa mal, és car. Probablement és millor no fer-ho.

I quina és la millor manera de fer-ho?

Agafem la posada en escena i seleccionem una part del producte allà. O, en el millor dels casos, agafem un producte real, totes les dades. I després d'haver-lo desenvolupat localment, comprovarem, a més, la posada en escena.

Això ens permetrà eliminar alguns dels errors, és a dir, evitar que estiguin en prod.

Quins són els problemes?

• El problema és que compartim aquesta posada en escena amb els companys. I molt sovint passa que fas algun tipus de canvi, bam, i no hi ha dades, la feina està per la canalització. La posada en escena era de diversos terabytes. I cal esperar molt de temps perquè torni a pujar. I decidim finalitzar-ho demà. Això és tot, tenim un desenvolupament.
• I, és clar, hi treballem molts companys, molts equips. I s'ha de fer manualment. I això és inconvenient.

I val a dir que només tenim un intent, un cop, si volem fer alguns canvis a la base de dades, tocar les dades, canviar l'estructura. I si alguna cosa va sortir malament, si hi ha hagut un error en la migració, no tornarem enrere ràpidament.

Això és millor que l'enfocament anterior, però encara hi ha una alta probabilitat que algun tipus d'error passi a la producció.

Què ens impedeix oferir a cada desenvolupador un banc de proves, una còpia a mida completa? Crec que està clar què s'interposa.

Qui té una base de dades més gran que un terabyte? Més de la meitat de l'habitació.

I és evident que mantenir màquines per a cada desenvolupador, quan hi ha una producció tan gran, és molt car i, a més, costa molt de temps.

Tenim clients que s'han adonat que és molt important provar tots els canvis en còpies a mida completa, però la seva base de dades és inferior a un terabyte i no hi ha recursos per mantenir un banc de proves per a cada desenvolupador. Per tant, han de descarregar els abocadors localment a la seva màquina i provar d'aquesta manera. Es necessita molt de temps.

Fins i tot si ho feu dins de la infraestructura, descarregar un terabyte de dades per hora ja és molt bo. Però fan servir abocadors lògics, es descarreguen localment des del núvol. Per a ells, la velocitat és d'uns 200 gigabytes per hora. I encara es necessita temps per donar la volta de l'abocament lògic, enrotllar els índexs, etc.

Però utilitzen aquest enfocament perquè els permet mantenir el producte fiable.

Què podem fer aquí? Fem que els bancs de proves siguin barats i donem a cada desenvolupador el seu propi banc de proves.

I això és possible.

I en aquest enfocament, quan fem clons prims per a cada desenvolupador, podem compartir-ho en una màquina. Per exemple, si teniu una base de dades de 10 TB i voleu donar-la a 10 desenvolupadors, no cal que tingueu bases de dades de XNUMX x XNUMX TB. Només necessiteu una màquina per fer còpies fines aïllades per a cada desenvolupador amb una màquina. Ja us explicaré com funciona una mica més endavant.

Exemple real:

• DB - 4,5 terabytes.

• Podem obtenir còpies independents en 30 segons.

No cal esperar a un banc de proves i dependrà de la seva mida. El pots aconseguir en segons. Seran entorns completament aïllats, però que comparteixen dades entre ells.

Això es fantàstic. Aquí estem parlant de màgia i d'un univers paral·lel.

En el nostre cas, això funciona amb el sistema OpenZFS.

OpenZFS és un sistema de fitxers de còpia sobre escriptura que admet instantànies i clons des de la caixa. És fiable i escalable. És molt fàcil de gestionar. Es pot desplegar literalment en dos equips.

Hi ha altres opcions:

• lvm,

• Emmagatzematge (per exemple, Pure Storage).

El laboratori de bases de dades del qual parlo és modular. Es pot implementar amb aquestes opcions. Però de moment, ens hem centrat en OpenZFS, perquè hi havia problemes específicament amb LVM.

Com funciona? En lloc de reescriure les dades cada vegada que les canviem, les desem simplement marcant que aquestes noves dades són d'un nou punt en el temps, una nova instantània.

I en el futur, quan volem revertir o volem fer un nou clon d'alguna versió anterior, només diem: "D'acord, doneu-nos aquests blocs de dades que estan marcats així".

I aquest usuari treballarà amb aquest conjunt de dades. A poc a poc els canviarà, farà les seves pròpies instantànies.

I ens ramificarem. Cada desenvolupador en el nostre cas tindrà l'oportunitat de tenir el seu propi clon que editi, i les dades que es comparteixin es compartiran entre tothom.

Per implementar aquest sistema a casa, heu de resoldre dos problemes:

• El primer és la font de les dades, d'on les agafareu. Podeu configurar la replicació amb producció. Ja podeu fer servir les còpies de seguretat que hàgiu configurat, espero. WAL-E, WAL-G o Barman. I fins i tot si utilitzeu algun tipus de solució al núvol com RDS o Cloud SQL, podeu utilitzar abocaments lògics. Però tot i així t'aconsellem utilitzar còpies de seguretat, perquè amb aquest enfocament també conservaràs l'estructura física dels fitxers, la qual cosa et permetrà estar encara més a prop de les mètriques que veuries en producció per detectar aquells problemes que hi ha.

• El segon és on voleu allotjar el laboratori de bases de dades. Podria ser al núvol, podria ser on-premise. És important dir aquí que ZFS admet la compressió de dades. I ho fa força bé.

Imagineu que per a cada clon d'aquest tipus, depenent de les operacions que fem amb la base, creixerà algun tipus de dev. Per a això, el desenvolupador també necessitarà espai. Però a causa del fet que vam agafar una base de 4,5 terabytes, ZFS la comprimirà a 3,5 terabytes. Això pot variar segons la configuració. I encara tenim espai per a dev.

Aquest sistema es pot utilitzar per a diferents casos.

• Es tracta de desenvolupadors, DBA per a la validació de consultes, per a l'optimització.

• Això es pot utilitzar a les proves de control de qualitat per provar una migració concreta abans de llançar-la a la producció. I també podem crear entorns especials per al control de qualitat amb dades reals, on puguin provar noves funcionalitats. I trigarà segons en lloc d'hores d'espera, i potser dies en alguns altres casos en què no s'utilitzen còpies primes.

• I un altre cas. Si l'empresa no té un sistema d'anàlisi configurat, podem aïllar un clon prim de la base de productes i donar-lo a consultes llargues o índexs especials que es poden utilitzar en analítica.

Amb aquest enfocament:

1. Baixa probabilitat d'errors al "prod", perquè vam provar tots els canvis en dades a mida completa.

2. Tenim una cultura de proves, perquè ara no cal esperar hores pel teu propi estand.

3. I no hi ha cap barrera, ni espera entre proves. De fet, podeu anar a comprovar. I serà millor així a mesura que accelerem el desenvolupament.

• Hi haurà menys refactorització. Menys errors acabaran en producte. Més endavant els refactoritzarem menys.

• Podem revertir canvis irreversibles. Aquest no és l'enfocament estàndard.

1. Això és beneficiós perquè compartim els recursos dels bancs de proves.

Ja està bé, però què més es podria accelerar?

Gràcies a aquest sistema, podem reduir considerablement el llindar d'entrada a aquestes proves.

Ara hi ha un cercle viciós, quan un desenvolupador, per tenir accés a dades reals a mida completa, ha de convertir-se en un expert. S'ha de confiar en aquest accés.

Però com créixer si no hi és. Però, què passa si només tens a la teva disposició un conjunt molt petit de dades de prova? Aleshores no tindreu cap experiència real.

Com sortir d'aquest cercle? Com a primera interfície, convenient per a desenvolupadors de qualsevol nivell, vam triar el bot Slack. Però pot ser qualsevol altra interfície.

Què et permet fer? Podeu fer una consulta específica i enviar-la a un canal especial per a la base de dades. Desplegarem automàticament un clon prim en segons. Executem aquesta petició. Recopilem mètriques i recomanacions. Mostrem una visualització. I llavors aquest clon es mantindrà perquè aquesta consulta es pugui optimitzar d'alguna manera, afegir índexs, etc.

I també Slack ens ofereix oportunitats de col·laboració fora de la caixa. Com que es tracta només d'un canal, podeu començar a parlar d'aquesta sol·licitud allà mateix al fil d'aquesta sol·licitud, fent ping als vostres col·legues, DBA que es troben dins de l'empresa.

Però, és clar, hi ha problemes. Com que aquest és el món real i estem utilitzant un servidor que allotja molts clons alhora, hem de comprimir la quantitat de memòria i la potència de la CPU disponibles per als clons.

Però perquè aquestes proves siguin plausibles, cal resoldre d'alguna manera aquest problema.

Està clar que el punt important són les mateixes dades. Però ja ho tenim. I volem aconseguir la mateixa configuració. I podem donar una configuració gairebé idèntica.

Seria fantàstic tenir el mateix maquinari que en producció, però pot ser diferent.

Recordem com funciona Postgres amb la memòria. Tenim dos cachés. Un del sistema de fitxers i un de Postgres natiu, és a dir, la memòria cau de memòria intermèdia compartida.

És important tenir en compte que la memòria cau de memòria intermèdia compartida s'assigna quan s'inicia Postgres, depenent de la mida que especifiqueu a la configuració.

I la segona memòria cau utilitza tot l'espai disponible.

I quan fem diversos clons en una màquina, resulta que a poc a poc anem omplint la memòria. I en bona manera, la memòria cau compartida de la memòria intermèdia és el 25% de la quantitat total de memòria disponible a la màquina.

I resulta que si no canviem aquest paràmetre, només podrem executar 4 instàncies en una màquina, és a dir, 4 d'aquests clons prims en total. I això, és clar, és dolent, perquè en volem tenir molt més.

Però, d'altra banda, Buffer Cache s'utilitza per executar consultes d'índexs, és a dir, el pla depèn de la mida de les nostres cachés. I si només prenem aquest paràmetre i el reduïm, els nostres plans poden canviar molt.

Per exemple, si tenim una memòria cau gran a prod, Postgres preferirà utilitzar un índex. I si no, llavors hi haurà SeqScan. I quin sentit tindria si els nostres plans no coincidís?

Però aquí arribem a la conclusió que, de fet, el pla a Postgres no depèn de la mida específica especificada a la memòria intermèdia compartida del pla, sinó que depèn de la mida effective_cache_size.

Effective_cache_size és la quantitat estimada de memòria cau que tenim disponible, és a dir, la suma de la memòria cau de memòria intermèdia i la memòria cau del sistema de fitxers. Això ho defineix la configuració. I aquesta memòria no està assignada.

I a causa d'aquest paràmetre, podem enganyar a Postgres, dient que en realitat tenim moltes dades disponibles, encara que no disposem d'aquestes dades. I així, els plans coincidiran completament amb la producció.

Però això pot afectar el temps. I optimitzem les consultes segons el temps, però és important que el temps depengui de molts factors:

• Depèn de la càrrega que hi ha actualment al producte.

• Depèn de les característiques de la pròpia màquina.

I aquest és un paràmetre indirecte, però de fet podem optimitzar exactament la quantitat de dades que llegirà aquesta consulta per obtenir el resultat.

I si voleu que el moment s'aproximi al que veurem en prod, hem d'agafar el maquinari més semblant i, possiblement, encara més perquè encaixin tots els clons. Però això és un compromís, és a dir, obtindreu els mateixos plans, veureu quantes dades llegirà una consulta concreta i podreu concloure si aquesta consulta és bona (o migració) o dolenta, encara cal optimitzar-la. .

Mirem com Joe està optimitzat específicament.

Prenem una sol·licitud d'un sistema real. En aquest cas, la base de dades és d'1 terabyte. I volem comptar el nombre de publicacions noves que van tenir més de 10 m'agrada.

Estem escrivint un missatge al canal, s'ha desplegat un clon per a nosaltres. I veurem que aquesta sol·licitud es completarà en 2,5 minuts. Això és el primer que observem.

B Joe us mostrarà recomanacions automàtiques basades en el pla i les mètriques.

Veurem que la consulta processa massa dades per obtenir un nombre relativament petit de files. I cal algun tipus d'índex especialitzat, ja que hem observat que hi ha massa files filtrades a la consulta.

Fem una ullada més de prop al que va passar. De fet, veiem que hem llegit gairebé un giga i mig de dades de la memòria cau de fitxers o fins i tot del disc. I això no és bo, perquè només tenim 142 línies.

Sembla que aquí tenim una exploració d'índex i hauria d'haver funcionat ràpidament, però com que vam filtrar massa línies (les vam haver de comptar), la consulta va funcionar lentament.

I això va passar al pla a causa del fet que les condicions de la consulta i les condicions de l'índex parcialment no coincideixen.

Intentem fer l'índex més precís i veure com canvia l'execució de la consulta després d'això.

La creació de l'índex va trigar força, però ara comprovem la consulta i veiem que el temps en lloc de 2,5 minuts és només de 156 mil·lisegons, la qual cosa és prou bo. I només llegim 6 megabytes de dades.

I ara fem servir només l'escaneig d'índex.

Una altra història important és que volem presentar el pla d'una manera més entenedora. Hem implementat la visualització mitjançant Flame Graphs.

Aquesta és una petició diferent, més intensa. I construïm Flame Graphs d'acord amb dos paràmetres: aquesta és la quantitat de dades que un node determinat comptava en el pla i el temps, és a dir, el temps d'execució del node.

Aquí podem comparar nodes específics entre si. I quedarà clar quin d'ells triga més o menys, cosa que sol ser difícil de fer en altres mètodes de renderització.

Per descomptat, tothom sap explic.depesz.com. Una bona característica d'aquesta visualització és que desem el pla de text i també posem alguns paràmetres bàsics en una taula perquè puguem ordenar.

I els desenvolupadors que encara no han aprofundit en aquest tema també fan servir explic.depesz.com, perquè els és més fàcil esbrinar quines mètriques són importants i quines no.

Hi ha un nou enfocament de la visualització: això és explica.dalibo.com. Fan una visualització d'arbres, però és molt difícil comparar els nodes entre ells. Aquí podeu entendre bé l'estructura, però, si hi ha una sol·licitud gran, haureu de desplaçar-vos cap endavant i cap enrere, però també una opció.

col·laboració

I, com he dit, Slack ens dóna l'oportunitat de col·laborar. Per exemple, si ens trobem amb una consulta complexa que no té clar com optimitzar, podem aclarir aquest problema amb els nostres companys en un fil a Slack.

Ens sembla que és important provar dades a mida completa. Per fer-ho, hem creat l'eina Update Database Lab, que està disponible en codi obert. També podeu utilitzar el bot Joe. Podeu agafar-lo ara mateix i implementar-lo al vostre lloc. Totes les guies estan disponibles allà.

També és important tenir en compte que la solució en si no és revolucionària, perquè hi ha Delphix, però és una solució empresarial. Està totalment tancat, és molt car. Ens especialitzem específicament en Postgres. Tots aquests són productes de codi obert. Uneix-te a nosaltres!

Aquí és on acabo. Gràcies!

Les vostres preguntes

Hola! Gràcies pel reportatge! Molt interessant, sobretot per a mi, perquè vaig resoldre el mateix problema fa un temps. I per tant tinc una sèrie de preguntes. Espero que n'aconsegueixi almenys una part.

Em pregunto com calculeu el lloc d'aquest entorn? La tecnologia significa que, en determinades circumstàncies, els vostres clons poden créixer a la mida màxima. A grans trets, si teniu una base de dades de deu terabytes i 10 clons, és fàcil simular una situació en què cada clon pesi 10 dades úniques. Com calcules aquest indret, és a dir, aquell delta del qual parlaves, on viuran aquests clons?

Bona pregunta. És important fer un seguiment de clons específics aquí. I si un clon té un canvi massa gran, comença a créixer, primer podem emetre un avís a l'usuari sobre això o aturar immediatament aquest clon perquè no tinguem una situació de fallada.

Sí, tinc una pregunta imbricada. És a dir, com es garanteix el cicle de vida d'aquests mòduls? Tenim aquest problema i una història completament a part. Com passa això?

Hi ha una mica de ttl per a cada clon. Bàsicament, tenim un ttl fix.

Què, si no és un secret?

1 hora, és a dir, inactiu - 1 hora. Si no s'utilitza, l'encetem. Però aquí no hi ha cap sorpresa, ja que podem augmentar el clon en segons. I si ho necessiteu de nou, si us plau.

També m'interessa l'elecció de tecnologies, perquè, per exemple, utilitzem diversos mètodes en paral·lel per un motiu o un altre. Per què ZFS? Per què no vau utilitzar LVM? Heu esmentat que hi havia problemes amb LVM. Quins eren els problemes? Al meu entendre, l'opció més òptima és amb emmagatzematge, pel que fa al rendiment.

Quin és el principal problema amb ZFS? El fet que hàgiu d'executar-vos al mateix host, és a dir, totes les instàncies viuran dins del mateix sistema operatiu. I en el cas de l'emmagatzematge, podeu connectar diferents equips. I el coll d'ampolla són només aquells blocs que es troben al sistema d'emmagatzematge. I la qüestió de l'elecció de les tecnologies és interessant. Per què no LVM?

Concretament, podem parlar de LVM a la reunió. Sobre l'emmagatzematge: només és car. Podem implementar el sistema ZFS a qualsevol lloc. Podeu implementar-lo a la vostra màquina. Només podeu descarregar el repositori i desplegar-lo. ZFS s'instal·la gairebé a tot arreu si parlem de Linux. És a dir, obtenim una solució molt flexible. I el mateix ZFS ofereix molt de sortida. Podeu carregar tantes dades com vulgueu, connectar un gran nombre de discos, hi ha instantànies. I, com he dit, és fàcil d'administrar. És a dir, sembla molt agradable d'utilitzar. Està provat, té molts anys. Té una comunitat molt gran que està creixent. ZFS és una solució molt fiable.

Nikolai Samokhvalov: Puc comentar més? Em dic Nikolay, treballem juntament amb Anatoly. Estic d'acord que l'emmagatzematge és fantàstic. I alguns dels nostres clients tenen Pure Storage, etc.

Anatoly va assenyalar correctament que estem centrats en la modularitat. I en el futur, podeu implementar una interfície: fer una instantània, fer un clon, destruir el clon. Tot és fàcil. I l'emmagatzematge és fresc, si ho és.

Però ZFS està disponible per a tothom. DelPhix ja és suficient, tenen 300 clients. D'aquests, fortune 100 té 50 clients, és a dir, estan destinats a la NASA, etc. És hora que tothom s'aconsegueixi aquesta tecnologia. I per això tenim un Core de codi obert. Tenim una part d'interfície que no és de codi obert. Aquesta és la plataforma que mostrarem. Però volem que sigui accessible per a tothom. Volem fer una revolució perquè tots els provadors deixin d'endevinar als portàtils. Hem d'escriure SELECT i de seguida veure que és lent. Deixeu d'esperar que el DBA us ho expliqui. Aquí està l'objectiu principal. I crec que tots arribarem a això. I fem aquesta cosa perquè tothom la tingui. Per tant, ZFS, perquè estarà disponible a tot arreu. Gràcies a la comunitat per resoldre problemes i per tenir una llicència de codi obert, etc.*

Salutacions! Gràcies pel reportatge! Em dic Maxim. Hem tractat els mateixos temes. Van decidir ells mateixos. Com comparteixes recursos entre aquests clons? Cada clon pot fer les seves coses en qualsevol moment: un prova una cosa, un altre una altra, algú construeix un índex, algú té una feina pesada. I si encara podeu dividir per CPU, després per IO, com es divideix? Aquesta és la primera pregunta.

I la segona pregunta és sobre la desigualtat de les grades. Suposem que tinc ZFS aquí i tot està bé, però el client de prod no té ZFS, sinó ext4, per exemple. Com en aquest cas?

Les preguntes són molt bones. He esmentat una mica aquest problema amb el fet que compartim recursos. I la solució és aquesta. Imagina que estàs fent proves sobre la posada en escena. També pots tenir una situació així al mateix temps que algú dóna una càrrega, algú altre. I com a resultat, veus mètriques incomprensibles. Fins i tot el mateix problema pot ser amb el producte. Quan voleu comprovar alguna sol·licitud i veieu que hi ha algun problema, funciona lentament, de fet, el problema no es trobava en la sol·licitud, sinó en el fet que hi ha algun tipus de càrrega paral·lela.

I, per tant, aquí és important centrar-nos en quin serà el pla, quins passos farem en el pla i quantes dades recollirem per a això. El fet que els nostres discs, per exemple, es carreguin amb alguna cosa, afectarà específicament el temps. Però podem estimar la càrrega d'aquesta sol·licitud per la quantitat de dades. No és tan important que al mateix temps hi hagi algun tipus d'execució.

Tinc dues preguntes. Això és una cosa molt xula. Hi ha hagut casos en què les dades de producció són crítiques, com ara números de targeta de crèdit? Ja hi ha alguna cosa a punt o és una tasca a part? I la segona pregunta: hi ha alguna cosa com això per a MySQL?

Sobre les dades. Farem ofuscacions fins que ho fem. Però si desplegueu exactament Joe, si no doneu accés als desenvolupadors, no hi ha accés a les dades. Per què? Perquè en Joe no mostra dades. Només mostra mètriques, plans i ja està. Això es va fer a propòsit, perquè aquest és un dels requisits del nostre client. Volien poder optimitzar sense donar accés a tothom.

Sobre MySQL. Aquest sistema es pot utilitzar per a qualsevol cosa que emmagatzemi l'estat al disc. I com que estem fent Postgres, ara estem fent tota l'automatització per a Postgres primer. Volem automatitzar l'obtenció de dades d'una còpia de seguretat. Estem configurant Postgres correctament. Sabem com fer coincidir els plans, etc.

Però com que el sistema és extensible, també es pot utilitzar per a MySQL. I aquests exemples n'hi ha. Yandex té una cosa semblant, però no la publiquen enlloc. L'utilitzen dins de Yandex.Metrica. I només hi ha una història sobre MySQL. Però les tecnologies són les mateixes, ZFS.

Gràcies pel reportatge! També tinc un parell de preguntes. Heu esmentat que la clonació es pot utilitzar per a analítiques, per exemple, per crear-hi índexs addicionals. Pots explicar una mica més com funciona?

I de seguida faré la segona pregunta sobre la similitud de les grades, la similitud dels plànols. El pla també depèn de les estadístiques recollides per Postgres. Com resoleu aquest problema?

Segons les analítiques, no hi ha casos concrets, perquè encara no l'hem utilitzat, però hi ha aquesta oportunitat. Si estem parlant d'índexs, imagineu-vos que una consulta està perseguint una taula amb centenars de milions de registres i una columna que normalment no està indexada a prod. I aquí volem calcular algunes dades. Si aquesta sol·licitud s'envia a prod, hi ha la possibilitat que sigui senzilla a prod, perquè la sol·licitud es processarà allà durant un minut.

D'acord, anem a fer un clon prim que no és terrible aturar-se durant uns minuts. I per tal de facilitar la lectura de les analítiques, afegirem índexs per a aquelles columnes en què ens interessen les dades.

L'índex es crearà cada vegada?

Podeu fer-ho perquè toquem les dades, fem instantànies, després ens recuperarem d'aquesta instantània i generarem noves sol·licituds. És a dir, podeu fer-ho de manera que pugueu generar nous clons amb índexs ja fixats.

Pel que fa a la pregunta sobre les estadístiques, si restaurem des d'una còpia de seguretat, si fem rèplica, les nostres estadístiques seran exactament les mateixes. Com que tenim tota l'estructura de dades físiques, és a dir, també portarem les dades tal com estan amb totes les mètriques estadístiques.

Aquí hi ha un altre problema. Si utilitzeu una solució al núvol, només hi ha disponibles abocaments lògics, perquè Google, Amazon no us permeten fer una còpia física. Hi haurà un problema.

Gràcies pel reportatge. Aquí hi havia dues bones preguntes sobre MySQL i l'ús compartit de recursos. Però, de fet, tot es redueix al fet que no es tracta d'un tema d'un SGBD específic, sinó del sistema de fitxers en conjunt. I, en conseqüència, els problemes de compartir recursos també s'han de resoldre des d'aquí, no al final que sigui Postgres, sinó al sistema de fitxers, al servidor, per exemple.

La meva pregunta és una mica diferent. Està més a prop de la base de dades multicapa, on hi ha diverses capes. Per exemple, configurem una actualització d'imatge de deu terabytes, estem replicant. I fem servir aquesta solució específicament per a bases de dades. La replicació està en curs, les dades s'estan actualitzant. Aquí hi treballen 100 empleats en paral·lel, que estan constantment llançant aquestes diferents preses. Què fer? Com assegurar-se que no hi ha cap conflicte, que n'han llançat un i, aleshores, el sistema de fitxers ha canviat i totes aquestes imatges han anat?

No aniran perquè és així com funciona ZFS. Podem mantenir per separat en un fil els canvis del sistema de fitxers que es produeixen a causa de la replicació. I manteniu els clons que utilitzen els desenvolupadors en versions anteriors de les dades. I ens funciona, tot està en ordre amb això.

Resulta que l'actualització es farà com una capa addicional i totes les imatges noves ja aniran, basades en aquesta capa, oi?

De capes anteriors que eren de rèpliques anteriors.

Les capes anteriors cauran, però es referiran a la capa antiga i prendran imatges noves de l'última capa que es va rebre a l'actualització?

En general, sí.

Aleshores com a conseqüència tindrem fins a una figa de capes. I amb el temps caldrà comprimir-los?

Sí, tot és correcte. Hi ha alguna finestra. Conservem instantànies setmanals. Depèn del recurs que tinguis. Si teniu la possibilitat d'emmagatzemar moltes dades, podeu emmagatzemar instantànies durant molt de temps. No marxaran sols. No hi haurà corrupció de dades. Si les instantànies estan obsoletes, tal com ens sembla, és a dir, depèn de la política de l'empresa, simplement podem esborrar-les i alliberar espai.

Hola, gràcies pel reportatge! Pregunta sobre Joe. Vostè va dir que el client no volia donar accés a les dades a tothom. En sentit estricte, si una persona té el resultat d'Explica analitzar, pot mirar les dades.

És així. Per exemple, podem escriure: "SELECT FROM WHERE email = to that". És a dir, no veurem les dades en si, però sí que podem veure alguns senyals indirectes. Això s'ha d'entendre. Però, d'altra banda, hi és tot. Tenim una auditoria de registre, tenim el control d'altres companys que també veuen què estan fent els desenvolupadors. I si algú intenta fer-ho, el servei de seguretat vindrà a buscar-los i treballarà en aquest tema.

Bona tarda Gràcies pel reportatge! Tinc una pregunta breu. Si l'empresa no utilitza Slack, hi ha alguna vinculació ara o és possible que els desenvolupadors implementin instàncies per connectar una aplicació de prova a les bases de dades?

Ara hi ha un enllaç a Slack, és a dir, no hi ha cap altre missatger, però també vull donar suport a altres missatgers. Què pots fer? Podeu implementar DB Lab sense Joe, anar amb l'ajuda de l'API REST o amb l'ajuda de la nostra plataforma i crear clons i connectar-vos amb PSQL. Però això es pot fer si esteu preparat per donar accés a les dades als vostres desenvolupadors, perquè ja no hi haurà cap pantalla.

No necessito aquesta capa, però necessito aquesta oportunitat.

Aleshores sí, es pot fer.

Font: www.habr.com