Bästa DELETE. Nikolay Samokhvalov (Postgres.ai)

En dag i en avlägsen framtid kommer automatisk borttagning av onödiga data att vara en av de viktiga uppgifterna för ett DBMS [1]. Under tiden måste vi själva ta hand om att radera eller flytta onödig data till billigare lagringssystem. Låt oss säga att du bestämmer dig för att ta bort flera miljoner rader. En ganska enkel uppgift, speciellt om tillståndet är känt och det finns ett lämpligt index. "DELETE FROM table1 WHERE col1 = :value" - vad kan vara enklare, eller hur?

videor:

• Jag har suttit i Highload-programkommittén sedan första året, d.v.s. sedan 2007.

• Och jag har varit med Postgres sedan 2005. Använde det i många projekt.

• Gruppen har också varit med i RuPostges sedan 2007.

• Vi har vuxit till 2100+ deltagare på Meetup. Detta är den andra platsen i världen efter New York, efter att ha kört om San Francisco för länge sedan.

• Jag har bott i Kalifornien i flera år. Jag jobbar mest med amerikanska företag, inklusive stora. De är aktiva Postgres-användare. Och alla möjliga intressanta saker dyker upp där.

https://postgres.ai/ – det här är mitt företag. Vi arbetar med att automatisera uppgifter som eliminerar utvecklingsavbrott.

Om du gör något, ibland finns det några fel runt Postgres. Låt oss säga att du måste vänta tills administratören får dig en testbänk, eller så måste du vänta tills DBA svarar dig. Och vi hittar sådana flaskhalsar i utvecklings-, testnings- och administrationsprocessen och försöker eliminera dem med hjälp av automatisering och nya tillvägagångssätt.

https://www.seagate.com/files/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf

Jag var nyligen på VLDB i Los Angeles. Detta är den största databaskonferensen. Och det fanns en rapport som i framtiden kommer DBMS inte bara att lagra, utan också automatiskt radera data. Det här är ett nytt ämne.

Det finns mer och mer data i världen. Zetabyte är 1 000 000 petabyte. Och nu uppskattas det redan att vi har mer än 100 zettabyte data lagrade i världen. Och det blir fler och fler av dem.

https://vldb2019.github.io/files/VLDB19-keynote-2-slides.pdf

Och vad ska man göra med det? Det är klart att det måste raderas. Här är en länk till denna intressanta rapport. Men hittills har detta inte implementerats i DBMS.

De som vet hur man räknar pengar vill ha två saker. De vill att vi ska radera, så tekniskt sett måste vi kunna göra det.

Det jag kommer att berätta härnäst är en abstrakt situation som inkluderar ett gäng verkliga situationer, det vill säga en viss sammanställning av vad som faktiskt hände mig och de omgivande databaserna många gånger, många år. Rakes finns överallt och alla trampar på dem hela tiden.

Låt oss säga att vi har en bas eller flera baser som växer. Och några av skivorna är uppenbart skräp. Användaren började till exempel göra något där, men avslutade inte. Och efter en tid vet vi att detta oavslutade arbete inte längre kan lagras. Det vill säga, vi skulle vilja städa lite skräpsaker för att spara utrymme, förbättra prestanda osv.

I allmänhet är uppgiften att automatisera borttagningen av specifika saker, specifika rader i en tabell.

Och vi har en förfrågan som vi kommer att prata om idag, det vill säga om sopborttagning.

Vi bad en erfaren utvecklare att göra detta. Han tog denna begäran, kontrollerade den själv - allt fungerar. Jag testade det på iscensättning - allt är bra. Rullade ut det - allt fungerar. En gång om dagen kör vi detta - allt är bra.

Databasen växer och växer. Den dagliga DELETE börjar fungera lite långsammare.

Då inser vi att vi nu är ett marknadsföringsföretag och trafiken kommer att bli flera gånger större, så vi bestämmer oss för att tillfälligt pausa onödiga saker. Och vi glömmer att lämna tillbaka den.

Några månader senare kom de ihåg. Och den utvecklaren slutade eller var upptagen med något annat, de tilldelade en annan att lämna tillbaka den.

Han kollade på dev, på iscensättning - allt är OK. Naturligtvis behöver du fortfarande städa upp det som har samlats. Han kollade, allt fungerar.

Vad händer sen? Sedan faller allt isär för oss. Det sjunker så mycket att allt någon gång ramlar ner. Alla är i chock, ingen förstår vad som händer. Och sedan visar det sig att denna DELETE var problemet.

Något gick fel? Här är en lista över saker som kan gå fel. Vilken av dessa är viktigast?

• Det fanns till exempel ingen recension, d.v.s. DBA-experten tittade inte. Med ett erfaret öga skulle han genast hitta problemet, och dessutom har han tillgång till prod, där flera miljoner rader har samlats.

• Kanske har de kollat ​​något fel.

• Kanske är hårdvaran föråldrad och du behöver uppgradera den här databasen.

• Eller så är något fel med själva databasen, och vi måste flytta från Postgres till MySQL.

• Eller så kanske det är något fel på operationen.

• Kanske finns det några fel i organisationen av arbetet och du behöver sparka någon och anställa bättre folk?

Det fanns ingen DBA-kontroll. Om det fanns en DBA skulle han se dessa flera miljoner rader och även utan några experiment skulle han säga: "De gör inte det." Låt oss säga att om den här koden fanns i GitLab, GitHub och det fanns en kodgranskningsprocess och det inte fanns något sådant att utan DBA-godkännande skulle denna operation ske på prod, då skulle DBA självklart säga: "Du kan inte göra det. ”

Och han skulle säga att du kommer att ha problem med disk-IO och alla processer kommer att bli galna, det kan finnas lås, och du kommer också att blockera autovakuumet i ett gäng minuter, så det här är inte bra.

http://bit.ly/nancy-hl2018-2

Det andra misstaget är att de checkade på fel ställe. Vi såg i efterhand att mycket skräpdata hade samlats på prod, men utvecklaren hade inte samlat data i den här databasen, och ingen skapade riktigt detta skräp på iscensättning. Följaktligen fanns det 1 000 linjer, som snabbt blev klara.

Vi förstår att våra tester är svaga, det vill säga att processen som byggs inte fångar problem. Ett adekvat DB-experiment utfördes inte.

Ett idealiskt experiment bör helst utföras på samma utrustning. Det är inte alltid möjligt att göra detta på samma hårdvara, men det är mycket viktigt att det är en kopia av databasen i full storlek. Detta är vad jag har predikat i flera år nu. Och för ett år sedan pratade jag om detta, du kan se allt på YouTube.

Kanske är vår utrustning dålig? Om du tittar har latensen hoppat. Vi såg att återvinningen var 100 %. Naturligtvis, om dessa vore moderna NVMe-enheter, så skulle det förmodligen vara mycket lättare för oss. Och vi kanske inte skulle lägga oss på grund av det.

Om du har moln är uppgraderingen enkel. Vi lanserade nya repliker på ny hårdvara. Övergång. Och allt är bra. Ganska lätt.

Är det möjligt att på något sätt röra mindre diskar? Och här, med hjälp av DBA, dyker vi in ​​i ett visst ämne som kallas checkpoint tuning. Det visar sig att vi inte har utfört checkpoint tuning.

Vad är en checkpoint? Detta är tillgängligt i alla DBMS. När data i ditt minne ändras skrivs de inte direkt till diskar. Information om att data har ändrats skrivs först till framåtloggen, i framskrivningsloggen. Och någon gång bestämmer DBMS att det är dags att kasta de riktiga sidorna på disken, så att om vi har ett fel kan vi göra mindre om. Det är som en leksak. Om vi ​​dödas kommer vi att starta spelet från den sista checkpointen. Och alla DBMS implementerar detta.

Inställningarna i Postgres släpar efter. De är designade för 10-15 år gamla volymer av data och operationer. Och checkpoint är inget undantag.

Denna information kommer från vår rapport med Postgres check-up, det vill säga automatisk hälsokontroll. Och här är en databas med flera terabyte. Och det är tydligt att kontrollpunkter tvingas fram i nästan 90 % av fallen.

Vad betyder det? Det finns två inställningar där. Checkpoint kan inträffa i timeout, till exempel inom 10 minuter. Eller det kan inträffa när ganska mycket data har fyllts i.

Och som standard är max_wal_saze inställd på 1 gigabyte. Faktum är att detta faktiskt händer i Postgres efter 300-400 megabyte. Du har ändrat så mycket data och du har en checkpoint.

Och om ingen ställde in den, men tjänsten har vuxit och företaget tjänar mycket pengar, det har många transaktioner, då sker kontrollpunkten en gång i minuten, ibland en gång var 30:e sekund, och ibland överlappar de varandra. . Det här är riktigt dåligt.

Och vi måste se till att det kommer mer sällan. Det vill säga, vi kan höja max_wal_size. Och han kommer att attackera mindre ofta.

Men vi har utvecklat en hel metod för hur man gör detta mer korrekt, det vill säga hur man fattar beslut om att välja inställningar, tydligt baserat på specifik data.

Följaktligen utför vi två serier av databasexperiment.

Första serien - vi ändrar max_wal_size. Och vi genomför en massiv operation. Först gör vi det med standardinställningen 1 gigabyte. Och vi gör en massiv DELETE av många miljoner rader.

Du kan se hur svårt det är för oss. Vi ser att disk IO är mycket dålig. Låt oss se hur mycket WAL vi genererade, för det här är väldigt viktigt. Låt oss se hur många gånger checkpointen hände. Och vi ser att det inte är bra.

Därefter ökar vi max_wal_size. Vi upprepar. Öka, upprepa. Och så många gånger. I princip är 10 poäng bra, där 1, 2, 4, 8 gigabyte. Och vi tittar på beteendet hos ett specifikt system. Det är klart att utrustningen här ska vara som på prod. Du bör ha samma diskar, samma mängd minne och samma Postgres-inställningar.

Och på detta sätt kommer vi att byta ut vårt system, och vi vet hur DBMS kommer att bete sig i händelse av en dålig massa DELETE, hur den kommer att kontrollera.

Kontrollpunkt på ryska betyder kontrollpunkter.

Exempel: TA BORT flera miljoner rader efter index, raderna är "spridda" över sidorna.

Här är ett exempel. Detta är någon grund. Och med standardinställningen på 1 gigabyte för max_wal_size är det väldigt tydligt att våra diskar för inspelning går till hyllan. Den här bilden är ett typiskt symptom på en mycket sjuk patient, det vill säga att han verkligen mådde dåligt. Och det var bara en operation, här var bara DELETE av flera miljoner rader.

Om en sådan operation tillåts i prod, då ramlar vi bara ner, för det är klart att en DELETE dödar oss i hyllan.

Vidare, där det finns 16 gigabyte, kan du se att tänderna redan har börjat dyka upp. Tänderna är redan bättre, det vill säga vi knackar i taket, men inte så illa. Lite frihet dök upp där. Till höger finns inspelningen. Och antalet operationer är den andra grafen. Och det är tydligt att vi redan andas lite lättare med 16 gigabyte.

Och där 64 gigabyte syns har det blivit helt bättre. Redan tänderna syns tydligt, det finns fler möjligheter att överleva andra operationer och göra något med disken.

Varför så?

Jag kommer att dyka in i detaljerna lite, men det här ämnet om hur man utför kontrollpunktsinställning kan resultera i en hel rapport, så jag kommer inte gå in för mycket i detalj, men jag kommer att beskriva lite vilka svårigheter det finns.

Om kontrollpunkten händer för ofta och vi inte uppdaterar våra rader sekventiellt, utan hittar dem efter index, vilket är bra, eftersom vi inte tar bort hela tabellen, kan det hända att vi först rörde första sidan, sedan den tusende, och sedan återvände till den första. Och om kontrollpunkten redan har sparat den på disken mellan dessa besök på första sidan, kommer den att spara den igen, eftersom vi har smutsad ner den en andra gång.

Och vi kommer att tvinga checkpointen att rädda den många gånger. Som om det finns överflödiga operationer för det.

Men det är inte allt. I Postgres väger sidor 8 kilobyte och i Linux 4 kilobyte. Och det finns en inställning full_page_writes. Den är aktiverad som standard. Och detta är korrekt, för om vi stänger av det finns det en risk att om det blir ett misslyckande så sparas bara hälften av sidan.

Beteendet för inmatningen i framåtloggens WAL är sådant att när vi har en kontrollpunkt och vi byter sida för första gången hamnar hela sidan, det vill säga alla 8 kilobyte, i framåtloggen, även om vi ändrade bara en rad som väger 100 byte. Och vi tvingas skriva ner hela sidan.

I efterföljande ändringar kommer det bara att finnas en specifik tupel, men för första gången skriver vi ner allt.

Och följaktligen, om kontrollpunkten händer igen, måste vi börja allt från början igen och fylla på hela sidan. Med frekventa kontrollpunkter, när vi går igenom samma sidor, kommer full_page_writes = on att vara större än det skulle kunna vara, dvs vi genererar mer WAL. Mer skickas till repliker, till arkivet, till disken.

Och följaktligen har vi två uppsägningar.

Om vi ​​ökar max_wal_size visar det sig att vi underlättar arbetet för både checkpoint och wal writer. Och det är jättebra.

Låt oss installera en terabyte och leva med den. Vad är det för dåligt med det? Detta är dåligt, för i händelse av misslyckande kommer vi att gå upp i timmar, eftersom checkpointen var för länge sedan och mycket har redan förändrats. Och vi måste göra REDO för allt detta. Och så gör vi en andra serie experiment.

Vi gör operationen och ser när checkpointen är nära att slutföras, vi gör en kill -9 Postgres med flit.

Och efter det startar vi det igen och ser hur lång tid det tar att stiga på den här utrustningen, dvs hur mycket REDO den kommer att göra i denna dåliga situation.

Jag kommer att notera två gånger att situationen är dålig. För det första föll vi precis före slutet av checkpointen, så vi har mycket att förlora. Och för det andra hade vi en massiv operation. Och om checkpoints hade en timeout, skulle troligen mindre WAL ha genererats sedan den senaste checkpointen. Det vill säga, det här är en två gånger förlorare.

Vi mäter denna situation för olika max_wal_size och förstår att om max_wal_size är 64 gigabyte, så kommer vi i en dubbelt värsta situation att stiga i 10 minuter. Och vi funderar på om det här passar oss eller inte. Det här är en affärsfråga. Vi måste visa den här bilden för de som är ansvariga för affärsbeslut och fråga: "Vad är den maximala tiden vi kan vänta vid problem? Kan vi ligga ner i en sämre situation i 3-5 minuter?” Och du fattar ett beslut.

Och här finns en intressant poäng. Vi har ett par reportage om Patroni på konferensen. Och du kanske använder den. Detta är autofailover för Postgres. GitLab och Data Egret pratade om detta.

Och om du har en autofailover som inträffar inom 30 sekunder, så kanske vi kan ligga ner i 10 minuter? För vid det här laget kommer vi att byta till repliken, och allt kommer att bli bra. Detta är en kontroversiell fråga. Jag vet inget klart svar. Jag känner bara att det här ämnet inte bara handlar om katastrofåterställning.

Om vi ​​har en lång återhämtning från ett misslyckande, kommer vi att vara obekväma i många andra situationer. Till exempel i samma experiment, när vi gör något och ibland måste vänta i 10 minuter.

Jag skulle fortfarande inte gå för långt, även om vi har autofailover. Som regel är värden som 64, 100 gigabyte bra värden. Ibland är det till och med värt att välja mindre. I allmänhet är detta en subtil vetenskap.

För att till exempel iterera max_wal_size = 1, 8 måste du upprepa massoperationen många gånger. Du gjorde det. Och du vill göra det igen på samma bas, men du har redan tagit bort allt. Vad ska man göra?

Jag kommer att berätta senare om vår lösning och vad vi gör för att upprepa i sådana situationer. Och detta är det mest korrekta tillvägagångssättet.

Men i det här fallet hade vi tur. Om, som det står här "BEGIN, DELETE, ROLLBACK", så kan vi upprepa DELETE. Det vill säga om vi avbröt det själva, då kan vi upprepa det. Och fysiskt kommer din data att finnas där. Du får inte ens någon svullnad. Du kan iterera på en sådan DELETE.

Denna DELETE med ROLLBACK är idealisk för kontrollpunktsinställning, även om du inte har en korrekt distribuerad databaslabb.

Vi gjorde en skylt med en kolumn "i". Postgres har verktygskolumner. De är osynliga om de inte specifikt efterfrågas. Dessa är: ctid, xmid, xmax.

Ctid är den fysiska adressen. Sida noll, den första tuppeln på sidan.

Det kan ses att efter ROOLBACK stannade tupeln kvar på samma plats. Det vill säga, vi kan försöka igen, det kommer att bete sig likadant. Detta är huvudsaken.

Xmax är tidpunkten för tupelns död. Det är inmatat, men Postgres vet att denna transaktion återställdes, så det spelar ingen roll om det är 0 eller en återställd transaktion. Detta tyder på att DELETE kan användas för att iterera och testa massiva operationer av systembeteende. Du kan göra databaslabb för de fattiga.

Det här handlar om programmerare. Om DBA också, de skäller alltid programmerare för detta: "Varför gör du så långa och svåra operationer?" Det här är ett helt annat vinkelrätt ämne. Tidigare fanns det administration, men nu blir det utveckling.

Uppenbarligen har vi inte brutit ner det i bitar. Kusten är klar. Det är omöjligt att dela en sådan DELETE för ett gäng miljontals rader i delar. Det tar 20 minuter att göra och allt kommer att ligga ner. Men tyvärr gör även erfarna utvecklare misstag, även i mycket stora företag.

Varför är det viktigt att bryta?

• Om vi ​​ser att skivan är hård, låt oss sakta ner den. Och om vi är trasiga, då kan vi lägga till pauser, vi kan bromsa gasen.

• Och vi kommer inte att blockera andra länge. I vissa fall spelar det ingen roll, om du tar bort riktigt skräp som ingen jobbar på, då kommer du med största sannolikhet inte att blockera någon förutom autovacuums arbete eftersom det väntar på att transaktionen ska slutföras. Men om du raderar något som någon annan kan begära, då kommer de att blockeras, det blir någon form av kedjereaktion. Långa transaktioner bör undvikas på webbplatser och mobilapplikationer.

https://postgres.ai/products/joe/

Det här är intressant. Jag ser ofta utvecklare som frågar "Vilken paketstorlek ska jag välja?"

Det är tydligt att ju större batchstorleken är, desto lägre blir transaktionsoverheaden, dvs ytterligare transaktionsoverhead. Men samtidigt ökar tiden för denna transaktion.

Jag har en väldigt enkel regel: ta så många som möjligt, men överskrid inte exekveringen per sekund.

Varför en sekund? Förklaringen är väldigt enkel och förståelig för alla, även icke-tekniska personer. Vi ser reaktionen. Låt oss ta 50 millisekunder. Om något har förändrats kommer vårt öga att reagera. Om det är mindre är det svårare. Om något svarar efter 100 millisekunder, till exempel, du klickade med musen och det svarade dig efter 100 millisekunder, känner du redan denna lilla fördröjning. En tvåa uppfattas redan som en broms.

Följaktligen, om vi delar upp våra massoperationer i 10-sekunders skurar, riskerar vi att blockera någon. Och det kommer att fungera i några sekunder, och folk kommer redan att märka det. Det är därför jag föredrar att inte göra det mer än en sekund. Men samtidigt, bryt inte ner det för litet, eftersom transaktionskostnader kommer att märkas. Det blir tyngre för basen och olika andra problem kan uppstå.

Vi väljer förpackningsstorlek. I varje fall kan vi göra detta på olika sätt. Kan automatiseras. Och vi är övertygade om effektiviteten i att bearbeta en förpackning. Det vill säga, vi tar bort ett paket eller uppdaterar.

Förresten, allt jag berättar handlar inte bara om DELETE. Som du gissade är detta alla bulkoperationer på data.

Och vi ser att planen är utmärkt. Du kan se index scan, ännu bättre index scan. Och vi har en liten mängd data inblandade. Och allt fungerar på mindre än en sekund. Super.

Och vi måste fortfarande se till att det inte sker någon nedbrytning. Det händer att de första satserna snabbt blir klara, och sedan blir allt värre och värre och värre. Processen är sådan att du behöver testa mycket. Det är precis vad databaslabb behövs för.

Och vi måste fortfarande förbereda något så att vi kan övervaka detta korrekt i produktionen. Vi kan till exempel skriva tiden i loggen, vi kan skriva var vi är nu och vilka vi nu har raderat. Och detta kommer att tillåta oss att senare förstå vad som händer. Och om något går fel, hitta problemet snabbt.

Om vi ​​behöver kontrollera effektiviteten av frågor och vi behöver iterera många gånger, så finns det något sådant som en kollega-bot. Han är redan redo. Den används av dussintals utvecklare varje dag. Och han kan tillhandahålla en enorm terabytedatabas på begäran på 30 sekunder, din egen kopia. Och du kan radera något där och säga RESET, och radera det igen. Du kan experimentera med det på detta sätt. Jag ser en framtid i det här. Och vi gör redan detta.

https://docs.gitlab.com/ee/development/background_migrations.html

Vilka är partitioneringsstrategierna? Jag ser 3 olika partitioneringsstrategier som utvecklarna använder på paketet.

Den första är väldigt enkel. Vi har ett numeriskt ID. Och låt oss dela upp det i olika intervaller och arbeta med det. Nackdelen är tydlig. I det första segmentet kan vi ha 100 rader med riktigt sopor, i det andra 5 rader eller inte alls, eller så kommer alla 1 000 rader att visa sig vara sopor. Mycket ojämnt arbete, men lätt att bryta. De tog max legitimation och slog sönder den. Detta är ett naivt tillvägagångssätt.

Den andra strategin är en balanserad strategi. Det används i Gitlab. Vi tog och skannade bordet. Vi hittade gränserna för ID-paketen så att varje förpackning innehöll exakt 10 000 poster. Och de fastnade mig i någon slags kö. Och vi bearbetar vidare. Det kan du göra i flera trådar.

I den första strategin kan du förresten även göra detta i flera trådar. Det är inte svårt.

https://medium.com/@samokhvalov/how-partial-indexes-affect-update-performance-in-postgres-d05e0052abc

Men det finns ett svalare och mer optimalt tillvägagångssätt. Detta är den tredje strategin. Och när det är möjligt är det bättre att välja det. Vi gör detta utifrån ett speciellt index. I det här fallet kommer det med största sannolikhet att vara ett index baserat på vårt soptillstånd och ID. Vi kommer att inkludera ID så att det bara är en indexskanning så att vi inte går till högen.

Vanligtvis är endast indexsökning snabbare än indexskanning.

Och vi hittar snabbt våra ID:n som vi vill radera. Vi väljer BATCH_SIZE i förväg. Och vi tar inte bara emot dem, vi tar emot dem på ett speciellt sätt och fixar dem omedelbart. Men vi låser dem på ett sådant sätt att om de redan är låsta så låser vi dem inte, utan går vidare och tar nästa. Detta är för uppdateringshopplåst. Denna Postgres superfunktion låter oss arbeta i flera trådar om vi vill. Möjligen i en tråd. Och så finns det CTE - det här är en begäran. Och vi har verklig borttagning på gång på andra våningen av denna CTE - returning *. Du kan returnera id, men det är bättre *, om du har lite data på varje rad.

Varför behöver vi detta? Vi behöver detta för att kunna rapportera. Vi har nu raderat så många rader faktiskt. Och våra gränser efter ID eller create_at är så här. Du kan göra min, max. Något annat kan göras. Det finns mycket du kan stoppa in här. Och detta är mycket bekvämt för övervakning.

Det finns ytterligare en anteckning om indexet. Om vi ​​bestämmer oss för att vi behöver ett speciellt index för just den här uppgiften, måste vi se till att det inte förstör uppdateringar av heap bara tupler. Det vill säga, Postgres har sådan statistik. Detta kan ses i pg_stat_user_tables för din tabell. Du kan se om heta uppdateringar används eller inte.

Det finns situationer då ditt nya index helt enkelt kan klippa bort dem. Och alla andra uppdateringar som redan körs kommer att sakta ner. Inte bara för att indexet dök upp (varje index saktar ner uppdateringarna lite, men bara lite), men här kommer det fortfarande att röra till saker och ting. Och det är omöjligt att göra speciell optimering för detta bord. Detta händer ibland. Detta är en sådan subtilitet som få människor kommer ihåg. Och det är lätt att trampa på denna rake. Ibland händer det att du behöver hitta ett tillvägagångssätt från andra sidan och ändå klara dig utan detta nya index, eller göra ett annat index, eller göra något annat, till exempel kan du använda den andra metoden.

Men detta är den mest optimala strategin, hur man delar upp den i batcher och skjuter i omgångar med en begäran, raderar lite i taget, etc.

Långa transaktioner - https://gitlab.com/snippets/1890447

Blockerad autovakuum https://gitlab.com/snippets/1889668

Blockeringsproblem https://gitlab.com/snippets/1890428

Misstag #5 är stort. Nikolay från Okmeter pratade om Postgres-övervakning. Tyvärr existerar inte perfekt Postgres-övervakning. Vissa är närmare, andra är längre. Okmeter är tillräckligt nära för att vara perfekt, men det är mycket som saknas och måste läggas till. Du måste vara beredd på detta.

Till exempel är det bättre att övervaka döda tuplar. Om du har många döda grejer på bordet så är något fel. Det är bättre att reagera nu, annars kan det bli försämring där, och vi kan ligga ner. Det händer.

Om det finns en stor IO så är det klart att detta inte är bra.

Långa transaktioner också. Långa transaktioner bör inte tillåtas på OLTP. Och här är en länk till utdraget, som låter dig ta det här utdraget och redan göra en del spårning av långa transaktioner.

Varför är långa transaktioner dåliga? Eftersom alla lås släpps först i slutet. Och vi låser in alla. Dessutom blockerar vi autovakuum för alla bord. Det här är inte alls bra. Även om du har aktiverat hot standby på repliken är detta fortfarande dåligt. I allmänhet är det bättre att undvika långa transaktioner var som helst.

Om vi ​​har många bord som inte dammsugs så behöver vi ha en varning. En sådan situation är möjlig här. Vi kan indirekt påverka driften av autovakuum. Det här är ett utdrag från Avito, som jag förbättrat lite. Och det visade sig vara ett intressant verktyg för att se vad vi har med autovakuum. Till exempel finns det några bord som väntar där och de väntar inte på sin tur. Du måste också lägga den i övervakning och ha en varning.

Och utfärdar block. Skog av blockerande träd. Jag gillar att ta något från någon och förbättra det. Här tog jag en cool rekursiv CTE från Data Egret, som visar en skog av låsande träd. Detta är bra för diagnostik. Och övervakning kan också byggas på dess grund. Men detta måste göras försiktigt. Du måste göra en liten statement_timeout för dig själv. Och lock_timeout är önskvärt.

Ibland uppstår alla dessa fel samtidigt.

Enligt min mening är det viktigaste misstaget här organisatoriskt. Det är organisatoriskt, eftersom tekniken inte fungerar. Det här är nummer 2 - de checkade på fel ställe.

Vi kollade på fel ställe eftersom vi inte hade en produktionsklon som var lätt att kontrollera. Utvecklaren kanske inte har tillgång till produktion alls.

Och vi kollade på fel ställe. Om de hade kollat ​​där så hade vi sett det själva. Utvecklaren kunde se allt detta även utan en DBA, om han kontrollerade det i en bra miljö, där det finns samma mängd data och ett identiskt arrangemang. Han skulle ha sett all denna förnedring och skulle ha skämts.

Mer om bildammsugaren. Efter att vi har gjort en massiv sanering av flera miljoner rader behöver vi fortfarande göra en OMPACKNING. Detta är särskilt viktigt för index. De kommer att må dåligt efter att vi städat allt där.

Och om du vill ta tillbaka det dagliga arbetet med att strippa, skulle jag föreslå att du gör det oftare, men mindre. Det kan vara en gång i minuten eller till och med lite oftare. Och vi måste övervaka två saker: att den här saken inte har några fel och att den inte släpar efter. Knepet som jag visade gör att du kan lösa detta.

Det vi gör är öppen källkod. Detta publiceras på GitLab. Och vi gör det så att folk kan kolla även utan DBA. Vi gör ett databaslabb, det vill säga vi kallar baskomponenten som Joe för närvarande arbetar med. Och du kan ta en kopia av produktionen. Nu finns det en implementering av Joe för slack, du kan säga där: "förklara en sådan och sådan begäran" och omedelbart få resultatet för din kopia av databasen. Du kan till och med göra DELETE där, och ingen kommer att märka det.

Låt oss säga att du har 10 terabyte, vi gör ett databaslabb också 10 terabyte. Och 10 utvecklare kan arbeta samtidigt med 10 terabyte databaser samtidigt. Alla får göra vad de vill. Kan ta bort, släppa, etc. Det här är fantastiskt. Vi kommer att prata om detta imorgon.

Detta kallas thin provisioning. Detta är subtil provisionering. Det här är någon form av fantasi som i hög grad eliminerar förseningar i utveckling och testning och gör världen till en bättre plats i detta avseende. Det vill säga, det låter dig bara undvika problem med massoperationer.

Exempel: 5 terabyte databas, erhåller en kopia på mindre än 30 sekunder. Och det beror inte ens på storleken, det vill säga det spelar ingen roll hur många terabyte.

Idag kan du gå till postgres.ai och gräva i våra verktyg. Du kan registrera dig och se vad som finns där. Du kan installera den här boten själv. Det är gratis. Skriva.

frågor

Mycket ofta i verkliga situationer visar det sig att data som ska finnas kvar i tabellen är mycket mindre än vad som behöver raderas. Det vill säga, i en sådan situation är det ofta lättare att implementera detta tillvägagångssätt, när det är lättare att skapa ett nytt objekt, kopiera endast nödvändig data dit och transkribera den gamla tabellen. Det är tydligt att du behöver en mjukvarustrategi för det här ögonblicket medan du byter. Hur är detta tillvägagångssätt?

Detta är ett mycket bra tillvägagångssätt och en mycket bra uppgift. Det är väldigt likt det som pg_repack gör, det är väldigt likt det du måste göra när du ID-personer gjorde det till 4 byte. Många ramverk gjorde detta för flera år sedan, och plattorna har precis blivit större, och de måste konverteras till 8 byte.

Denna uppgift är ganska svår. Vi gjorde det. Och du måste vara mycket försiktig. Det finns lås etc. Men det är gjort. Det vill säga, standardmetoden är att använda pg_repack. Du tillkännager ett sådant tecken. Och innan du börjar fylla den med ögonblicksbilddata, deklarerar du också en tabell som spårar alla ändringar. Det finns ett knep där att du kanske inte ens spårar vissa förändringar. Det finns finesser. Och sedan byter du och rullar ut ändringarna. Det blir en kort paus när vi låser in alla, men överlag görs detta.

Om du tittar på pg_repack på GitHub, då det fanns en uppgift att konvertera ID från int 4 till int 8, då fanns det en idé att använda själva pg_repack. Detta är också möjligt, men det här är lite av en hackermetod, men det kommer också att fungera för detta. Du kan ingripa i triggern som använder pg_repack och säga där: "Vi behöver inte denna data", dvs vi överför bara det vi behöver. Och så byter han bara och det är det.

Med detta tillvägagångssätt får vi också en andra kopia av tabellen, där data redan är indexerad och mycket smidigt upplagd med vackra index.

Bloat nej, det här är ett bra tillvägagångssätt. Men jag vet att det finns försök att utveckla automatisering för detta, det vill säga att göra en universell lösning. Jag kan presentera dig för denna automatisering. Det är skrivet i Python, bra grejer.

Jag är bara lite från MySQL-världen, så jag kom för att lyssna. Och vi använder detta tillvägagångssätt.

Men det är bara om vi har 90%. Om vi ​​har 5 % är det inte särskilt bra att använda det.

Tack för rapporten! Om det inte finns några resurser för att göra en fullständig kopia av prod, finns det någon algoritm eller formel för att beräkna belastningen eller storleken?

Bra fråga. Hittills har vi kunnat hitta databaser med flera terabyte. Även om hårdvaran där inte är densamma, till exempel mindre minne, mindre processor och diskarna inte är exakt likadana, gör vi det ändå. Om det inte finns någonstans, måste du tänka på det. Låt mig tänka på det tills imorgon, du kom, vi pratar, det här är en bra fråga.

Tack för rapporten! Du började först prata om att det finns en cool Postgres, som har sådana och sådana begränsningar, men den håller på att utvecklas. Och det här är i det stora hela en krycka. Motsäger inte allt detta utvecklingen av Postgres själv, där någon form av DELETE-deferent kommer att dyka upp eller något annat som borde hålla på en låg nivå vad vi försöker dölja här med några av våra egna konstiga medel?

Om vi ​​i SQL sa att vi skulle radera eller uppdatera många poster i en transaktion, hur kan Postgres då distribuera detta? Vi är fysiskt begränsade i verksamheten. Vi kommer fortfarande att göra det här länge. Och vi kommer att låsa vid den här tiden osv.

De gjorde samma sak med index.

Jag kan anta att samma kontrollpunktsinställning skulle kunna automatiseras. Någon gång kan detta hända. Men då förstår jag inte riktigt frågan.

Frågan är: finns det en utvecklingsvektor som går just där och går parallellt med din här? De där. Tänker de inte på det än?

Jag pratade om de principer som kan användas nu. Det finns en annan bot Nancy, med detta kan du göra automatiserad kontrollpunktsinställning. Kommer detta någonsin att hända i Postgres? Jag vet inte, detta diskuteras inte ens än. Vi är långt ifrån detta än. Men det finns forskare som gör nya system. Och de knuffar in oss i automatiska index. Det finns utvecklingar. Du kan till exempel titta på autotuning. Den väljer parametrar automatiskt. Men han kommer inte att göra checkpoint tuning åt dig ännu. Det vill säga, det kommer att välja för prestanda, skalbuffert, etc.

Och för kontrollpunktsinställning kan du göra följande: om du har tusen kluster och olika delar av hårdvara, olika virtuella maskiner i molnet, kan du använda vår bot Nancy göra automatisering. Och max_wal_size kommer att väljas automatiskt enligt dina målinställningar. Men än så länge är detta inte ens i närheten av att vara i kärnan, tyvärr.

God eftermiddag Du pratade om farorna med långa transaktioner. Du sa att autovakuum blockeras vid raderingar. Hur skadar detta oss annars? För vi pratar mer om att frigöra utrymme och att kunna använda det. Vad mer har vi att förlora?

Autovacuum är kanske inte det största problemet här. Och det faktum att en lång transaktion kan blockera andra transaktioner är en farligare möjlighet. Hon kanske träffas eller inte. Om hon träffades kan det gå väldigt illa. Och med autovacuum är detta också ett problem. Det finns två problem med långa transaktioner i OLTP: lås och autovakuum. Och om du har hot standby-feedback aktiverad på repliken, kommer autovakuumblockeringen också att anlända till mastern, den kommer från repliken. Men det blir åtminstone inga lås där. Och här kommer det att finnas lås. Vi pratar om dataförändringar, så lås är en viktig punkt här. Och om detta pågår under en lång, lång tid, blockeras fler och fler transaktioner. De kan fånga andra. Och låsträd dyker upp. Jag gav en länk till utdraget. Och detta problem blir snabbt mer märkbart än problemet med autovakuum, som bara kan ackumuleras.

Tack för rapporten! Du började din rapport med att säga att du testat fel. Vi fortsatte vår idé att vi måste ta samma utrustning, med basen exakt densamma. Låt oss säga att vi gav utvecklaren en bas. Och han efterkom begäran. Och han verkar ha det bra. Men den kontrollerar inte på live, utan på live, till exempel är vår belastning 60-70%. Och även om vi använder den här inställningen blir det inte särskilt bra

Att ha en expert i ditt team och använda DBA-experter som kan förutsäga vad som kommer att hända under verklig bakgrundsbelastning är viktigt. När vi helt enkelt kört igenom våra rena förändringar ser vi bilden. Men ett mer avancerat tillvägagångssätt var när vi gjorde samma sak igen, men med en simulerad produktionsbelastning. Det här är helt coolt. Vi behöver fortfarande växa till denna punkt. Den är mogen. Vi tittade rent på vad vi har och tittade också på om vi har tillräckligt med resurser. Det är en bra fråga.

När vi redan gör ett sopval och vi har till exempel en raderad flagga

Detta är vad autovacuum gör automatiskt i Postgres.

Åh, gör han det?

Autovacuum är sopsamlaren.

Tack!

Tack för rapporten! Finns det ett alternativ att omedelbart designa en databas med partitionering så att allt skräp tas bort från huvudbordet någonstans åt sidan?

Har såklart.

Kan vi då skydda oss om vi har låst ett bord som inte ska användas?

Har såklart. Men det här är en fråga om kyckling och ägg. Om vi ​​alla vet vad som kommer att hända i framtiden, så kommer vi naturligtvis att göra allt bra. Men verksamheten förändras, nya kolumner och nya förfrågningar dyker upp. Och sedan - oj, vi vill ta bort det. Men detta är en idealisk situation, det händer i livet, men inte alltid. Men överlag är det en bra idé. Bara trunkera och det är allt.

Källa: will.com