En gang i en fjern fremtid vil automatisk fjerning av unødvendige data være en av de viktige oppgavene til DBMS [1]. I mellomtiden må vi selv sørge for å slette eller flytte unødvendige data til rimeligere lagringssystemer. La oss si at du bestemmer deg for å slette noen millioner rader. En ganske enkel oppgave, spesielt hvis tilstanden er kjent og det er en passende indeks. "DELETE FROM table1 WHERE col1 = :value" - hva kan være enklere, ikke sant?
Video:
-
Jeg har vært i Highload-programkomiteen siden det første året, det vil si siden 2007.
-
Og jeg har vært med Postgres siden 2005. Har brukt det i mange prosjekter.
-
Gruppe med RuPostges også siden 2007.
-
Vi har vokst til 2100+ deltakere på Meetup. Den er nummer to i verden etter New York, forbigått av San Francisco i lang tid.
-
Jeg har bodd i California i flere år. Jeg driver mer med amerikanske selskaper, inkludert store. De er aktive brukere av Postgres. Og det er alle slags interessante ting.
er mitt selskap. Vi driver med automatisering av oppgaver som eliminerer utviklingsbremser.
Hvis du gjør noe, så er det noen ganger noen slags plugger rundt Postgres. La oss si at du må vente på at administratoren setter opp en teststand for deg, eller at du må vente på at DBA svarer deg. Og vi finner slike flaskehalser i utviklings-, test- og administrasjonsprosessen og prøver å eliminere dem ved hjelp av automatisering og nye tilnærminger.
Jeg var nylig på VLDB i Los Angeles. Dette er den største konferansen om databaser. Og det var en rapport om at DBMS i fremtiden ikke bare vil lagre, men også automatisk slette data. Dette er et nytt tema.
Det er mer og mer data i zettabytes verden - det er 1 000 000 petabyte. Og nå er det allerede anslått at vi har mer enn 100 zettabyte med data lagret i verden. Og det blir flere og flere av dem.
Og hva skal man gjøre med det? Det er klart at det må fjernes. Her er en lenke til denne interessante rapporten. Men så langt er ikke dette implementert i DBMS.
De som kan telle penger vil ha to ting. De vil at vi skal slette, så teknisk sett burde vi kunne gjøre det.
Det jeg skal fortelle videre er en abstrakt situasjon som inkluderer en haug med virkelige situasjoner, dvs. en slags sammenstilling av hva som faktisk skjedde med meg og de omkringliggende databasene mange ganger, mange år. Raker er overalt og alle tråkker på dem hele tiden.
La oss si at vi har en base eller flere baser som vokser. Og noen plater er åpenbart søppel. For eksempel begynte brukeren å gjøre noe der, men fullførte det ikke. Og etter en tid vet vi at dette uferdige ikke lenger kan lagres. Det vil si at vi ønsker å rydde noen søppelting for å spare plass, forbedre ytelsen osv.
Generelt er oppgaven å automatisere sletting av spesifikke ting, spesifikke linjer i en tabell.
Og vi har en slik forespørsel, som vi skal snakke om i dag, det vil si om søppelfjerning.
Vi ba en erfaren utvikler om å gjøre det. Han tok denne forespørselen, sjekket den selv - alt fungerer. Testet på oppsetning - alt er i orden. Rullet ut - alt fungerer. En gang om dagen kjører vi det - alt er bra.
Databasen vokser og vokser. Daily DELETE begynner å fungere litt saktere.
Da forstår vi at vi nå har et markedsføringsselskap og trafikken blir flere ganger større, så vi bestemmer oss for å midlertidig pause unødvendige ting. Og glem å returnere.
Noen måneder senere husket de. Og den utvikleren sluttet eller er opptatt med noe annet, instruerte en annen om å returnere den.
Han sjekket på utvikler, på iscenesettelse - alt er OK. Naturligvis må du fortsatt rydde opp i det som har samlet seg. Han sjekket at alt fungerer.
Hva skjer etterpå? Da faller alt fra hverandre for oss. Det faller slik at alt på et tidspunkt faller ned. Alle er i sjokk, ingen forstår hva som skjer. Og så viser det seg at saken lå i denne SLETT.
Noe gikk galt? Her er en liste over hva som kan ha gått galt. Hvilken av disse er den viktigste?
-
For eksempel var det ingen anmeldelse, det vil si at DBA-eksperten ikke så på den. Han ville umiddelbart finne problemet med et erfarent øye, og dessuten har han tilgang til prod, der flere millioner linjer har samlet seg.
-
Kanskje de sjekket noe galt.
-
Kanskje maskinvaren er utdatert og du må oppgradere denne basen.
-
Eller noe er galt med selve databasen, og vi må flytte fra Postgres til MySQL.
-
Eller kanskje det er noe galt med operasjonen.
-
Kanskje det er noen feil i organiseringen av arbeidet og du trenger å sparke noen og ansette de beste folkene?
Det var ingen DBA-sjekk. Hvis det fantes en DBA, ville han se disse flere millioner linjene, og selv uten noen eksperimenter ville han si: "Det gjør de ikke." Anta at hvis denne koden var i GitLab, GitHub og det ville være en kodegjennomgangsprosess og det ikke var noe slikt at uten godkjenning fra DBA ville denne operasjonen finne sted på prod, så ville åpenbart DBA si: "Dette kan ikke gjøres ."
Og han ville si at du vil ha problemer med disk-IO og alle prosesser vil gå gale, det kan være låser, og du vil også blokkere autovakuum i en haug med minutter, så dette er ikke bra.
Den andre feilen - de sjekket på feil sted. Vi så etter det faktum at mye søppeldata samlet seg på prod, men utvikleren hadde ikke akkumulert data i denne databasen, og ingen opprettet dette søppelet under iscenesettelsen. Følgelig var det 1 linjer som raskt ordnet seg.
Vi forstår at testene våre er svake, det vil si at prosessen som bygges ikke fanger opp problemer. Et tilstrekkelig DB-eksperiment ble ikke utført.
Et ideelt eksperiment utføres fortrinnsvis på samme utstyr. Det er ikke alltid mulig å gjøre dette på samme utstyr, men det er veldig viktig at det er en kopi av databasen i full størrelse. Det er dette jeg har forkynt i flere år nå. Og for et år siden snakket jeg om dette, du kan se alt på YouTube.
Kanskje utstyret vårt er dårlig? Hvis du ser, så hoppet ventetiden. Vi har sett at utnyttelsen er 100 %. Selvfølgelig, hvis dette var moderne NVMe-stasjoner, ville det sannsynligvis vært mye enklere for oss. Og kanskje ville vi ikke legge oss fra det.
Hvis du har skyer, er oppgraderingen enkelt gjort der. Opprettet nye replikaer på den nye maskinvaren. bytte over. Og alt er bra. Ganske enkelt.
Er det mulig å berøre de mindre diskene på en eller annen måte? Og her, bare ved hjelp av DBA, dykker vi inn i et bestemt emne som kalles sjekkpunktinnstilling. Det viser seg at vi ikke hadde sjekkpunkttuning.
Hva er sjekkpunkt? Det er i alle DBMS. Når du har data i minnet som endres, blir det ikke umiddelbart skrevet til disk. Informasjonen om at dataene er endret blir først skrevet til fremskrivningsloggen. Og på et tidspunkt bestemmer DBMS at det er på tide å dumpe ekte sider til disken, slik at hvis vi har en feil, kan vi gjøre mindre GJØRING. Det er som et leketøy. Hvis vi blir drept, starter vi spillet fra siste sjekkpunkt. Og alle DBMS implementerer det.
Innstillingene i Postgres henger etter. De er designet for 10-15 år gamle data- og transaksjonsvolumer. Og sjekkpunkt er intet unntak.
Her er informasjonen fra vår Postgres-sjekkrapport, det vil si automatisk helsesjekk. Og her er en database med flere terabyte. Og det kan godt sees at tvungne sjekkpunkter i nesten 90 % av tilfellene.
Hva betyr det? Det er to innstillinger der. Sjekkpunkt kan komme etter timeout, for eksempel på 10 minutter. Eller det kan komme når ganske mye data er fylt ut.
Og som standard er max_wal_saze satt til 1 gigabyte. Faktisk skjer dette virkelig i Postgres etter 300-400 megabyte. Du har endret så mye data og sjekkpunktet ditt skjer.
Og hvis ingen stilte den, og tjenesten vokste, og selskapet tjener mye penger, har det mange transaksjoner, så kommer sjekkpunktet en gang i minuttet, noen ganger hvert 30. sekund, og noen ganger til og med overlapper. Dette er ganske dårlig.
Og vi må sørge for at det kommer sjeldnere. Det vil si at vi kan heve max_wal_size. Og det vil komme sjeldnere.
Men vi har utviklet en hel metodikk for hvordan man gjør det mer riktig, det vil si hvordan man tar en beslutning om valg av innstillinger, tydelig basert på spesifikke data.
Følgelig gjør vi to serier med eksperimenter på databaser.
Den første serien - vi endrer max_wal_size. Og vi gjør en massiv operasjon. Først gjør vi det på standardinnstillingen på 1 gigabyte. Og vi gjør en massiv SLETT av mange millioner linjer.
Du kan se hvor vanskelig det er for oss. Vi ser at disk IO er veldig dårlig. Vi ser på hvor mange WALer vi har generert, fordi dette er veldig viktig. La oss se hvor mange ganger sjekkpunktet skjedde. Og vi ser at det ikke er bra.
Deretter øker vi max_wal_size. Vi gjentar. Vi øker, vi gjentar. Og så mange ganger. I prinsippet er 10 poeng bra, der 1, 2, 4, 8 gigabyte. Og vi ser på oppførselen til et bestemt system. Det er klart at her skal utstyret være som på prod. Du må ha de samme diskene, samme mengde minne og de samme Postgres-innstillingene.
Og på denne måten vil vi bytte ut systemet vårt, og vi vet hvordan DBMS vil oppføre seg i tilfelle en dårlig masse SLETT, hvordan det vil kontrollere.
Sjekkpunkt på russisk er sjekkpunkter.
Eksempel: SLETT flere millioner rader etter indeks, rader er "spredt" over sidene.
Her er et eksempel. Dette er en base. Og med standardinnstillingen på 1 gigabyte for max_wal_size, er det veldig tydelig at diskene våre går til hyllen for opptak. Dette bildet er et typisk symptom på en veldig syk pasient, det vil si at han virkelig følte seg dårlig. Og det var én enkelt operasjon, det var bare en SLETT på flere millioner linjer.
Hvis en slik operasjon tillates i prod, så legger vi oss bare, for det er klart at en SLETT dreper oss i regimentet.
Videre, hvor 16 gigabyte, er det klart at tennene allerede har gått. Tennene er allerede bedre, det vil si at vi banker i taket, men ikke så ille. Det var litt frihet der. Til høyre er posten. Og antall operasjoner - den andre grafen. Og det er tydelig at vi allerede puster litt lettere når 16 gigabyte.
Og hvor 64 gigabyte kan ses at det har blitt helt bedre. Allerede tennene er uttalt, det er flere muligheter til å overleve andre operasjoner og gjøre noe med disken.
Hvorfor så?
Jeg vil dykke ned i detaljene litt, men dette emnet, hvordan du utfører sjekkpunktinnstilling, kan resultere i en hel rapport, så jeg vil ikke laste mye, men jeg vil skissere litt hvilke vanskeligheter det er.
Hvis sjekkpunktet skjer for ofte, og vi oppdaterer linjene våre ikke sekvensielt, men finner etter indeks, noe som er bra, fordi vi ikke sletter hele tabellen, kan det hende at vi først rørte på den første siden, deretter den tusende, og så tilbake til den første. Og hvis mellom disse besøkene på den første siden, checkpoint allerede har lagret den på disk, vil den lagre den igjen, fordi vi har blitt skitten en gang til.
Og vi vil tvinge sjekkpunkt til å redde det mange ganger. Hvordan ville det være overflødige operasjoner for ham.
Men det er ikke alt. Sidene er 8 kilobyte i Postgres og 4 kilobyte i Linux. Og det er en full_page_writes-innstilling. Den er aktivert som standard. Og dette er riktig, for slår vi den av, så er det fare for at bare halvparten av siden blir lagret hvis den krasjer.
Oppførselen til å skrive til WAL for foroverloggen er slik at når vi har et sjekkpunkt og vi endrer siden for første gang, kommer hele siden, dvs. alle 8 kilobyte, inn i foroverloggen, selv om vi bare endret linje, som veier 100 byte . Og vi må skrive ned hele siden.
I påfølgende endringer vil det bare være en spesifikk tuppel, men for første gang skriver vi ned alt.
Og følgelig, hvis sjekkpunktet skjedde igjen, må vi starte alt fra bunnen av igjen og presse hele siden. Med hyppige sjekkpunkter, når vi går gjennom de samme sidene, vil full_page_writes = on være mer enn det kan være, det vil si at vi genererer mer WAL. Mer sendes til replikaer, til arkivet, til disk.
Og følgelig har vi to oppsigelser.
Hvis vi øker max_wal_size, viser det seg at vi gjør det enklere for både checkpoint og wal writer. Og det er flott.
La oss legge inn en terabyte og leve med det. Hva er galt med det? Dette er dårlig, for i tilfelle feil vil vi klatre i timevis, fordi sjekkpunktet var for lenge siden og mye har allerede endret seg. Og vi må gjøre alt dette REDO. Og så gjør vi den andre serien med eksperimenter.
Vi gjør en operasjon og ser når sjekkpunktet er i ferd med å fullføres, vi dreper -9 Postgres med vilje.
Og etter det starter vi den igjen, og ser hvor lenge den vil stige på dette utstyret, dvs. hvor mye den vil GJØRE i denne dårlige situasjonen.
To ganger vil jeg konstatere at situasjonen er dårlig. Først krasjet vi rett før sjekkpunktet var over, så vi har mye å tape. Og for det andre hadde vi en massiv operasjon. Og hvis sjekkpunkter var på timeout, ville mest sannsynlig mindre WAL blitt generert siden siste sjekkpunkt. Det vil si at det er en dobbel taper.
Vi måler en slik situasjon for forskjellige max_wal_size-størrelser og forstår at hvis max_wal_size er 64 gigabyte, så vil vi i doble verste fall klatre i 10 minutter. Og vi tenker om det passer oss eller ikke. Dette er et forretningsspørsmål. Vi må vise dette bildet til de ansvarlige for forretningsbeslutninger og spørre: «Hvor lenge kan vi maksimalt ligge nede i tilfelle et problem? Kan vi legge oss i verste situasjon i 3-5 minutter? Og du tar en avgjørelse.
Og her er et interessant poeng. Vi har et par rapporter om Patroni på konferansen. Og kanskje du bruker det. Dette er en autofailover for Postgres. GitLab og Data Egret snakket om dette.
Og hvis du har en autofailover som kommer om 30 sekunder, så kan vi kanskje ligge i 10 minutter? Fordi vi vil bytte til replikaen på dette tidspunktet, og alt vil være bra. Dette er et omstridt poeng. Jeg vet ikke noe klart svar. Jeg føler bare at dette emnet ikke bare handler om krasjgjenoppretting.
Hvis vi har lang restitusjon etter en feil, vil vi være ukomfortable i mange andre situasjoner. For eksempel i de samme eksperimentene, når vi gjør noe og noen ganger må vente i 10 minutter.
Jeg vil fortsatt ikke gå for langt, selv om vi har en autofailover. Som regel er verdier som 64, 100 gigabyte gode verdier. Noen ganger er det til og med verdt å velge mindre. Generelt er dette en subtil vitenskap.
For å gjøre iterasjoner, for eksempel max_wal_size =1, 8, må du gjenta masseoperasjonen mange ganger. Du klarte det. Og på samme base vil du gjøre det igjen, men du har allerede slettet alt. Hva å gjøre?
Jeg skal snakke senere om løsningen vår, hva vi gjør for å gjenta i slike situasjoner. Og dette er den mest korrekte tilnærmingen.
Men i dette tilfellet var vi heldige. Hvis, som det står her "BEGIN, DELETE, ROLLBACK", så kan vi gjenta SLETT. Det vil si at hvis vi kansellerte det selv, så kan vi gjenta det. Og fysisk hos deg vil dataene ligge på samme sted. Du får ikke engang oppblåsthet. Du kan iterere over slike DELETEs.
Denne DELETE med ROLLBACK er ideell for sjekkpunktinnstilling, selv om du ikke har en riktig distribuert databaselab.
Vi laget en plate med en kolonne "i". Postgres har verktøykolonner. De er usynlige med mindre det er spesifikt bedt om det. Disse er: ctid, xmid, xmax.
Ctid er en fysisk adresse. Null side, den første tuppelen på siden.
Det kan sees at etter ROOLBACK forble tupelen på samme sted. Det vil si at vi kan prøve igjen, det vil oppføre seg på samme måte. Dette er hovedsaken.
Xmax er tidspunktet for døden til tupelen. Det ble stemplet, men Postgres vet at transaksjonen ble rullet tilbake, så det spiller ingen rolle om det er 0 eller det er en tilbakeført transaksjon. Dette antyder at det er mulig å iterere over SLETT og sjekke bulkoperasjonene til systemets oppførsel. Du kan lage databaselaboratorier for de fattige.
Dette handler om programmerere. Også når det gjelder DBA, skjeller de alltid programmerere for dette: «Hvorfor gjør dere så lange og vanskelige operasjoner?». Dette er et helt annet vinkelrett tema. Før var det administrasjon, og nå blir det utvikling.
Det er klart at vi ikke har brutt i stykker. Det er klart. Det er umulig å ikke bryte en slik SLETT for en haug med millioner av linjer i deler. Det vil bli gjort i 20 minutter, og alt vil legge seg ned. Men dessverre gjør selv erfarne utviklere feil, selv i veldig store selskaper.
Hvorfor er det viktig å bryte?
-
Hvis vi ser at disken er hard, la oss senke den. Og hvis vi er ødelagte, kan vi legge til pauser, vi kan bremse gassen.
-
Og vi vil ikke blokkere andre på lenge. I noen tilfeller spiller det ingen rolle, hvis du sletter ekte søppel som ingen jobber med, vil du mest sannsynlig ikke blokkere noen bortsett fra autovakuumarbeidet, fordi det vil vente på at transaksjonen skal fullføres. Men hvis du fjerner noe som noen andre kan be om, så blir de blokkert, det blir en slags kjedereaksjon. Lange transaksjoner bør unngås på nettsider og mobilapplikasjoner.
Dette er interessant. Jeg ser ofte at utviklere spør: "Hvilken pakkestørrelse skal jeg velge?".
Det er klart at jo større buntstørrelsen er, desto mindre blir transaksjonskostnadene, dvs. de ekstra kostnadene fra transaksjoner. Men samtidig øker tiden for denne transaksjonen.
Jeg har en veldig enkel regel: ta så mye du kan, men ikke gå over kjørbare filer per sekund.
Hvorfor et sekund? Forklaringen er veldig enkel og forståelig for alle, også ikke-tekniske personer. Vi ser en reaksjon. La oss ta 50 millisekunder. Hvis noe har endret seg, vil øyet vårt reagere. Hvis mindre, så vanskeligere. Hvis noe reagerer etter 100 millisekunder, for eksempel, du klikket med musen, og det svarte deg etter 100 millisekunder, føler du allerede denne lille forsinkelsen. Et sekund oppfattes allerede som bremser.
Følgelig, hvis vi bryter masseoperasjonene våre i 10-sekunders utbrudd, har vi en risiko for at vi blokkerer noen. Og det vil fungere i noen sekunder, og folk vil allerede legge merke til det. Derfor foretrekker jeg å ikke gjøre mer enn et sekund. Men på samme tid, ikke del det opp veldig fint, fordi transaksjonskostnadene vil bli merkbare. Basen blir hardere, og andre forskjellige problemer kan oppstå.
Vi velger størrelsen på pakken. I hvert tilfelle kan vi gjøre det annerledes. Kan automatiseres. Og vi er overbevist om effektiviteten av behandlingen av én pakke. Det vil si at vi sletter én pakke eller OPPDATER.
Alt jeg snakker om handler forresten ikke bare om SLETT. Som du gjettet, er dette alle bulkoperasjoner på data.
Og vi ser at opplegget er utmerket. Du kan se indeksskanningen, kun indeksskanning er enda bedre. Og vi har en liten mengde data involvert. Og mindre enn et sekund oppfyller. Super.
Og vi må fortsatt sørge for at det ikke er noen degradering. Det hender at de første pakkene raskt ordner seg, og så blir det verre, verre og verre. Prosessen er slik at du må teste mye. Det er nettopp dette databaselabs er for.
Og vi må fortsatt forberede noe slik at det lar oss følge dette riktig i produksjonen. For eksempel kan vi skrive klokkeslettet i loggen, vi kan skrive hvor vi er nå og hvem vi nå har slettet. Og dette vil tillate oss å forstå hva som skjer senere. Og i tilfelle noe går galt, finn problemet raskt.
Hvis vi trenger å sjekke effektiviteten til forespørsler og vi må iterere mange ganger, så er det noe slikt som en med-bot. Han er allerede klar. Den brukes av dusinvis av utviklere daglig. Og han vet hvordan han skal gi en enorm terabyte-database på forespørsel på 30 sekunder, din egen kopi. Og du kan slette noe der og si RESET, og slette det igjen. Du kan eksperimentere med det på denne måten. Jeg ser en fremtid for dette. Og vi gjør det allerede.
Hva er partisjoneringsstrategier? Jeg ser 3 forskjellige partisjoneringsstrategier som utviklerne på pakken bruker.
Den første er veldig enkel. Vi har en numerisk ID. Og la oss dele det opp i forskjellige intervaller og jobbe med det. Ulempen er tydelig. I det første segmentet kan vi ha 100 linjer med ekte søppel, i det andre 5 linjer eller ikke i det hele tatt, eller alle 1 linjer vil vise seg å være søppel. Veldig ujevnt arbeid, men det er lett å bryte. De tok maksimal ID og knuste den. Dette er en naiv tilnærming.
Den andre strategien er en balansert tilnærming. Den brukes i Gitlab. De tok og skannet bordet. Vi fant grensene til ID-pakkene slik at hver pakke hadde nøyaktig 10 000 poster. Og sett dem i kø. Og så behandler vi. Du kan gjøre dette i flere tråder.
Også i den første strategien kan du forresten gjøre dette i flere tråder. Det er ikke vanskelig.
Men det er en kulere og bedre tilnærming. Dette er den tredje strategien. Og når det er mulig, er det bedre å velge det. Dette gjør vi på grunnlag av en spesiell indeks. I dette tilfellet vil det mest sannsynlig være en indeks i henhold til vår søppeltilstand og ID. Vi vil inkludere ID slik at det er en kun indeksskanning slik at vi ikke går til haugen.
Generelt er kun indeksskanning raskere enn indeksskanning.
Og vi finner raskt ID-ene våre som vi ønsker å fjerne. BATCH_SIZE velger vi på forhånd. Og vi får dem ikke bare, vi får dem på en spesiell måte og hacker dem umiddelbart. Men vi låser slik at hvis de allerede er låst, låser vi dem ikke, men går videre og tar de neste. Dette er for oppdateringshopp låst. Denne superfunksjonen til Postgres lar oss jobbe i flere tråder hvis vi vil. Det er mulig i en strøm. Og her er det en CTE - dette er en forespørsel. Og vi har en skikkelig sletting på gang i andre etasje i denne CTE - returning *. Du kan returnere id, men det er bedre *hvis du ikke har mye data på hver linje.
Hvorfor trenger vi det? Det er dette vi må rapportere tilbake. Vi har nå slettet så mange linjer faktisk. Og vi har grenser etter ID eller ved create_at som dette. Du kan gjøre min, maks. Noe annet kan gjøres. Du kan gjøre mye her. Og det er veldig praktisk for overvåking.
Det er en merknad til om indeksen. Hvis vi bestemmer oss for at vi trenger en spesiell indeks for denne oppgaven, må vi sørge for at den ikke ødelegger bare tuppeloppdateringer. Det vil si at Postgres har slik statistikk. Dette kan sees i pg_stat_user_tables for tabellen din. Du kan se om varme oppdateringer brukes eller ikke.
Det er situasjoner når den nye indeksen din ganske enkelt kan kutte dem av. Og du har alle de andre oppdateringene som allerede fungerer, sakte ned. Ikke bare fordi indeksen dukket opp (hver indeks bremser oppdateringene litt, men litt), men her ødelegger den fortsatt. Og det er umulig å gjøre spesiell optimalisering for dette bordet. Dette skjer noen ganger. Dette er en slik subtilitet som få mennesker husker. Og denne raken er lett å tråkke på. Noen ganger skjer det at du trenger å finne en tilnærming fra den andre siden og fortsatt klare deg uten denne nye indeksen, eller lage en annen indeks, eller på annen måte, for eksempel, kan du bruke den andre metoden.
Men dette er den mest optimale strategien, hvordan dele opp i batcher og skyte på batcher med én forespørsel, slette litt osv.
Lange transaksjoner
Blokkert autovakuum -
blokkeringsproblem -
Feil #5 er en stor en. Nikolai fra Okmeter snakket om Postgres-overvåking. Ideell Postgres-overvåking eksisterer dessverre ikke. Noen er nærmere, noen er lengre. Okmeter er nær nok til å være perfekt, men mye mangler og må legges til. Du må være klar for dette.
For eksempel er døde tupler best overvåket. Hvis du har mange døde ting på bordet, så er det noe galt. Det er bedre å reagere nå, ellers kan det bli degradering, og vi kan legge oss ned. Det skjer.
Hvis det er en stor IO, så er det klart at dette ikke er bra.
Lange transaksjoner også. Lange transaksjoner bør ikke tillates på OLTP. Og her er en lenke til en kodebit som lar deg ta denne kodebiten og allerede spore lange transaksjoner.
Hvorfor er lange transaksjoner dårlige? Fordi alle låsene frigjøres først på slutten. Og vi driter alle sammen. I tillegg blokkerer vi autovakuum for alle bord. Det er ikke bra i det hele tatt. Selv om du har hot standby aktivert på kopien, er den fortsatt dårlig. Generelt er det ingen steder bedre å unngå lange transaksjoner.
Hvis vi har mange bord som ikke er støvsuget, så må vi ha et varsel. Her er en slik situasjon mulig. Vi kan indirekte påvirke driften av autovakuum. Dette er et utdrag fra Avito, som jeg har forbedret litt. Og det viste seg å være et interessant verktøy for å se hva vi har med autovakuum. For eksempel venter noen bord der og vil ikke vente på tur. Du må også sette den i overvåking og ha et varsel.
Og utsteder blokker. Skog av blokktrær. Jeg liker å ta noe fra noen og forbedre det. Her tok jeg en kul rekursiv CTE fra Data Egret som viser en skog av slusetrær. Dette er et godt diagnostisk verktøy. Og på grunnlag av det kan du også bygge overvåking. Men dette må gjøres forsiktig. Du må lage en liten statement_timeout for deg selv. Og lock_timeout er ønskelig.
Noen ganger oppstår alle disse feilene i sum.
Etter min mening er hovedfeilen her organisatorisk. Det er organisatorisk, fordi teknikken ikke trekker. Dette er nummer 2 - de sjekket på feil sted.
Vi sjekket på feil sted, fordi vi ikke hadde en produksjonsklon, som er lett å sjekke. En utvikler har kanskje ikke tilgang til produksjon i det hele tatt.
Og vi sjekket ikke der. Hadde vi sjekket der, hadde vi sett det selv. Utvikleren så det hele selv uten en DBA hvis han sjekket det i et godt miljø, hvor det er samme mengde data og en identisk plassering. Han ville ha sett all denne fornedrelsen og han ville skamme seg.
Mer om autovakuum. Etter at vi har gjort et massivt sveip på flere millioner linjer, må vi fortsatt gjøre PAKKE PÅ. Dette er spesielt viktig for indekser. De vil føle seg dårlige etter at vi har renset alt der.
Og hvis du ønsker å få tilbake det daglige rengjøringsarbeidet, så vil jeg foreslå å gjøre det oftere, men mindre. Det kan være en gang i minuttet eller enda oftere litt. Og du må overvåke to ting: at denne tingen ikke har noen feil og at den ikke henger etter. Trikset jeg viste vil bare løse dette.
Det vi gjør er åpen kildekode. Det er lagt ut på GitLab. Og vi gjør det slik at folk kan sjekke selv uten DBA. Vi gjør en databaselab, det vil si at vi kaller basekomponenten som Joe jobber med. Og du kan hente en kopi av produksjonen. Nå er det en implementering av Joe for slack, du kan si der: "forklar en slik og slik forespørsel" og umiddelbart få resultatet for din kopi av databasen. Du kan til og med SLETTE der, og ingen vil legge merke til det.
La oss si at du har 10 terabyte, vi lager databaselab også til 10 terabyte. Og med samtidige 10 terabyte databaser kan 10 utviklere jobbe samtidig. Alle kan gjøre hva de vil. Kan slette, slippe osv. Det er en slik fantasi. Vi skal snakke om dette i morgen.
Dette kalles thin provisioning. Dette er subtil klargjøring. Dette er en slags fantasi som fjerner forsinkelser i utvikling, i testing og gjør verden til et bedre sted i denne forbindelse. Det vil si at det bare lar deg unngå problemer med bulkoperasjoner.
Eksempel: 5 terabyte database, får en kopi på mindre enn 30 sekunder. Og det avhenger ikke engang av størrelsen, det vil si at det ikke spiller noen rolle hvor mange terabyte.
I dag kan du gå til og grav i verktøyene våre. Du kan registrere deg for å se hva som finnes. Du kan installere denne boten. Det er gratis. Skrive.
spørsmål
Svært ofte i virkelige situasjoner viser det seg at dataene som skal forbli i tabellen er mye mindre enn det som må slettes. Det vil si at i en slik situasjon er det ofte lettere å implementere en slik tilnærming, når det er lettere å lage et nytt objekt, kopiere bare de nødvendige dataene dit og trunk den gamle tabellen. Det er klart at en programmatisk tilnærming er nødvendig for dette øyeblikket, mens du skal bytte. Hvordan er denne tilnærmingen?
Dette er en veldig god tilnærming og en veldig god oppgave. Det er veldig likt det pg_repack gjør, det er veldig likt det du må gjøre når du lager IDer til 4 byte. Mange rammeverk gjorde dette for noen år siden, og bare platene har vokst opp, og de må konverteres til 8 byte.
Denne oppgaven er ganske vanskelig. Vi gjorde det. Og du må være veldig forsiktig. Det er låser osv. Men det blir gjort. Det vil si at standardtilnærmingen er å gå med pg_repack. Du erklærer en slik etikett. Og før du begynner å laste opp øyeblikksbildedata til den, erklærer du også én plate som sporer alle endringer. Det er et triks at du kanskje ikke engang sporer noen endringer. Det er finesser. Og så bytter du ved å rulle endringer. Det blir en liten pause når vi stenger alle, men generelt blir dette gjort.
Hvis du ser på pg_repack på GitHub, så der, når det var en oppgave å konvertere en ID fra int 4 til int 8, så var det en idé å bruke selve pg_repack. Dette er også mulig, men det er litt av et hack, men det vil fungere for dette også. Du kan gripe inn i triggeren som pg_repack bruker og si der: "Vi trenger ikke disse dataene", dvs. vi overfører kun det vi trenger. Og så bytter han bare og det er det.
Med denne tilnærmingen får vi fortsatt en annen kopi av tabellen, der dataene allerede er indeksert og stablet veldig jevnt med vakre indekser.
Bloat er ikke tilstede, det er en god tilnærming. Men jeg vet at det er forsøk på å utvikle en automatisering for dette, det vil si å lage en universell løsning. Jeg kan sette deg i kontakt med denne automatiseringen. Det er skrevet i Python, noe som er bra.
Jeg er bare litt fra MySQL-verdenen, så jeg kom for å lytte. Og vi bruker denne tilnærmingen.
Men det er bare hvis vi har 90%. Hvis vi har 5 %, så er det ikke så godt å bruke det.
Takk for rapporten! Hvis det ikke er ressurser til å lage en fullstendig kopi av prod, finnes det noen algoritme eller formel for å beregne belastningen eller størrelsen?
Godt spørsmål. Så langt er vi i stand til å finne multi-terabyte databaser. Selv om maskinvaren der ikke er den samme, for eksempel mindre minne, mindre prosessor og disker er ikke helt det samme, men likevel gjør vi det. Hvis det er absolutt ingen steder, må du tenke. La meg tenke til i morgen, du kom, vi snakker, dette er et godt spørsmål.
Takk for rapporten! Du begynte først med det faktum at det er en kul Postgres, som har slike og slike begrensninger, men den er under utvikling. Og dette er i det store og hele en krykke. Er ikke alt dette i konflikt med utviklingen av selve Postgres, der en eller annen DELETE deferent vil dukke opp eller noe annet som burde holde på et lavt nivå det vi prøver å smøre med noen av våre merkelige virkemidler her?
Hvis vi sa i SQL å slette eller oppdatere mange poster i en transaksjon, hvordan kan Postgres distribuere det der? Vi er fysisk begrenset i driften. Vi vil fortsatt gjøre det i lang tid. Og vi vil låse på dette tidspunktet osv.
Ferdig med indekser.
Jeg kan anta at den samme sjekkpunktinnstillingen kan automatiseres. En dag kan det være det. Men så skjønner jeg ikke helt spørsmålet.
Spørsmålet er, er det en slik utviklingsvektor som går her og der, og her går din parallelt? De. Har de ikke tenkt på det ennå?
Jeg snakket om prinsippene som kan brukes nå. Det er en annen bot , med dette kan du gjøre automatisert sjekkpunktinnstilling. Vil det en dag være i Postgres? Jeg vet ikke, det har ikke engang blitt diskutert enda. Det er vi fortsatt langt fra. Men det er forskere som lager nye systemer. Og de dytter oss inn i automatiske indekser. Det er utviklinger. For eksempel kan du se på automatisk tuning. Den velger parametere automatisk. Men han vil ikke gjøre sjekkpunktinnstilling for deg ennå. Det vil si at den vil plukke opp for ytelse, skallbuffer, etc.
Og for sjekkpunktinnstilling kan du gjøre dette: hvis du har tusen klynger og forskjellig maskinvare, forskjellige virtuelle maskiner i skyen, kan du bruke boten vår gjøre automatisering. Og max_wal_size velges automatisk i henhold til målinnstillingene dine. Men så langt er dette ikke engang i nærheten av kjernen, dessverre.
God ettermiddag Du snakket om farene ved lange transaksjoner. Du sa at autovakuum er blokkert i tilfelle slettinger. Hvordan skader det oss ellers? For vi snakker mer om å frigjøre plass og å kunne bruke den. Hva mer mangler vi?
Autovacuum er kanskje ikke det største problemet her. Og det faktum at en lang transaksjon kan låse andre transaksjoner, denne muligheten er farligere. Hun møter kanskje eller ikke. Hvis hun møttes, kan det være veldig ille. Og med autovakuum - dette er også et problem. Det er to problemer med lange transaksjoner i OLTP: låser og autovakuum. Og hvis du har varm standby-tilbakemelding aktivert på kopien, vil du fortsatt motta en autovakuumlås på masteren, den kommer fra kopien. Men det blir i hvert fall ingen låser. Og det blir loks. Vi snakker om dataendringer, så låser er et viktig poeng her. Og hvis dette er alt i lang, lang tid, blir flere og flere transaksjoner låst. De kan stjele andre. Og det dukker opp trær. Jeg ga en lenke til utdraget. Og dette problemet blir mer merkbart raskere enn problemet med autovakuum, som bare kan akkumuleres.
Takk for rapporten! Du startet rapporten med å si at du testet feil. Vi fortsatte ideen om at vi må ta det samme utstyret, med basen på samme måte. La oss si at vi ga utvikleren en base. Og han etterkom forespørselen. Og han ser ut til å ha det bra. Men han sjekker ikke for live, men for live har vi for eksempel en belastning på 60-70%. Og selv om vi bruker denne tuningen, fungerer det ikke særlig bra.
Å ha en ekspert på laget og bruke DBA-eksperter som kan forutsi hva som vil skje med en reell bakgrunnsbelastning er viktig. Når vi nettopp kjørte våre rene endringer, ser vi bildet. Men en mer avansert tilnærming, da vi gjorde det samme igjen, men med en belastning simulert med produksjon. Det er ganske kult. Inntil da må du bli voksen. Det er som en voksen. Vi har bare sett på hva vi har og også sett på om vi har nok ressurser. Det er et godt spørsmål.
Når vi allerede gjør et søppelvalg og vi for eksempel har et slettet flagg
Dette er hva autovacuum gjør automatisk i Postgres.
Å, gjør han det?
Autovacuum er søppelsamleren.
Takk!
Takk for rapporten! Er det et alternativ å umiddelbart designe en database med partisjonering på en slik måte at alt søppel blir skittent fra hovedbordet et sted til siden?
Selvfølgelig har.
Er det mulig da å beskytte oss selv om vi har låst et bord som ikke skal brukes?
Selvfølgelig har. Men det er som et spørsmål om kylling og egg. Hvis vi alle vet hva som vil skje i fremtiden, så vil vi selvfølgelig gjøre alt kult. Men virksomheten er i endring, det er nye spalter, nye forespørsler. Og så – ops, vi vil fjerne det. Men denne ideelle situasjonen, i livet det skjer, men ikke alltid. Men alt i alt er det en god idé. Bare avkort og det er det.
Kilde: www.habr.com