Hvordan forstår en backend-udvikler, at en SQL-forespørgsel vil fungere godt på en "prod"? I store eller hurtigt voksende virksomheder er det ikke alle, der har adgang til "produktet". Og med adgang kan ikke alle anmodninger kontrolleres smertefrit, og det tager ofte timer at oprette en kopi af databasen. For at løse disse problemer oprettede vi en kunstig DBA - Joe. Det er allerede blevet implementeret med succes i flere virksomheder og hjælper mere end et dusin udviklere.
Video:
Hej alle! Mit navn er Anatoly Stansler. Jeg arbejder for en virksomhed . Vi er forpligtet til at fremskynde udviklingsprocessen ved at fjerne forsinkelser forbundet med Postgres arbejde fra udviklere, DBA'er og QA'er.
Vi har fantastiske kunder, og i dag vil en del af rapporten blive afsat til sager, som vi mødte, mens vi arbejdede med dem. Jeg vil tale om, hvordan vi hjalp dem med at løse ganske alvorlige problemer.
Når vi udvikler og laver komplekse højbelastningsmigreringer, stiller vi os selv spørgsmålet: "Vil denne migration tage fart?". Vi bruger anmeldelse, vi bruger mere erfarne kollegaers viden, DBA-eksperter. Og de kan se, om den vil flyve eller ej.
Men måske ville det være bedre, hvis vi selv kunne teste det på kopier i fuld størrelse. Og i dag vil vi lige tale om, hvilke tilgange til test er nu, og hvordan det kan gøres bedre og med hvilke værktøjer. Vi vil også tale om fordele og ulemper ved sådanne tilgange, og hvad vi kan rette her.
Hvem har nogensinde lavet indeks direkte på prod eller foretaget ændringer? Ganske lidt af. Og for hvem førte det til, at data gik tabt, eller der var nedetid? Så kender du denne smerte. Gudskelov er der backups.
Den første tilgang er test i prod. Eller, når en udvikler sidder på en lokal maskine, han har testdata, er der en form for begrænset udvalg. Og vi ruller ud for at prode, og vi får denne situation.
Det gør ondt, det er dyrt. Det er nok bedst at lade være.
Og hvad er den bedste måde at gøre det på?
Lad os tage iscenesættelse og vælge en del af prod der. Eller i bedste fald, lad os tage en rigtig prod, alle dataene. Og efter at vi har udviklet det lokalt, vil vi desuden tjekke for iscenesættelse.
Dette vil give os mulighed for at fjerne nogle af fejlene, dvs. forhindre dem i at være på prod.
Hvad er problemerne?
- Problemet er, at vi deler denne iscenesættelse med kollegerne. Og meget ofte sker det, at man laver en eller anden form for ændring, bam - og der er ingen data, arbejdet er nede i kloakken. Staging var multi-terabyte. Og man skal vente længe på, at den rejser sig igen. Og vi beslutter at afslutte det i morgen. Det er det, vi har en udvikling.
- Og selvfølgelig har vi mange kolleger, der arbejder der, mange teams. Og det skal gøres manuelt. Og dette er ubelejligt.
Og det er værd at sige, at vi kun har et forsøg, et skud, hvis vi vil lave nogle ændringer i databasen, skal du røre ved dataene, ændre strukturen. Og hvis noget gik galt, hvis der var en fejl i migreringen, så ruller vi ikke hurtigt tilbage.
Dette er bedre end den tidligere tilgang, men der er stadig stor sandsynlighed for, at en eller anden form for fejl vil gå til produktion.
Hvad forhindrer os i at give hver udvikler en testbænk, en kopi i fuld størrelse? Jeg synes, det er tydeligt, hvad der kommer i vejen.
Hvem har en database større end en terabyte? Mere end halvdelen af rummet.
Og det er klart, at det er meget dyrt at holde maskiner for hver udvikler, når der er så stor en produktion, og desuden tager det lang tid.
Vi har kunder, der har indset, at det er meget vigtigt at teste alle ændringer på kopier i fuld størrelse, men deres database er mindre end en terabyte, og der er ingen ressourcer til at holde en testbænk for hver udvikler. Derfor skal de downloade dumpene lokalt til deres maskine og teste på denne måde. Det tager meget tid.
Selvom du gør det inde i infrastrukturen, så er det allerede meget godt at downloade en terabyte data i timen. Men de bruger logiske dumps, de downloader lokalt fra skyen. For dem er hastigheden omkring 200 gigabyte i timen. Og det tager stadig tid at vende om fra det logiske dump, rulle indekserne op osv.
Men de bruger denne tilgang, fordi den giver dem mulighed for at holde proden pålidelig.
Hvad kan vi gøre her? Lad os gøre testbænke billige og give hver udvikler deres egen testbænk.
Og det er muligt.
Og i denne tilgang, når vi laver tynde kloner for hver udvikler, kan vi dele det på én maskine. For eksempel, hvis du har en 10TB database og vil give den til 10 udviklere, behøver du ikke have XNUMX x XNUMXTB databaser. Du behøver kun én maskine til at lave tynde isolerede kopier for hver udvikler ved hjælp af én maskine. Jeg fortæller dig, hvordan det virker lidt senere.
Rigtigt eksempel:
DB - 4,5 terabyte.
Vi kan få uafhængige kopier på 30 sekunder.
Du behøver ikke vente på en teststand og afhænger af, hvor stor den er. Du kan få det på få sekunder. Det vil være fuldstændig isolerede miljøer, men som deler data indbyrdes.
Dette er godt. Her taler vi om magi og et parallelunivers.
I vores tilfælde fungerer dette ved hjælp af OpenZFS-systemet.
OpenZFS er et kopi-på-skriv-filsystem, der understøtter snapshots og kloner ud af boksen. Det er pålideligt og skalerbart. Hun er meget nem at administrere. Det kan bogstaveligt talt implementeres i to hold.
Der er andre muligheder:
lvm,
Opbevaring (for eksempel Pure Storage).
Database Lab, jeg taler om, er modulopbygget. Kan implementeres ved hjælp af disse muligheder. Men indtil videre har vi fokuseret på OpenZFS, fordi der var problemer med LVM specifikt.
Hvordan det virker? I stedet for at overskrive dataene hver gang vi ændrer dem, gemmer vi dem ved blot at markere, at disse nye data er fra et nyt tidspunkt, et nyt øjebliksbillede.
Og i fremtiden, når vi ønsker at rulle tilbage, eller vi vil lave en ny klon fra en ældre version, siger vi bare: "OK, giv os disse datablokke, der er markeret som denne."
Og denne bruger vil arbejde med et sådant datasæt. Han vil gradvist ændre dem, lave sine egne snapshots.
Og vi vil forgrene. Hver udvikler i vores tilfælde vil have mulighed for at have sin egen klon, som han redigerer, og de data, der deles, vil blive delt mellem alle.
For at implementere et sådant system derhjemme skal du løse to problemer:
Den første er kilden til dataene, hvor du vil tage dem fra. Du kan opsætte replikering med produktion. Du kan allerede nu bruge de sikkerhedskopier, du har konfigureret, håber jeg. WAL-E, WAL-G eller Barman. Og selvom du bruger en form for Cloud-løsning som RDS eller Cloud SQL, så kan du bruge logiske dumps. Men vi råder dig stadig til at bruge sikkerhedskopier, for med denne tilgang vil du også bevare den fysiske struktur af filerne, hvilket vil give dig mulighed for at være endnu tættere på de målinger, du ville se i produktionen for at fange de problemer, der eksisterer.
Det andet er, hvor du vil være vært for databaselaben. Det kunne være Cloud, det kunne være On-premise. Det er vigtigt at sige her, at ZFS understøtter datakomprimering. Og det gør det ret godt.
Forestil dig, at for hver sådan klon, afhængigt af de operationer, vi udfører med basen, vil en form for dev vokse. Til dette har dev også brug for plads. Men på grund af det faktum, at vi tog en base på 4,5 terabyte, vil ZFS komprimere den til 3,5 terabyte. Dette kan variere afhængigt af indstillingerne. Og vi har stadig plads til dev.
Et sådant system kan bruges til forskellige sager.
Disse er udviklere, DBA'er til forespørgselsvalidering, til optimering.
Dette kan bruges i QA-test til at teste en bestemt migration, før vi ruller den ud til prod. Og vi kan også rejse specielle miljøer til QA med rigtige data, hvor de kan teste ny funktionalitet. Og det vil tage sekunder i stedet for at vente timer, og måske dage i nogle andre tilfælde, hvor der ikke bruges tynde kopier.
Og en anden sag. Hvis virksomheden ikke har et analysesystem opsat, så kan vi isolere en tynd klon af produktbasen og give den til lange forespørgsler eller specielle indekser, der kan bruges i analyser.
Med denne tilgang:
Lav sandsynlighed for fejl på "prod", fordi vi testede alle ændringerne på data i fuld størrelse.
Vi har en testkultur, for nu skal du ikke vente i timevis på din egen stand.
Og der er ingen barriere, ingen ventetid mellem prøverne. Du kan faktisk gå og tjekke. Og det bliver bedre på denne måde, når vi fremskynder udviklingen.
Der vil være mindre refaktorering. Færre fejl vil ende i prod. Vi refaktorerer dem mindre senere.
Vi kan vende irreversible ændringer. Dette er ikke standardmetoden.
- Dette er fordelagtigt, fordi vi deler ressourcerne fra testbænkene.
Allerede godt, men hvad kunne ellers fremskyndes?
Takket være et sådant system kan vi i høj grad reducere tærsklen for at gå ind i en sådan test.
Nu er der en ond cirkel, når en udvikler, for at få adgang til rigtige data i fuld størrelse, skal blive ekspert. Han skal have tillid til en sådan adgang.
Men hvordan vokser man, hvis den ikke er der. Men hvad nu hvis du kun har et meget lille sæt testdata til rådighed for dig? Så får du ingen reel oplevelse.
Hvordan kommer man ud af denne cirkel? Som den første grænseflade, praktisk for udviklere på ethvert niveau, valgte vi Slack-bot. Men det kan være en hvilken som helst anden grænseflade.
Hvad giver det dig mulighed for? Du kan tage en specifik forespørgsel og sende den til en speciel kanal til databasen. Vi vil automatisk implementere en tynd klon på få sekunder. Lad os køre denne anmodning. Vi indsamler metrics og anbefalinger. Lad os vise en visualisering. Og så forbliver denne klon, så denne forespørgsel på en eller anden måde kan optimeres, tilføje indekser osv.
Og også Slack giver os muligheder for samarbejde ud af boksen. Da dette kun er en kanal, kan du begynde at diskutere denne anmodning lige der i tråden for sådan en anmodning, ping dine kollegaer, DBA'er, der er inde i virksomheden.
Men der er selvfølgelig problemer. Fordi dette er den virkelige verden, og vi bruger en server, der hoster mange kloner på én gang, er vi nødt til at komprimere mængden af hukommelse og CPU-kraft, der er tilgængelig for klonerne.
Men for at disse test skal være plausible, skal du på en eller anden måde løse dette problem.
Det er klart, at det vigtige punkt er de samme data. Men vi har det allerede. Og vi ønsker at opnå den samme konfiguration. Og vi kan give sådan en næsten identisk konfiguration.
Det ville være fedt at have samme hardware som i produktionen, men det kan være forskelligt.
Lad os huske, hvordan Postgres arbejder med hukommelse. Vi har to cacher. En fra filsystemet og en native Postgres, dvs. Shared Buffer Cache.
Det er vigtigt at bemærke, at Shared Buffer Cache tildeles, når Postgres starter, afhængigt af hvilken størrelse du angiver i konfigurationen.
Og den anden cache bruger al tilgængelig plads.
Og når vi laver flere kloner på én maskine, viser det sig, at vi gradvist fylder hukommelsen. Og på en god måde er Shared Buffer Cache 25 % af den samlede mængde hukommelse, der er tilgængelig på maskinen.
Og det viser sig, at hvis vi ikke ændrer denne parameter, vil vi kun være i stand til at køre 4 forekomster på én maskine, dvs. 4 af alle sådanne tynde kloner. Og det er selvfølgelig dårligt, for dem vil vi gerne have meget flere af.
Men på den anden side bruges Buffer Cache til at udføre forespørgsler til indekser, det vil sige at planen afhænger af hvor store vores caches er. Og hvis vi bare tager denne parameter og reducerer den, så kan vores planer ændre meget.
For eksempel, hvis vi har en stor cache på prod, så vil Postgres foretrække at bruge et indeks. Og hvis ikke, så vil der være SeqScan. Og hvad ville være meningen, hvis vores planer ikke faldt sammen?
Men her kommer vi til den konklusion, at planen i Postgres faktisk ikke afhænger af den specifikke størrelse, der er angivet i Shared Buffer i planen, den afhænger af effective_cache_size.
Effective_cache_size er den estimerede mængde cache, der er tilgængelig for os, dvs. summen af Buffer Cache og filsystemcache. Dette er indstillet af config. Og denne hukommelse er ikke tildelt.
Og på grund af denne parameter kan vi på en måde narre Postgres og sige, at vi faktisk har mange data til rådighed, selvom vi ikke har disse data. Og dermed vil planerne falde fuldstændig sammen med produktionen.
Men dette kan påvirke timingen. Og vi optimerer forespørgsler efter timing, men det er vigtigt, at timing afhænger af mange faktorer:
Det afhænger af den belastning, der i øjeblikket er på prod.
Det afhænger af selve maskinens egenskaber.
Og dette er en indirekte parameter, men faktisk kan vi optimere nøjagtigt efter mængden af data, som denne forespørgsel vil læse for at få resultatet.
Og hvis du vil have timingen tæt på det, vi vil se i prod, så skal vi tage den mest lignende hardware og muligvis endnu mere, så alle klonerne passer. Men dette er et kompromis, dvs. du vil få de samme planer, du vil se, hvor meget data en bestemt forespørgsel vil læse, og du vil være i stand til at konkludere, om denne forespørgsel er god (eller migration) eller dårlig, den skal stadig optimeres .
Lad os tage et kig på, hvordan Joe specifikt er optimeret.
Lad os tage en anmodning fra et rigtigt system. I dette tilfælde er databasen 1 terabyte. Og vi vil tælle antallet af friske opslag, der havde mere end 10 likes.
Vi skriver en besked til kanalen, en klon er blevet indsat for os. Og vi vil se, at en sådan anmodning vil gennemføres på 2,5 minutter. Det er det første, vi bemærker.
B Joe vil vise dig automatiske anbefalinger baseret på planen og metrics.
Vi vil se, at forespørgslen behandler for meget data til at få et relativt lille antal rækker. Og en form for specialiseret indeks er nødvendig, da vi har bemærket, at der er for mange filtrerede rækker i forespørgslen.
Lad os se nærmere på, hvad der skete. Faktisk ser vi, at vi har læst næsten halvanden gigabyte data fra filcachen eller endda fra disken. Og det er ikke godt, for vi har kun 142 linjer.
Og det ser ud til, at vi har en indeksscanning her og burde have fungeret hurtigt, men da vi filtrerede for mange linjer fra (vi var nødt til at tælle dem), lykkedes anmodningen langsomt.
Og det skete i planen på grund af, at betingelserne i forespørgslen og betingelserne i indekset delvist ikke stemmer overens.
Lad os prøve at gøre indekset mere præcist og se, hvordan forespørgselsudførelsen ændres derefter.
Oprettelsen af indekset tog ret lang tid, men nu tjekker vi forespørgslen og ser, at tiden i stedet for 2,5 minutter kun er 156 millisekunder, hvilket er godt nok. Og vi læser kun 6 megabyte data.
Og nu bruger vi kun indeksscanning.
En anden vigtig historie er, at vi gerne vil præsentere planen på en mere forståelig måde. Vi har implementeret visualisering ved hjælp af Flame Graphs.
Dette er en anden anmodning, mere intens. Og vi bygger Flame Graphs i henhold til to parametre: dette er mængden af data, som en bestemt node talte i planen og timingen, dvs. udførelsestiden for noden.
Her kan vi sammenligne specifikke noder med hinanden. Og det vil være klart, hvilken af dem der tager mere eller mindre, hvilket normalt er svært at gøre i andre renderingsmetoder.
Selvfølgelig kender alle explain.depesz.com. En god funktion ved denne visualisering er, at vi gemmer tekstplanen og også lægger nogle grundlæggende parametre ind i en tabel, så vi kan sortere.
Og udviklere, der endnu ikke har dykket ned i dette emne, bruger også explain.depesz.com, fordi det er nemmere for dem at finde ud af, hvilke metrics der er vigtige, og hvilke der ikke er.
Der er en ny tilgang til visualisering - dette er explain.dalibo.com. De laver en trævisualisering, men det er meget svært at sammenligne noder med hinanden. Her kan du godt forstå strukturen, men hvis der er en stor anmodning, så skal du scrolle frem og tilbage, men også en mulighed.
Коллаборация
Og som sagt giver Slack os muligheden for at samarbejde. For eksempel, hvis vi støder på en kompleks forespørgsel, der ikke er klar over, hvordan man optimerer, kan vi afklare dette problem med vores kolleger i en tråd i Slack.
Det forekommer os, at det er vigtigt at teste på data i fuld størrelse. For at gøre dette lavede vi værktøjet Update Database Lab, som er tilgængeligt i open source. Du kan også bruge Joe-bot. Du kan tage det lige nu og implementere det hos dig. Alle guider er tilgængelige der.
Det er også vigtigt at bemærke, at selve løsningen ikke er revolutionerende, for der er Delphix, men det er en virksomhedsløsning. Det er helt lukket, det er meget dyrt. Vi specialiserer os specifikt i Postgres. Disse er alle open source-produkter. Kom med os!
Det er her jeg slutter. Tak skal du have!
R'RѕRїSЂRѕSЃS <
Hej! Tak for rapporten! Meget interessant, især for mig, fordi jeg løste det samme problem for noget tid siden. Og så har jeg en række spørgsmål. Forhåbentlig får jeg i det mindste en del af det.
Jeg spekulerer på, hvordan du beregner stedet for dette miljø? Teknologien betyder, at dine kloner under visse omstændigheder kan vokse til den maksimale størrelse. Groft sagt, hvis du har en ti terabyte database og 10 kloner, så er det nemt at simulere en situation, hvor hver klon vejer 10 unikke data. Hvordan beregner du dette sted, det vil sige det delta, som du talte om, hvor disse kloner vil leve?
Godt spørgsmål. Det er vigtigt at holde styr på specifikke kloner her. Og hvis en klon har en for stor ændring, begynder den at vokse, så kan vi først udsende en advarsel til brugeren om dette, eller straks stoppe denne klon, så vi ikke har en fejlsituation.
Ja, jeg har et indlejret spørgsmål. Det vil sige, hvordan sikrer man disse modulers livscyklus? Vi har dette problem og en hel separat historie. Hvordan sker dette?
Der er noget ttl for hver klon. Som udgangspunkt har vi en fast ttl.
Hvad, hvis ikke en hemmelighed?
1 time, dvs. tomgang - 1 time. Hvis den ikke bliver brugt, så knalder vi den. Men der er ingen overraskelse her, da vi kan hæve klonen på få sekunder. Og hvis du har brug for det igen, så tak.
Jeg er også interesseret i valget af teknologier, fordi vi for eksempel af den ene eller anden grund bruger flere metoder parallelt. Hvorfor ZFS? Hvorfor brugte du ikke LVM? Du nævnte, at der var problemer med LVM. Hvad var problemerne? Efter min mening er den mest optimale mulighed med opbevaring, hvad angår ydeevne.
Hvad er hovedproblemet med ZFS? Det faktum, at du skal køre på den samme vært, dvs. alle instanser vil leve inden for det samme OS. Og i tilfælde af opbevaring kan du tilslutte forskelligt udstyr. Og flaskehalsen er kun de blokke, der er på lagersystemet. Og spørgsmålet om valget af teknologier er interessant. Hvorfor ikke LVM?
Vi kan diskutere LVM specifikt på mødet. Hvad angår storage, er det bare dyrt. Vi kan implementere ZFS hvor som helst. Du kan implementere det på din maskine. Du kan blot downloade repository'et og implementere det. ZFS kan installeres næsten hvor som helst, hvis vi taler om Linux Vi taler om det. Så vi får en meget fleksibel løsning. Og ZFS tilbyder i sig selv meget lige fra starten. Du kan indlæse så mange data i det, som du vil, tilslutte et stort antal diske, og det har snapshots. Og som jeg allerede sagde, er det nemt at administrere. Så det virker meget behageligt at bruge. Det er bevist, det har eksisteret i mange år. Det har et meget stort fællesskab, der vokser. ZFS er en meget pålidelig løsning.
Nikolai Samokhvalov: Må jeg kommentere yderligere? Mit navn er Nikolay, vi arbejder sammen med Anatoly. Jeg er enig i, at opbevaring er fantastisk. Og nogle af vores kunder har Pure Storage mm.
Anatoly bemærkede korrekt, at vi er fokuseret på modularitet. Og i fremtiden kan du implementere én grænseflade - tag et øjebliksbillede, lav en klon, ødelægge klonen. Det hele er nemt. Og opbevaring er cool, hvis det er.
Men ZFS er tilgængelig for alle. DelPhix er allerede nok, de har 300 kunder. Heraf har Fortune 100 50 kunder, dvs. de er rettet mod NASA osv. Det er på tide, at alle får denne teknologi. Og det er derfor, vi har en open source-kerne. Vi har en grænsefladedel, der ikke er open source. Dette er platformen, som vi vil vise. Men vi ønsker, at det skal være tilgængeligt for alle. Vi vil lave en revolution, så alle testere holder op med at gætte på bærbare computere. Vi skal skrive SELECT og straks se, at det er langsomt. Lad være med at vente på, at DBA fortæller dig om det. Her er hovedmålet. Og jeg tror, at vi alle kommer til det her. Og vi laver denne ting til alle. Derfor ZFS, fordi den vil være tilgængelig overalt. Tak til fællesskabet for at løse problemer og for at have en open source-licens osv.*
Vær hilset! Tak for rapporten! Mit navn er Maxim. Vi har beskæftiget os med de samme problemer. De besluttede sig selv. Hvordan deler du ressourcer mellem disse kloner? Hver klon kan gøre sin egen ting til enhver tid: en tester én ting, en anden en anden, nogen bygger et indeks, nogen har et tungt job. Og hvis du stadig kan dividere med CPU, så med IO, hvordan dividerer du? Dette er det første spørgsmål.
Og det andet spørgsmål handler om tribunernes ulighed. Lad os sige, at jeg har ZFS her og alt er fedt, men klienten på prod har ikke ZFS, men ext4, for eksempel. Hvordan i dette tilfælde?
Spørgsmålene er meget gode. Jeg nævnte dette problem lidt med, at vi deler ressourcer. Og løsningen er denne. Forestil dig, at du tester på iscenesættelse. Man kan også have sådan en situation samtidig med, at nogen giver et læs, en anden. Og som et resultat ser du uforståelige målinger. Selv samme problem kan være med prod. Når du vil tjekke en forespørgsel og se, at der er et eller andet problem med det - det virker langsomt, så lå problemet faktisk ikke i forespørgslen, men i det faktum, at der er en form for parallel belastning.
Og derfor er det her vigtigt at fokusere på, hvad planen bliver, hvilke skridt vi vil tage i planen, og hvor meget data vi vil indsamle til dette. Det, at vores diske for eksempel vil blive fyldt med noget, det vil specifikt påvirke timingen. Men vi kan vurdere, hvor indlæst denne anmodning er ved mængden af data. Det er ikke så vigtigt, at der samtidig kommer en form for henrettelse.
Jeg har to spørgsmål. Det er meget seje ting. Har der været tilfælde, hvor produktionsdata er kritiske, såsom kreditkortnumre? Er der allerede noget klar eller er det en separat opgave? Og det andet spørgsmål - er der noget lignende til MySQL?
Om data. Vi vil gøre sløring indtil vi gør det. Men hvis du implementerer præcis Joe, hvis du ikke giver adgang til udviklere, så er der ingen adgang til dataene. Hvorfor? Fordi Joe ikke viser data. Det viser kun målinger, planer og det er det. Dette blev gjort med vilje, fordi dette er et af kravene fra vores klient. De ønskede at kunne optimere uden at give alle adgang.
Om MySQL. Dette system kan bruges til alt, der gemmer tilstand på disken. Og da vi laver Postgres, laver vi nu al automatiseringen til Postgres først. Vi ønsker at automatisere at få data fra en sikkerhedskopi. Vi konfigurerer Postgres korrekt. Vi ved, hvordan man får planer til at matche osv.
Men da systemet er udvidbart, kan det også bruges til MySQL. Og der er sådanne eksempler. Yandex har en lignende ting, men de udgiver det ikke nogen steder. De bruger det inde i Yandex.Metrica. Og der er bare en historie om MySQL. Men teknologierne er de samme, ZFS.
Tak for rapporten! Jeg har også et par spørgsmål. Du nævnte, at kloning kan bruges til analyser, for eksempel til at bygge yderligere indekser der. Kan du fortælle lidt mere om, hvordan det fungerer?
Og jeg vil straks stille det andet spørgsmål om ligheden mellem standene, ligheden i planerne. Planen afhænger også af den statistik, som Postgres indsamler. Hvordan løser du dette problem?
Ifølge analysen er der ingen konkrete sager, for vi har ikke brugt det endnu, men sådan en mulighed er der. Hvis vi taler om indekser, så forestil dig, at en forespørgsel jager en tabel med hundreder af millioner af poster og en kolonne, der normalt ikke er indekseret i prod. Og vi vil gerne beregne nogle data der. Hvis denne anmodning køres på prod, så er der mulighed for, at den bliver simpel på prod, fordi anmodningen vil blive behandlet der i et minut.
Ok, lad os lave en tynd klon, der ikke er forfærdelig at stoppe i et par minutter. Og for at gøre det mere behageligt at læse analyserne, tilføjer vi indekser for de kolonner, hvor vi er interesserede i data.
Vil indekset blive oprettet hver gang?
Du kan gøre det sådan, at vi rører ved dataene, laver snapshots, så vil vi gendanne fra dette snapshot og køre nye anmodninger. Det vil sige, at du kan gøre det, så du kan rejse nye kloner med allerede påsatte indekser.
Med hensyn til spørgsmålet om statistik, hvis vi gendanner fra en sikkerhedskopi, hvis vi replikerer, så vil vores statistik være nøjagtig den samme. Fordi vi har hele den fysiske datastruktur, det vil sige, at vi også bringer dataene, som de er med alle statistik-metrics.
Her er et andet problem. Hvis du bruger en cloud-løsning, så er der kun logiske dumps tilgængelige der, fordi Google, Amazon ikke tillader dig at tage en fysisk kopi. Der vil være et problem.
Tak for præsentationen. Der blev rejst to gode spørgsmål her om MySQL og ressourcedeling. Men i bund og grund handler det hele om, at dette ikke er et emne for specifikke databasestyrede systemstyringssystemer, men for filsystemet som helhed. Og derfor bør problemer med ressourcedeling også løses derfra, ikke kun i Postgres, men i selve filsystemet. server, for eksempel.
Mit spørgsmål er lidt anderledes. Det er tættere på den flerlagede database, hvor der er flere lag. For eksempel sætter vi en ti-terabyte billedopdatering op, vi replikerer. Og vi bruger specifikt denne løsning til databaser. Replikering er i gang, data opdateres. Der arbejder 100 medarbejdere parallelt, som konstant lancerer disse forskellige skud. Hvad skal man gøre? Hvordan sikrer man sig, at der ikke er nogen konflikt, at de lancerede en, og så ændrede filsystemet sig, og disse billeder gik alle sammen?
De vil ikke gå, fordi det er sådan ZFS fungerer. Vi kan holde de filsystemændringer, der kommer på grund af replikering, separat i én tråd. Og behold de kloner, som udviklere bruger, på ældre versioner af dataene. Og det virker for os, alt er i orden med dette.
Det viser sig, at opdateringen vil finde sted som et ekstra lag, og alle nye billeder vil gå allerede, baseret på dette lag, ikke?
Fra tidligere lag, der var fra tidligere replikationer.
De tidligere lag vil falde af, men de vil referere til det gamle lag, og vil de tage nye billeder fra det sidste lag, der blev modtaget i opdateringen?
Generelt, ja.
Så som en konsekvens vil vi have op til en figen af lag. Og med tiden skal de komprimeres?
Ja alt er korrekt. Der er et vindue. Vi holder ugentlige snapshots. Det afhænger af, hvilken ressource du har. Hvis du har mulighed for at gemme en masse data, kan du gemme snapshots i lang tid. De vil ikke gå væk af sig selv. Der vil ikke være nogen datakorruption. Hvis snapshots er forældede, som det forekommer os, det vil sige at det afhænger af politikken i virksomheden, så kan vi blot slette dem og frigøre plads.
Hej, tak for rapporten! Spørgsmål om Joe. Du sagde, at kunden ikke ønskede at give alle adgang til dataene. Strengt taget, hvis en person har resultatet af Explain Analyse, så kan han kigge på dataene.
Sådan er det. For eksempel kan vi skrive: "SELECT FROM WHERE email = to that". Det vil sige, at vi ikke vil se selve dataene, men vi kan se nogle indirekte tegn. Dette skal forstås. Men på den anden side er det hele der. Vi har logrevision, vi har styr på andre kollegaer, som også ser, hvad udviklerne laver. Og hvis nogen forsøger at gøre dette, så vil sikkerhedstjenesten komme til dem og arbejde på dette spørgsmål.
God eftermiddag Tak for rapporten! Jeg har et kort spørgsmål. Hvis virksomheden ikke bruger Slack, er der så nogen binding til det nu, eller er det muligt for udviklere at implementere instanser for at forbinde en testapplikation til databaserne?
Nu er der et link til Slack, dvs. der er ingen anden messenger, men jeg vil virkelig også lave support til andre messengers. Hvad kan du gøre? Du kan implementere DB Lab uden Joe, gå ved hjælp af REST API eller ved hjælp af vores platform og oprette kloner og oprette forbindelse til PSQL. Men det kan lade sig gøre, hvis du er klar til at give dine udviklere adgang til dataene, for der vil ikke længere være nogen skærm.
Jeg har ikke brug for dette lag, men jeg har brug for sådan en mulighed.
Så ja, det kan lade sig gøre.
Kilde: www.habr.com
