DBA-bot Joe. Anatoly Stansler (Postgres.ai)

Hvordan forstår en backend-utvikler at en SQL-spørring vil fungere bra på en "prod"? I store eller raskt voksende bedrifter er det ikke alle som har tilgang til «produktet». Og med tilgang kan ikke alle forespørsler kontrolleres smertefritt, og å lage en kopi av databasen tar ofte timer. For å løse disse problemene laget vi en kunstig DBA - Joe. Det er allerede vellykket implementert i flere selskaper og hjelper mer enn et dusin utviklere.

Video:

Hei alle sammen! Mitt navn er Anatoly Stansler. Jeg jobber for et selskap postgres.ai. Vi er forpliktet til å fremskynde utviklingsprosessen ved å fjerne forsinkelsene knyttet til arbeidet til Postgres fra utviklere, DBAer og QAer.

Vi har flotte kunder, og i dag vil en del av rapporten være viet saker vi møtte mens vi jobbet med dem. Jeg vil snakke om hvordan vi hjalp dem med å løse ganske alvorlige problemer.

Når vi utvikler og utfører komplekse høybelastningsmigrasjoner, stiller vi oss selv spørsmålet: "Vil denne migreringen ta av?". Vi bruker anmeldelse, vi bruker kunnskapen til mer erfarne kolleger, DBA-eksperter. Og de kan si om den vil fly eller ikke.

Men kanskje det ville vært bedre om vi kunne teste det selv på full størrelse kopier. Og i dag skal vi bare snakke om hvilke tilnærminger til testing er nå og hvordan det kan gjøres bedre og med hvilke verktøy. Vi vil også snakke om fordeler og ulemper med slike tilnærminger, og hva vi kan fikse her.

Hvem har noen gang laget indekser direkte på prod eller gjort noen endringer? Ganske mye av. Og for hvem førte dette til at data gikk tapt eller nedetid? Da kjenner du denne smerten. Takk Gud for at det finnes sikkerhetskopier.

Den første tilnærmingen er testing i prod. Eller, når en utvikler sitter på en lokal maskin, har han testdata, det er en slags begrenset utvalg. Og vi ruller ut for å prod, og vi får denne situasjonen.

Det gjør vondt, det er dyrt. Det er nok best å la være.

Og hva er den beste måten å gjøre det på?

La oss ta iscenesettelse og velge en del av prod der. Eller i beste fall, la oss ta en skikkelig prod, alle dataene. Og etter at vi har utviklet det lokalt, vil vi i tillegg sjekke for iscenesettelse.

Dette vil tillate oss å fjerne noen av feilene, dvs. forhindre at de blir på prod.

Hva er problemene?

• Problemet er at vi deler denne iscenesettelsen med kolleger. Og veldig ofte skjer det at du gjør en slags endring, bam - og det er ingen data, arbeidet er i vasken. Staging var multi-terabyte. Og du må vente lenge på at den skal heve seg igjen. Og vi bestemmer oss for å fullføre det i morgen. Det er det, vi har en utvikling.
• Og selvfølgelig har vi mange kolleger som jobber der, mange team. Og det må gjøres manuelt. Og dette er upraktisk.

Og det er verdt å si at vi bare har ett forsøk, ett skudd, hvis vi vil gjøre noen endringer i databasen, trykk på dataene, endre strukturen. Og hvis noe gikk galt, hvis det var en feil i migreringen, vil vi ikke raskt rulle tilbake.

Dette er bedre enn den forrige tilnærmingen, men det er fortsatt stor sannsynlighet for at en eller annen form for feil vil gå til produksjon.

Hva hindrer oss i å gi hver utvikler en testbenk, en kopi i full størrelse? Jeg synes det er klart hva som kommer i veien.

Hvem har en database større enn en terabyte? Mer enn halve rommet.

Og det er klart at det er veldig dyrt å holde maskiner for hver utvikler, når det er så stor produksjon, og dessuten tar det lang tid.

Vi har kunder som har innsett at det er veldig viktig å teste alle endringer på kopier i full størrelse, men databasen deres er mindre enn en terabyte, og det er ingen ressurser til å holde en testbenk for hver utvikler. Derfor må de laste ned dumpene lokalt til maskinen sin og teste på denne måten. Det tar mye tid.

Selv om du gjør det inne i infrastrukturen, er det allerede veldig bra å laste ned én terabyte med data i timen. Men de bruker logiske dumps, de laster ned lokalt fra skyen. For dem er hastigheten rundt 200 gigabyte i timen. Og det tar fortsatt tid å snu fra den logiske dumpen, rulle opp indeksene osv.

Men de bruker denne tilnærmingen fordi den lar dem holde proden pålitelig.

Hva kan vi gjøre her? La oss gjøre testbenker billige og gi hver utvikler sin egen testbenk.

Og dette er mulig.

Og i denne tilnærmingen, når vi lager tynne kloner for hver utvikler, kan vi dele den på én maskin. For eksempel, hvis du har en 10TB-database og ønsker å gi den til 10 utviklere, trenger du ikke ha XNUMX x XNUMXTB-databaser. Du trenger bare én maskin for å lage tynne isolerte kopier for hver utvikler som bruker én maskin. Jeg skal fortelle deg hvordan det fungerer litt senere.

Ekte eksempel:

• DB - 4,5 terabyte.

• Vi kan få uavhengige kopier på 30 sekunder.

Du trenger ikke vente på en teststand og er avhengig av hvor stor den er. Du kan få det på sekunder. Det vil være helt isolerte miljøer, men som deler data seg imellom.

Dette er flott. Her snakker vi om magi og et parallellunivers.

I vårt tilfelle fungerer dette med OpenZFS-systemet.

OpenZFS er et kopi-på-skriv-filsystem som støtter øyeblikksbilder og kloner ut av esken. Den er pålitelig og skalerbar. Hun er veldig lett å administrere. Det kan bokstavelig talt distribueres i to lag.

Det er andre alternativer:

• lvm,

• Lagring (for eksempel Pure Storage).

Databaselaben jeg snakker om er modulær. Kan implementeres ved hjelp av disse alternativene. Men foreløpig har vi fokusert på OpenZFS, fordi det var problemer med LVM spesifikt.

Hvordan det fungerer? I stedet for å overskrive dataene hver gang vi endrer dem, lagrer vi dem ved ganske enkelt å merke at disse nye dataene er fra et nytt tidspunkt, et nytt øyeblikksbilde.

Og i fremtiden, når vi ønsker å rulle tilbake eller vi vil lage en ny klone fra en eldre versjon, sier vi bare: "OK, gi oss disse datablokkene som er merket som dette."

Og denne brukeren vil jobbe med et slikt datasett. Han vil gradvis endre dem, lage sine egne øyeblikksbilder.

Og vi vil gren. Hver utvikler i vårt tilfelle vil ha muligheten til å ha sin egen klone som han redigerer, og dataene som deles vil bli delt mellom alle.

For å distribuere et slikt system hjemme, må du løse to problemer:

• Den første er kilden til dataene, hvor du vil ta den fra. Du kan sette opp replikering med produksjon. Du kan allerede bruke sikkerhetskopiene som du har konfigurert, håper jeg. WAL-E, WAL-G eller Barman. Og selv om du bruker en slags Cloud-løsning som RDS eller Cloud SQL, kan du bruke logiske dumper. Men vi anbefaler deg likevel å bruke sikkerhetskopier, for med denne tilnærmingen vil du også beholde den fysiske strukturen til filene, noe som vil tillate deg å være enda nærmere beregningene du vil se i produksjonen for å fange opp de problemene som eksisterer.

• Det andre er hvor du vil være vert for databaselaben. Det kan være Cloud, det kan være On-premise. Det er viktig å si her at ZFS støtter datakomprimering. Og det gjør det ganske bra.

Tenk deg at for hver slik klon, avhengig av operasjonene vi gjør med basen, vil en slags dev vokse. For dette vil dev også trenge plass. Men på grunn av det faktum at vi tok en base på 4,5 terabyte, vil ZFS komprimere den til 3,5 terabyte. Dette kan variere avhengig av innstillingene. Og vi har fortsatt plass til utvikling.

Et slikt system kan brukes til forskjellige tilfeller.

• Dette er utviklere, DBAer for spørringsvalidering, for optimalisering.

• Dette kan brukes i QA-testing for å teste en bestemt migrering før vi ruller den ut til prod. Og vi kan også heve spesielle miljøer for QA med ekte data, hvor de kan teste ny funksjonalitet. Og det vil ta sekunder i stedet for å vente timer, og kanskje dager i noen andre tilfeller hvor tynne kopier ikke brukes.

• Og en annen sak. Hvis selskapet ikke har et analysesystem satt opp, kan vi isolere en tynn klone av produktbasen og gi den til lange spørringer eller spesielle indekser som kan brukes i analyser.

Med denne tilnærmingen:

1. Lav sannsynlighet for feil på "prod", fordi vi testet alle endringene på data i full størrelse.

2. Vi har en testkultur, for nå slipper du å vente i timevis på din egen stand.

3. Og det er ingen barriere, ingen venting mellom testene. Du kan faktisk gå og sjekke. Og det blir bedre på denne måten ettersom vi får fart på utviklingen.

• Det blir mindre refaktorering. Færre feil vil ende opp i prod. Vi vil refaktorisere dem mindre senere.

• Vi kan reversere irreversible endringer. Dette er ikke standardmetoden.

1. Dette er gunstig fordi vi deler ressursene til testbenkene.

Allerede bra, men hva annet kan fremskyndes?

Takket være et slikt system kan vi redusere terskelen betraktelig for å gå inn i slik testing.

Nå er det en ond sirkel, når en utvikler, for å få tilgang til ekte fullstørrelsesdata, må bli en ekspert. Han må ha tillit til slik tilgang.

Men hvordan vokse hvis det ikke er der. Men hva om du bare har et veldig lite sett med testdata tilgjengelig for deg? Da får du ingen reell opplevelse.

Hvordan komme seg ut av denne sirkelen? Som det første grensesnittet, praktisk for utviklere på alle nivåer, valgte vi Slack-boten. Men det kan være et hvilket som helst annet grensesnitt.

Hva lar det deg gjøre? Du kan ta en spesifikk forespørsel og sende den til en spesiell kanal for databasen. Vi vil automatisk distribuere en tynn klon i løpet av sekunder. La oss kjøre denne forespørselen. Vi samler inn beregninger og anbefalinger. La oss vise en visualisering. Og så vil denne klonen forbli slik at denne spørringen på en eller annen måte kan optimaliseres, legge til indekser osv.

Og også Slack gir oss muligheter for samarbeid ut av boksen. Siden dette bare er en kanal, kan du begynne å diskutere denne forespørselen rett der i tråden for en slik forespørsel, ping dine kolleger, DBA-er som er inne i selskapet.

Men det er selvfølgelig problemer. Fordi dette er den virkelige verden, og vi bruker en server som er vert for mange kloner samtidig, må vi komprimere mengden minne og CPU-kraft som er tilgjengelig for klonene.

Men for at disse testene skal være plausible, må du på en eller annen måte løse dette problemet.

Det er klart at det viktige poenget er de samme dataene. Men vi har det allerede. Og vi ønsker å oppnå samme konfigurasjon. Og vi kan gi en slik nesten identisk konfigurasjon.

Det ville vært kult å ha samme maskinvare som i produksjon, men det kan variere.

La oss huske hvordan Postgres jobber med hukommelse. Vi har to cacher. En fra filsystemet og en innfødt Postgres, det vil si Shared Buffer Cache.

Det er viktig å merke seg at Shared Buffer Cache tildeles når Postgres starter, avhengig av hvilken størrelse du angir i konfigurasjonen.

Og den andre cachen bruker all tilgjengelig plass.

Og når vi lager flere kloner på en maskin, viser det seg at vi gradvis fyller minnet. Og på en god måte er Shared Buffer Cache 25 % av den totale mengden minne som er tilgjengelig på maskinen.

Og det viser seg at hvis vi ikke endrer denne parameteren, vil vi bare kunne kjøre 4 forekomster på en maskin, det vil si totalt 4 av disse tynne klonene. Og dette er selvfølgelig dårlig, for vi ønsker å ha mye flere av dem.

Men på den annen side brukes Buffer Cache til å utføre spørringer for indekser, det vil si at planen avhenger av hvor store cachene våre er. Og hvis vi bare tar denne parameteren og reduserer den, kan planene våre endre seg mye.

For eksempel, hvis vi har en stor cache på prod, vil Postgres foretrekke å bruke en indeks. Og hvis ikke, så blir det SeqScan. Og hva ville være vitsen hvis planene våre ikke falt sammen?

Men her kommer vi til den konklusjon at faktisk planen i Postgres ikke avhenger av den spesifikke størrelsen spesifisert i den delte bufferen i planen, den avhenger av effektiv_cache_size.

Effective_cache_size er den estimerte mengden cache som er tilgjengelig for oss, dvs. summen av bufferbuffer og filsystembuffer. Dette er satt av konfigurasjonen. Og dette minnet er ikke tildelt.

Og på grunn av denne parameteren kan vi på en måte lure Postgres og si at vi faktisk har mye data tilgjengelig, selv om vi ikke har disse dataene. Og dermed vil planene falle helt sammen med produksjonen.

Men dette kan påvirke timingen. Og vi optimaliserer søk etter timing, men det er viktig at timing avhenger av mange faktorer:

• Det avhenger av lasten som for øyeblikket er på prod.

• Det avhenger av egenskapene til selve maskinen.

Og dette er en indirekte parameter, men faktisk kan vi optimalisere nøyaktig etter mengden data som denne spørringen vil lese for å få resultatet.

Og hvis du vil at timingen skal være nær det vi vil se i prod, må vi ta den mest like maskinvaren og muligens enda mer slik at alle klonene passer. Men dette er et kompromiss, det vil si at du vil få de samme planene, du vil se hvor mye data en bestemt spørring vil lese og du vil kunne konkludere om denne spørringen er god (eller migrering) eller dårlig, den må fortsatt optimaliseres .

La oss ta en titt på hvordan Joe er spesifikt optimalisert.

La oss ta en forespørsel fra et ekte system. I dette tilfellet er databasen 1 terabyte. Og vi ønsker å telle antall ferske innlegg som hadde mer enn 10 likes.

Vi skriver en melding til kanalen, en klon har blitt distribuert for oss. Og vi vil se at en slik forespørsel vil fullføres på 2,5 minutter. Dette er det første vi legger merke til.

B Joe vil vise deg automatiske anbefalinger basert på planen og beregningene.

Vi vil se at spørringen behandler for mye data til å få et relativt lite antall rader. Og en slags spesialisert indeks er nødvendig, siden vi la merke til at det er for mange filtrerte rader i spørringen.

La oss se nærmere på hva som skjedde. Vi ser faktisk at vi har lest nesten en og en halv gigabyte med data fra filbufferen eller til og med fra disken. Og dette er ikke bra, for vi fikk bare 142 linjer.

Og, ser det ut til, vi har en indeksskanning her og burde ha fungert raskt, men siden vi filtrerte ut for mange linjer (vi måtte telle dem), løste spørringen seg sakte.

Og dette skjedde i planen på grunn av at betingelsene i spørringen og betingelsene i indeksen delvis ikke stemmer overens.

La oss prøve å gjøre indeksen mer presis og se hvordan spørringskjøringen endres etter det.

Opprettelsen av indeksen tok ganske lang tid, men nå sjekker vi spørringen og ser at tiden i stedet for 2,5 minutter bare er 156 millisekunder, noe som er bra nok. Og vi leser bare 6 megabyte med data.

Og nå bruker vi kun indeksskanning.

En annen viktig historie er at vi ønsker å presentere planen på en mer forståelig måte. Vi har implementert visualisering ved hjelp av Flame Graphs.

Dette er en annen forespørsel, mer intens. Og vi bygger Flame Graphs i henhold til to parametere: dette er mengden data som en bestemt node telte i planen og timingen, det vil si utførelsestiden til noden.

Her kan vi sammenligne spesifikke noder med hverandre. Og det vil være klart hvilken av dem som tar mer eller mindre, noe som vanligvis er vanskelig å gjøre i andre gjengivelsesmetoder.

Selvfølgelig vet alle explain.depesz.com. En god egenskap ved denne visualiseringen er at vi lagrer tekstplanen og legger også inn noen grunnleggende parametere i en tabell slik at vi kan sortere.

Og utviklere som ennå ikke har fordypet seg i dette emnet, bruker også explain.depesz.com, fordi det er lettere for dem å finne ut hvilke beregninger som er viktige og hvilke som ikke er det.

Det er en ny tilnærming til visualisering - dette er explain.dalibo.com. De gjør en trevisualisering, men det er veldig vanskelig å sammenligne noder med hverandre. Her kan du forstå strukturen godt, men hvis det er en stor forespørsel, må du bla frem og tilbake, men også et alternativ.

samarbeid

Og som sagt, Slack gir oss muligheten til å samarbeide. For eksempel, hvis vi kommer over et komplekst spørsmål som ikke er klart hvordan vi skal optimalisere, kan vi avklare dette problemet med våre kolleger i en tråd i Slack.

Det virker for oss som om det er viktig å teste på data i full størrelse. For å gjøre dette laget vi verktøyet Update Database Lab, som er tilgjengelig i åpen kildekode. Du kan også bruke Joe-boten. Du kan ta det akkurat nå og implementere det hos deg. Alle guider er tilgjengelige der.

Det er også viktig å merke seg at løsningen i seg selv ikke er revolusjonerende, fordi det er Delphix, men det er en bedriftsløsning. Det er helt lukket, det er veldig dyrt. Vi spesialiserer oss spesielt på Postgres. Disse er alle åpen kildekode-produkter. Bli med oss!

Det er her jeg slutter. Takk skal du ha!

spørsmål

Hallo! Takk for rapporten! Veldig interessant, spesielt for meg, fordi jeg løste omtrent det samme problemet for en tid siden. Og derfor har jeg en rekke spørsmål. Forhåpentligvis får jeg i det minste en del av det.

Jeg lurer på hvordan du beregner plassen for dette miljøet? Teknologien betyr at klonene dine under visse omstendigheter kan vokse til maksimal størrelse. Grovt sett, hvis du har en ti terabyte database og 10 kloner, så er det enkelt å simulere en situasjon der hver klon veier 10 unike data. Hvordan beregner du dette stedet, det vil si deltaet som du snakket om, der disse klonene vil leve?

Godt spørsmål. Det er viktig å holde styr på spesifikke kloner her. Og hvis en klon har en for stor endring, begynner den å vokse, så kan vi først gi en advarsel til brukeren om dette, eller umiddelbart stoppe denne klonen slik at vi ikke har en feilsituasjon.

Ja, jeg har et stillestående spørsmål. Det vil si, hvordan sikrer du livssyklusen til disse modulene? Vi har dette problemet og en helt egen historie. Hvordan skjer dette?

Det er noen ttl for hver klon. I utgangspunktet har vi en fast ttl.

Hva, hvis ikke en hemmelighet?

1 time, dvs. tomgang - 1 time. Hvis den ikke brukes, så banker vi den. Men det er ingen overraskelse her, siden vi kan heve klonen på sekunder. Og hvis du trenger det igjen, vær så snill.

Jeg er også interessert i valg av teknologier, fordi vi for eksempel bruker flere metoder parallelt av en eller annen grunn. Hvorfor ZFS? Hvorfor brukte du ikke LVM? Du nevnte at det var problemer med LVM. Hva var problemene? Etter min mening er det mest optimale alternativet med lagring, med tanke på ytelse.

Hva er hovedproblemet med ZFS? Det faktum at du må kjøre på samme vert, det vil si at alle forekomster vil leve innenfor samme OS. Og når det gjelder lagring, kan du koble til forskjellig utstyr. Og flaskehalsen er bare de blokkene som er på lagringssystemet. Og spørsmålet om valg av teknologier er interessant. Hvorfor ikke LVM?

Spesielt kan vi diskutere LVM på meetup. Om lagring - det er bare dyrt. Vi kan implementere ZFS-systemet hvor som helst. Du kan distribuere den på maskinen din. Du kan ganske enkelt laste ned depotet og distribuere det. ZFS er installert nesten overalt hvis vi snakker om Linux. Det vil si at vi får en veldig fleksibel løsning. Og ut av esken gir ZFS mye. Du kan laste opp så mye data du vil, koble til et stort antall disker, det er øyeblikksbilder. Og det er som sagt lett å administrere. Det vil si at den virker veldig behagelig å bruke. Han er testet, han er mange år gammel. Han har et veldig stort fellesskap som vokser. ZFS er en veldig pålitelig løsning.

Nikolai Samokhvalov: Kan jeg kommentere ytterligere? Jeg heter Nikolay, vi jobber sammen med Anatoly. Jeg er enig i at lagring er flott. Og noen av våre kunder har Pure Storage mm.

Anatoly bemerket riktig at vi er fokusert på modularitet. Og i fremtiden kan du implementere ett grensesnitt - ta et øyeblikksbilde, lag en klone, ødelegge klonen. Det hele er enkelt. Og oppbevaring er kult, hvis det er det.

Men ZFS er tilgjengelig for alle. DelPhix er allerede nok, de har 300 kunder. Av disse har Fortune 100 50 klienter, det vil si at de er rettet mot NASA osv. Det er på tide at alle får denne teknologien. Og det er derfor vi har en åpen kildekode-kjerne. Vi har en grensesnittdel som ikke er åpen kildekode. Dette er plattformen vi skal vise. Men vi ønsker at det skal være tilgjengelig for alle. Vi ønsker å gjøre en revolusjon slik at alle testere slutter å gjette på bærbare datamaskiner. Vi må skrive SELECT og umiddelbart se at det går tregt. Slutt å vent på at DBA skal fortelle deg om det. Her er hovedmålet. Og jeg tror at vi alle kommer til dette. Og vi lager denne tingen for alle å ha. Derfor ZFS, fordi den vil være tilgjengelig overalt. Takk til fellesskapet for å løse problemer og for å ha en åpen kildekode-lisens osv.*

Hilsener! Takk for rapporten! Mitt navn er Maxim. Vi har behandlet de samme problemene. De bestemte seg selv. Hvordan deler du ressurser mellom disse klonene? Hver klon kan gjøre sin egen ting til enhver tid: en tester en ting, en annen en annen, noen bygger en indeks, noen har en tung jobb. Og hvis du fortsatt kan dele etter CPU, så etter IO, hvordan deler du? Dette er det første spørsmålet.

Og det andre spørsmålet handler om ulikhetene på tribunene. La oss si at jeg har ZFS her og alt er kult, men klienten på prod har ikke ZFS, men ext4, for eksempel. Hvordan i dette tilfellet?

Spørsmålene er veldig gode. Jeg nevnte dette problemet litt med at vi deler ressurser. Og løsningen er denne. Tenk deg at du tester på iscenesettelse. Du kan også ha en slik situasjon samtidig at noen gir ett lass, noen andre. Og som et resultat ser du beregninger som er uforståelige. Selv det samme problemet kan være med prod. Når du vil sjekke en forespørsel og du ser at det er et eller annet problem med det - det fungerer sakte, så var faktisk ikke problemet i forespørselen, men i det faktum at det er en slags parallell belastning.

Og derfor er det viktig her å fokusere på hva planen vil være, hvilke steg vi skal ta i planen og hvor mye data vi skal samle inn for dette. Det faktum at våre disker, for eksempel, vil bli lastet med noe, det vil spesifikt påvirke timingen. Men vi kan anslå hvor lastet denne forespørselen er etter mengden data. Det er ikke så viktig at det samtidig blir en form for henrettelse.

Jeg har to spørsmål. Dette er veldig kule greier. Har det vært tilfeller der produksjonsdata er kritiske, for eksempel kredittkortnumre? Er det allerede noe klart eller er det en egen oppgave? Og det andre spørsmålet - er det noe slikt for MySQL?

Om dataene. Vi vil gjøre tilsløring til vi gjør det. Men hvis du distribuerer akkurat Joe, hvis du ikke gir tilgang til utviklere, så er det ingen tilgang til dataene. Hvorfor? Fordi Joe ikke viser data. Den viser bare beregninger, planer og det er det. Dette ble gjort med vilje, fordi dette er et av kravene til vår klient. De ønsket å kunne optimalisere uten å gi alle tilgang.

Om MySQL. Dette systemet kan brukes til alt som lagrer tilstand på disk. Og siden vi driver med Postgres, gjør vi nå all automatisering for Postgres først og fremst. Vi ønsker å automatisere å hente data fra en sikkerhetskopi. Vi konfigurerer Postgres riktig. Vi vet hvordan planene skal matche osv.

Men siden systemet er utvidbart, kan det også brukes til MySQL. Og det finnes slike eksempler. Yandex har en lignende ting, men de publiserer den ikke noe sted. De bruker det inne i Yandex.Metrica. Og det er bare en historie om MySQL. Men teknologiene er de samme, ZFS.

Takk for rapporten! Jeg har også et par spørsmål. Du nevnte at kloning kan brukes til analyser, for eksempel for å bygge flere indekser der. Kan du fortelle litt mer om hvordan det fungerer?

Og jeg vil umiddelbart stille det andre spørsmålet om likheten mellom standene, likheten mellom planene. Planen avhenger også av statistikken som samles inn av Postgres. Hvordan løser du dette problemet?

Ifølge analysene er det ingen konkrete tilfeller, fordi vi ikke har brukt det ennå, men det er en slik mulighet. Hvis vi snakker om indekser, så forestill deg at en spørring jager en tabell med hundrevis av millioner poster og en kolonne som vanligvis ikke er indeksert i prod. Og vi ønsker å beregne noen data der. Hvis denne forespørselen sendes til prod, så er det en mulighet for at det blir enkelt på prod, fordi forespørselen vil bli behandlet der i et minutt.

Ok, la oss lage en tynn klone som ikke er forferdelig å stoppe i noen minutter. Og for å gjøre det mer behagelig å lese analysene, vil vi legge til indekser for de kolonnene der vi er interessert i data.

Vil indeksen opprettes hver gang?

Du kan gjøre det slik at vi berører dataene, tar øyeblikksbilder, så vil vi gjenopprette fra dette øyeblikksbildet og sende nye forespørsler. Det vil si at du kan gjøre det slik at du kan oppdra nye kloner med allerede påførte indekser.

Når det gjelder spørsmålet om statistikk, hvis vi gjenoppretter fra en sikkerhetskopi, hvis vi replikerer, vil statistikken vår være nøyaktig den samme. Fordi vi har hele den fysiske datastrukturen, det vil si at vi vil bringe dataene som de er med alle statistikkberegningene også.

Her er et annet problem. Hvis du bruker en skyløsning, er det kun logiske dumper som er tilgjengelige der, fordi Google, Amazon ikke tillater deg å ta en fysisk kopi. Det vil være et problem.

Takk for rapporten. Det var to gode spørsmål her om MySQL og ressursdeling. Men faktisk kommer alt ned til det faktum at dette ikke er et tema for spesifikke DBMS, men for filsystemet som helhet. Og følgelig bør problemene med ressursdeling også løses derfra, ikke på slutten av at det er Postgres, men i filsystemet, på serveren, for eksempel.

Spørsmålet mitt er litt annerledes. Det er nærmere den flerlags databasen, hvor det er flere lag. For eksempel setter vi opp en ti-terabyte bildeoppdatering, vi replikerer. Og vi bruker denne løsningen spesielt for databaser. Replikering pågår, data oppdateres. Det er 100 ansatte som jobber parallelt her, som stadig lanserer disse forskjellige skuddene. Hva å gjøre? Hvordan sørge for at det ikke er noen konflikt, at de lanserte en, og så endret filsystemet seg, og alle bildene forsvant?

De vil ikke gå fordi det er slik ZFS fungerer. Vi kan holde filsystemendringene som kommer på grunn av replikering separat i én tråd. Og behold klonene som utviklere bruker på eldre versjoner av dataene. Og det fungerer for oss, alt er i orden med dette.

Det viser seg at oppdateringen vil skje som et ekstra lag, og alle nye bilder vil gå allerede, basert på dette laget, ikke sant?

Fra tidligere lag som var fra tidligere replikasjoner.

De forrige lagene vil falle av, men de vil referere til det gamle laget, og vil de ta nye bilder fra det siste laget som ble mottatt i oppdateringen?

Generelt sett, ja.

Da vil vi som en konsekvens ha opptil en fiken av lag. Og over tid må de komprimeres?

Ja alt er riktig. Det er et vindu. Vi holder ukentlige øyeblikksbilder. Det kommer an på hvilken ressurs du har. Hvis du har muligheten til å lagre mye data, kan du lagre øyeblikksbilder i lang tid. De vil ikke gå bort av seg selv. Det vil ikke være datakorrupsjon. Hvis øyeblikksbildene er utdaterte, slik det ser ut for oss, det vil si at det avhenger av retningslinjene i selskapet, kan vi ganske enkelt slette dem og frigjøre plass.

Hei, takk for rapporten! Spørsmål om Joe. Du sa at kunden ikke ønsket å gi alle tilgang til dataene. Strengt tatt, hvis en person har resultatet av Explain Analyze, så kan han kikke på dataene.

Det er slik det er. For eksempel kan vi skrive: "SELECT FROM WHERE email = to that". Det vil si at vi ikke vil se selve dataene, men vi kan se noen indirekte tegn. Dette må forstås. Men på den annen side er alt der. Vi har loggrevisjon, vi har kontroll på andre kollegaer som også ser hva utviklerne gjør. Og hvis noen prøver å gjøre dette, vil sikkerhetstjenesten komme til dem og jobbe med dette problemet.

God ettermiddag Takk for rapporten! Jeg har et kort spørsmål. Hvis selskapet ikke bruker Slack, er det noen binding til det nå, eller er det mulig for utviklere å distribuere instanser for å koble en testapplikasjon til databasene?

Nå er det en lenke til Slack, det vil si at det ikke er noen annen messenger, men jeg vil virkelig støtte andre messengers også. Hva kan du gjøre? Du kan distribuere DB Lab uten Joe, gå med hjelp av REST API eller ved hjelp av plattformen vår og lage kloner og koble til med PSQL. Men dette kan gjøres hvis du er klar til å gi utviklerne dine tilgang til dataene, fordi det ikke lenger vil være noen skjerm.

Jeg trenger ikke dette laget, men jeg trenger en slik mulighet.

Så ja, det kan gjøres.

Kilde: www.habr.com