Ergens in de verre toekomst zal het automatisch verwijderen van onnodige gegevens een van de belangrijke taken van het DBMS [1] zijn. In de tussentijd moeten we zelf zorgen voor het verwijderen of verplaatsen van onnodige gegevens naar goedkopere opslagsystemen. Stel dat u besluit een paar miljoen rijen te verwijderen. Een vrij eenvoudige opgave, zeker als de aandoening bekend is en er een passende index is. "VERWIJDER UIT tabel1 WHERE col1 =: waarde" - wat is er eenvoudiger, toch?
Video:
-
Ik zit sinds het eerste jaar in de programmacommissie van Highload, dus sinds 2007.
-
En ik werk sinds 2005 bij Postgres. Heb het in veel projecten gebruikt.
-
Groep met RuPostges ook sinds 2007.
-
We zijn gegroeid naar 2100+ deelnemers aan Meetup. Het is de tweede plaats ter wereld na New York, lange tijd ingehaald door San Francisco.
-
Ik heb een aantal jaren in Californië gewoond. Ik werk meer met Amerikaanse bedrijven, ook grote. Het zijn actieve gebruikers van Postgres. En er zijn allerlei interessante dingen.
is mijn bedrijf. We zijn bezig met het automatiseren van taken die ontwikkelingsvertragingen elimineren.
Als je iets aan het doen bent, dan zitten er soms een soort pluggen rond Postgres. Stel dat u moet wachten tot de beheerder een teststand voor u heeft opgezet, of dat u moet wachten tot de DBA op u reageert. En dergelijke knelpunten vinden we in het ontwikkel-, test- en beheerproces en proberen ze op te heffen met behulp van automatisering en nieuwe benaderingen.
Ik was onlangs bij VLDB in Los Angeles. Dit is de grootste conferentie over databases. En er was een rapport dat DBMS in de toekomst niet alleen gegevens zal opslaan, maar ook automatisch zal verwijderen. Dit is een nieuw onderwerp.
Er zijn steeds meer gegevens in de wereld van zettabytes - dat is 1 petabytes. En nu wordt al geschat dat we meer dan 000 zettabytes aan gegevens in de wereld hebben opgeslagen. En dat zijn er steeds meer.
En wat ermee te doen? Het is duidelijk dat het verwijderd moet worden. Hier is een link naar dit interessante rapport. Maar tot nu toe is dit nog niet geïmplementeerd in het DBMS.
Wie geld kan tellen, wil twee dingen. Ze willen dat we verwijderen, dus technisch gezien zouden we het moeten kunnen.
Wat ik hierna zal vertellen, is een abstracte situatie die een aantal echte situaties omvat, d.w.z. een soort compilatie van wat mij werkelijk is overkomen en de omringende databases, vele, vele jaren. Harken zijn overal en iedereen stapt er de hele tijd op.
Laten we zeggen dat we een basis of meerdere bases hebben die groeien. En sommige records zijn duidelijk onzin. De gebruiker is daar bijvoorbeeld iets gaan doen, maar heeft het niet afgemaakt. En na enige tijd weten we dat dit onvoltooide niet meer kan worden opgeslagen. Dat wil zeggen, we willen graag wat afval opruimen om ruimte te besparen, de prestaties te verbeteren, enz.
Over het algemeen is het de taak om het verwijderen van specifieke dingen, specifieke regels in een tabel, te automatiseren.
En we hebben zo'n verzoek, waarover we het vandaag zullen hebben, dat wil zeggen over het verwijderen van afval.
We hebben een ervaren ontwikkelaar gevraagd om het te doen. Hij nam dit verzoek aan, controleerde het zelf - alles werkt. Getest op enscenering - alles is in orde. Uitgerold - alles werkt. Een keer per dag voeren we het uit - alles is in orde.
De databank groeit en groeit. Dagelijks DELETE begint iets langzamer te werken.
Dan begrijpen we dat we nu een marketingbedrijf hebben en het verkeer vele malen groter zal zijn, dus besluiten we om overbodige dingen tijdelijk te pauzeren. En vergeten terug te sturen.
Een paar maanden later wisten ze het weer. En die ontwikkelaar stopte of is met iets anders bezig, heeft een ander opdracht gegeven het terug te sturen.
Hij controleerde de ontwikkelaar, de enscenering - alles is in orde. Natuurlijk moet je nog steeds opruimen wat zich heeft opgehoopt. Hij heeft gecontroleerd of alles werkt.
Wat gebeurt er nu? Dan valt alles voor ons uit elkaar. Het zakt zo dat op een gegeven moment alles naar beneden valt. Iedereen is in shock, niemand begrijpt wat er gebeurt. En dan blijkt dat de kwestie in deze DELETE zat.
Er is iets fout gegaan? Hier is een lijst van wat er mis kan zijn gegaan. Welke hiervan is het belangrijkste?
-
Zo was er geen review, d.w.z. de DBA-expert heeft er niet naar gekeken. Hij zou het probleem onmiddellijk vinden met een ervaren oog, en bovendien heeft hij toegang tot prod, waar zich enkele miljoenen regels hebben verzameld.
-
Misschien hebben ze iets verkeerd gecontroleerd.
-
Misschien is de hardware verouderd en moet u deze basis upgraden.
-
Of er is iets mis met de database zelf en we moeten overstappen van Postgres naar MySQL.
-
Of misschien is er iets mis met de operatie.
-
Misschien zijn er enkele fouten in de werkorganisatie en moet u iemand ontslaan en de beste mensen aannemen?
Er was geen DBA-controle. Als er een DBA was, zou hij deze miljoenen regels zien en zelfs zonder experimenten zou hij zeggen: "Dat doen ze niet." Stel dat als deze code zich in GitLab, GitHub zou bevinden en er een codebeoordelingsproces zou zijn en het niet zo zou zijn dat zonder de goedkeuring van de DBA deze operatie op prod zou plaatsvinden, dan zou de DBA natuurlijk zeggen: “Dit kan niet. ”
En hij zou zeggen dat je problemen zult hebben met schijf-IO en dat alle processen gek zullen worden, er kunnen sloten zijn, en ook zul je autovacuüm een aantal minuten blokkeren, dus dit is niet goed.
De tweede fout - ze hebben op de verkeerde plaats ingecheckt. We zagen achteraf dat er veel ongewenste gegevens op prod waren verzameld, maar de ontwikkelaar had geen verzamelde gegevens in deze database en niemand heeft deze ongewenste gegevens gemaakt tijdens de staging. Dienovereenkomstig waren er 1 regels die snel werkten.
We begrijpen dat onze tests zwak zijn, dat wil zeggen dat het proces dat is gebouwd geen problemen opvangt. Er is geen adequaat DB-experiment uitgevoerd.
Een ideaal experiment wordt bij voorkeur uitgevoerd op dezelfde apparatuur. Het is niet altijd mogelijk om dit op dezelfde apparatuur te doen, maar het is erg belangrijk dat het een volledige kopie van de database is. Dit is wat ik nu al een aantal jaren predik. En een jaar geleden had ik het hierover, je kunt het allemaal bekijken op YouTube.
Misschien is onze apparatuur slecht? Als je kijkt, is de latentie gesprongen. We hebben gezien dat de bezetting 100% is. Als dit moderne NVMe-schijven waren, zou het natuurlijk waarschijnlijk veel gemakkelijker voor ons zijn. En misschien zouden we er niet bij neerleggen.
Als je wolken hebt, dan is de upgrade daar eenvoudig te doen. Nieuwe replica's gemaakt op de nieuwe hardware. overschakelen. En alles is goed. Vrij eenvoudig.
Is het mogelijk om op de een of andere manier de kleinere schijven aan te raken? En hier, alleen met behulp van DBA, duiken we in een bepaald onderwerp genaamd checkpoint tuning. Het bleek dat we geen checkpoint-tuning hadden.
Wat is checkpoint? Het zit in elk DBMS. Als u gegevens in het geheugen hebt die veranderen, wordt deze niet onmiddellijk naar schijf geschreven. De informatie dat de gegevens zijn gewijzigd, wordt eerst naar het vooruitschrijflogboek geschreven. En op een gegeven moment besluit het DBMS dat het tijd is om echte pagina's naar schijf te dumpen, zodat we minder REDO kunnen doen als we een storing hebben. Het is als speelgoed. Als we worden gedood, starten we het spel vanaf het laatste checkpoint. En alle DBMS implementeren het.
De instellingen in Postgres blijven achter. Ze zijn ontworpen voor 10-15 jaar oude hoeveelheden gegevens en transacties. En checkpoint is geen uitzondering.
Hier is de informatie uit ons Postgres-controlerapport, d.w.z. automatische gezondheidscontrole. En hier is een database van enkele terabytes. En goed te zien is dat in bijna 90% van de gevallen checkpoints geforceerd zijn.
Wat betekent het? Er zijn daar twee instellingen. Checkpoint kan door time-out komen, bijvoorbeeld over 10 minuten. Of het kan komen wanneer er behoorlijk veel gegevens zijn ingevuld.
En standaard is max_wal_saze ingesteld op 1 gigabyte. In feite gebeurt dit pas echt in Postgres na 300-400 megabytes. Je hebt zoveel gegevens gewijzigd en je checkpoint vindt plaats.
En als niemand het heeft afgestemd, en de service is gegroeid, en het bedrijf verdient veel geld, het heeft veel transacties, dan komt het controlepunt eens per minuut, soms elke 30 seconden, en soms zelfs overlappend. Dit is vrij slecht.
En we moeten ervoor zorgen dat het minder vaak voorkomt. Dat wil zeggen, we kunnen max_wal_size verhogen. En het zal minder vaak voorkomen.
Maar we hebben een hele methodologie ontwikkeld om het correcter te doen, dat wil zeggen, hoe een beslissing te nemen over het kiezen van instellingen, duidelijk gebaseerd op specifieke gegevens.
Daarom doen we twee reeksen experimenten met databases.
De eerste serie - we veranderen max_wal_size. En we doen een enorme operatie. Eerst doen we het op de standaardinstelling van 1 gigabyte. En we doen een massale DELETE van vele miljoenen regels.
Je ziet hoe moeilijk het voor ons is. We zien dat schijf-IO erg slecht is. We kijken hoeveel WAL's we hebben gegenereerd, omdat dit erg belangrijk is. Laten we eens kijken hoe vaak het checkpoint is gebeurd. En we zien dat het niet goed is.
Vervolgens vergroten we max_wal_size. We herhalen. We verhogen, we herhalen. En zo vaak. In principe is 10 punten goed, waarbij 1, 2, 4, 8 gigabyte. En we kijken naar het gedrag van een bepaald systeem. Het is duidelijk dat hier de apparatuur moet zijn zoals op prod. U moet dezelfde schijven, dezelfde hoeveelheid geheugen en dezelfde Postgres-instellingen hebben.
En op deze manier zullen we ons systeem uitwisselen, en we weten hoe het DBMS zich zal gedragen in het geval van een slechte massa DELETE, hoe het zal checkpointen.
Checkpoint in het Russisch zijn checkpoints.
Voorbeeld: DELETE enkele miljoenen rijen per index, rijen zijn "verspreid" over pagina's.
Hier is een voorbeeld. Dit is een basis. En met de standaardinstelling van 1 gigabyte voor max_wal_size, is het heel duidelijk dat onze schijven naar de plank gaan om op te nemen. Deze foto is een typisch symptoom van een erg zieke patiënt, dat wil zeggen dat hij zich echt slecht voelde. En er was één enkele operatie, er was slechts een DELETE van enkele miljoenen regels.
Als zo'n operatie is toegestaan, gaan we gewoon liggen, want het is duidelijk dat één DELETE ons in het regiment doodt.
Verder, waar 16 gigabyte is, is het duidelijk dat de tandjes er al uit zijn. Tanden zijn al beter, dat wil zeggen, we kloppen op het plafond, maar niet zo erg. Er was daar enige vrijheid. Aan de rechterkant is het record. En het aantal bewerkingen - de tweede grafiek. En het is duidelijk dat we met 16 gigabyte al wat makkelijker ademen.
En waar 64 gigabyte aan te zien is dat het helemaal beter is geworden. De tanden zijn al uitgesproken, er zijn meer mogelijkheden om andere operaties te overleven en iets met de schijf te doen.
Hoe komt dat?
Ik zal een beetje in de details duiken, maar dit onderwerp, hoe checkpoint-afstemming moet worden uitgevoerd, kan resulteren in een heel rapport, dus ik zal niet veel laden, maar ik zal een beetje schetsen welke moeilijkheden er zijn.
Als het controlepunt te vaak voorkomt, en we werken onze regels niet sequentieel bij, maar zoeken op index, wat goed is, omdat we niet de hele tabel verwijderen, dan kan het gebeuren dat we eerst de eerste pagina hebben aangeraakt, daarna de duizendste, en keerde toen terug naar de eerste. En als checkpoint tussen deze bezoeken aan de eerste pagina het al op schijf heeft opgeslagen, dan zal het het opnieuw opslaan, omdat we het voor de tweede keer vies hebben gemaakt.
En we zullen checkpoint dwingen om het vele malen op te slaan. Hoe zouden er overbodige operaties voor hem zijn.
Maar dat is nog niet alles. Pagina's zijn 8 kilobytes in Postgres en 4 kilobytes in Linux. En er is een instelling voor full_page_writes. Het is standaard ingeschakeld. En dit klopt, want als we het uitschakelen, bestaat het gevaar dat slechts de helft van de pagina wordt opgeslagen als deze crasht.
Het gedrag van het schrijven naar de WAL van het voorwaartse logboek is zodanig dat wanneer we een checkpoint hebben en we de pagina voor de eerste keer wijzigen, de hele pagina, d.w.z. alle 8 kilobytes, in het voorwaartse logboek terechtkomt, hoewel we alleen de regel, die 100 bytes weegt. En we moeten de hele pagina opschrijven.
Bij volgende wijzigingen zal er alleen een specifieke tuple zijn, maar voor het eerst schrijven we alles op.
En dienovereenkomstig, als het checkpoint opnieuw is gebeurd, moeten we alles opnieuw beginnen en de hele pagina pushen. Met frequente checkpoints, wanneer we door dezelfde pagina's lopen, zal full_page_writes = on meer zijn dan het zou kunnen zijn, d.w.z. we genereren meer WAL. Er wordt meer naar replica's, naar het archief, naar schijf gestuurd.
En dienovereenkomstig hebben we twee ontslagen.
Als we max_wal_size vergroten, blijkt dat we het gemakkelijker maken voor zowel het checkpoint als de wal-schrijver. En dat is geweldig.
Laten we er een terabyte in stoppen en ermee leven. Wat is er slecht aan? Dit is erg, want in het geval van een storing zullen we urenlang klimmen, omdat het checkpoint lang geleden is geweest en er al veel is veranderd. En we moeten dit allemaal REDO doen. En dus doen we de tweede reeks experimenten.
We doen een operatie en zien wanneer het checkpoint bijna voltooid is, we doden -9 Postgres met opzet.
En daarna beginnen we het opnieuw en kijken we hoe lang het op deze apparatuur zal rijzen, d.w.z. hoeveel het in deze slechte situatie OPNIEUW zal doen.
Twee keer zal ik opmerken dat de situatie slecht is. Ten eerste crashten we vlak voordat het checkpoint voorbij was, dus we hebben veel te verliezen. En ten tweede hadden we een enorme operatie. En als checkpoints een time-out hadden, dan zou er hoogstwaarschijnlijk minder WAL worden gegenereerd sinds het laatste checkpoint. Dat wil zeggen, het is een dubbele verliezer.
We meten een dergelijke situatie voor verschillende maten van max_wal_size en begrijpen dat als max_wal_size 64 gigabyte is, we in het dubbele slechtste geval gedurende 10 minuten zullen klimmen. En we denken na of het bij ons past of niet. Dit is een zakelijke vraag. We moeten dit beeld laten zien aan degenen die verantwoordelijk zijn voor zakelijke beslissingen en vragen: “Hoe lang kunnen we maximaal blijven liggen in geval van een probleem? Kunnen we in de slechtste situatie 3-5 minuten gaan liggen? En je neemt een besluit.
En hier is een interessant punt. We hebben een paar rapporten over Patroni op de conferentie. En misschien maak je er wel gebruik van. Dit is een automatische failover voor Postgres. GitLab en Data Egret spraken hierover.
En als je een autofailover hebt die binnen 30 seconden komt, kunnen we dan misschien 10 minuten gaan liggen? Omdat we op dit punt naar de replica zullen overschakelen, en alles komt goed. Dit is een betwistbaar punt. Ik weet geen duidelijk antwoord. Ik heb gewoon het gevoel dat dit onderwerp niet alleen over crashherstel gaat.
Als we na een mislukking lang herstellen, zullen we ons in veel andere situaties ongemakkelijk voelen. Bijvoorbeeld in dezelfde experimenten, wanneer we iets doen en soms 10 minuten moeten wachten.
Ik zou nog steeds niet te ver gaan, zelfs als we een autofailover hebben. In de regel zijn waarden zoals 64, 100 gigabytes goede waarden. Soms is het zelfs de moeite waard om minder te kiezen. Over het algemeen is dit een subtiele wetenschap.
Om iteraties uit te voeren, bijvoorbeeld max_wal_size =1, 8, moet u de massabewerking vele malen herhalen. Je hebt het gehaald. En op dezelfde basis wil je het nog een keer doen, maar je hebt alles al verwijderd. Wat moeten we doen?
Ik zal later praten over onze oplossing, wat we doen om in dergelijke situaties te herhalen. En dit is de meest correcte benadering.
Maar in dit geval hadden we geluk. Als, zoals hier staat "BEGIN, DELETE, ROLLBACK", dan kunnen we DELETE herhalen. Dat wil zeggen, als we het zelf hebben geannuleerd, kunnen we het herhalen. En fysiek bij jou zullen de gegevens op dezelfde plek liggen. Je krijgt niet eens een opgeblazen gevoel. U kunt dergelijke DELETE's herhalen.
Deze DELETE met ROLLBACK is ideaal voor het afstemmen van checkpoints, zelfs als u geen correct geïmplementeerde databaselabs heeft.
We hebben een bord gemaakt met één kolom "i". Postgres heeft hulpkolommen. Ze zijn onzichtbaar, tenzij er specifiek om wordt gevraagd. Dit zijn: ctid, xmid, xmax.
Ctid is een fysiek adres. Nulpagina, de eerste tuple op de pagina.
Het is te zien dat na ROOLBACK de tuple op dezelfde plaats bleef. Dat wil zeggen, we kunnen het opnieuw proberen, het zal zich op dezelfde manier gedragen. Dit is het belangrijkste.
Xmax is het tijdstip van overlijden van de tupel. Het is gestempeld, maar Postgres weet dat de transactie is teruggedraaid, dus het maakt niet uit of het 0 is of dat het een teruggedraaide transactie is. Dit suggereert dat het mogelijk is om DELETE te herhalen en de bulkbewerkingen van het systeemgedrag te controleren. Je kunt databaselabs maken voor de armen.
Dit gaat over programmeurs. Ook over DBA schelden ze programmeurs hier altijd op uit: “Waarom doe je zulke lange en moeilijke operaties?”. Dit is een heel ander loodrecht onderwerp. Vroeger was er administratie, nu komt er ontwikkeling.
Het is duidelijk dat we niet in stukken zijn gebroken. Het is duidelijk. Het is onmogelijk om zo'n DELETE niet voor een hoop miljoenen regels in delen op te splitsen. Het duurt 20 minuten en alles gaat liggen. Maar helaas maken zelfs ervaren ontwikkelaars fouten, zelfs in zeer grote bedrijven.
Waarom is het belangrijk om te breken?
-
Als we zien dat de schijf hard is, laten we hem dan vertragen. En als we kapot zijn, kunnen we pauzes toevoegen, we kunnen het vertragen vertragen.
-
En we zullen anderen lange tijd niet blokkeren. In sommige gevallen maakt het niet uit, als je echte rotzooi verwijdert waar niemand aan werkt, dan blokkeer je hoogstwaarschijnlijk niemand behalve het autovacuümwerk, omdat het zal wachten tot de transactie is voltooid. Maar als je iets verwijdert waar iemand anders om kan vragen, dan worden ze geblokkeerd, er ontstaat een soort kettingreactie. Lange transacties moeten worden vermeden op websites en mobiele applicaties.
Dit is interessant. Ik zie vaak dat ontwikkelaars vragen: "Welke verpakkingsgrootte moet ik kiezen?".
Het is duidelijk dat hoe groter de bundelgrootte, hoe kleiner de transactieoverhead, d.w.z. de extra overhead van transacties. Maar tegelijkertijd neemt de tijd toe voor deze transactie.
Ik heb een heel eenvoudige regel: neem zoveel als je kunt, maar ga niet over uitvoerbare bestanden per seconde.
Waarom een seconde? De uitleg is heel eenvoudig en begrijpelijk voor iedereen, zelfs niet-technische mensen. We zien een reactie. Laten we 50 milliseconden nemen. Als er iets is veranderd, dan zal ons oog reageren. Is het minder, dan is het moeilijker. Als iets bijvoorbeeld na 100 milliseconden reageert, je hebt met de muis geklikt en het antwoordt na 100 milliseconden, voel je deze kleine vertraging al. Een seconde wordt al als remmen ervaren.
Dienovereenkomstig, als we onze massale operaties opsplitsen in bursts van 10 seconden, lopen we het risico dat we iemand blokkeren. En het zal een paar seconden werken, en mensen zullen het al opmerken. Daarom doe ik liever niet langer dan een seconde. Maar verdeel het tegelijkertijd niet heel fijn, want de overhead van de transactie zal merkbaar zijn. De basis zal harder zijn en er kunnen andere verschillende problemen ontstaan.
We kiezen de grootte van het pakket. In elk geval kunnen we het anders doen. Kan worden geautomatiseerd. En we zijn overtuigd van de efficiëntie van de verwerking van één pak. Dat wil zeggen, we verwijderen één pakket of UPDATE.
Overigens gaat alles waar ik het over heb niet alleen over VERWIJDEREN. Zoals u al vermoedde, zijn dit bulkbewerkingen op gegevens.
En we zien dat het plan uitstekend is. U kunt de indexscan zien, alleen indexscan is zelfs nog beter. En we hebben een kleine hoeveelheid gegevens. En minder dan een seconde vervult. Super.
En we moeten er nog steeds voor zorgen dat er geen degradatie plaatsvindt. Het komt voor dat de eerste pakketten snel werken, en dan wordt het erger, erger en erger. Het proces is zodanig dat je veel moet testen. Dit is precies waar databaselabs voor zijn.
En we moeten nog iets voorbereiden zodat we dit in productie correct kunnen volgen. We kunnen bijvoorbeeld de tijd in het logboek schrijven, we kunnen schrijven waar we nu zijn en wie we nu hebben verwijderd. En dit zal ons in staat stellen om te begrijpen wat er later gebeurt. En als er iets misgaat, vind dan snel het probleem.
Als we de efficiëntie van verzoeken moeten controleren en we moeten vaak herhalen, dan bestaat er zoiets als een mede-bot. Hij is al klaar. Het wordt dagelijks door tientallen ontwikkelaars gebruikt. En hij weet hoe hij een enorme terabyte database op aanvraag in 30 seconden jouw eigen exemplaar kan geven. En je kunt daar iets verwijderen en RESET zeggen, en het weer verwijderen. Je kunt er op deze manier mee experimenteren. Ik zie een toekomst voor dit ding. En we doen het al.
Wat zijn partitiestrategieën? Ik zie 3 verschillende partitioneringsstrategieën die de ontwikkelaars van het pakket gebruiken.
De eerste is heel eenvoudig. We hebben een numerieke ID. En laten we het opsplitsen in verschillende intervallen en daarmee werken. De keerzijde is duidelijk. In het eerste segment kunnen we 100 regels echte rommel hebben, in de tweede 5 regels of helemaal niet, of alle 1 regels zullen rommel blijken te zijn. Zeer ongelijk werk, maar het is gemakkelijk te breken. Ze namen het maximale ID en sloegen het kapot. Dit is een naïeve benadering.
De tweede strategie is een evenwichtige benadering. Het wordt gebruikt in Gitlab. Ze namen en scanden de tafel. We hebben de grenzen van de ID-pakketten gevonden, zodat elk pakket precies 10 records had. En zet ze in de rij. En dan verwerken we. Je kunt dit in meerdere threads doen.
Ook bij de eerste strategie kun je dit overigens in meerdere threads doen. Het is niet moeilijk.
Maar er is een coolere en betere aanpak. Dit is de derde strategie. En als het mogelijk is, is het beter om ervoor te kiezen. Dit doen wij aan de hand van een speciale index. In dit geval zal het hoogstwaarschijnlijk een index zijn volgens onze afvalconditie en ID. We voegen de ID toe zodat het alleen een indexscan is, zodat we niet naar de heap gaan.
Over het algemeen is alleen index scannen sneller dan index scannen.
En we vinden snel onze ID's die we willen verwijderen. BATCH_SIZE selecteren we van tevoren. En we krijgen ze niet alleen, we krijgen ze op een speciale manier en hacken ze meteen. Maar we vergrendelen zodat als ze al op slot zijn, we ze niet op slot doen, maar verder gaan en de volgende nemen. Dit is voor het overslaan van updates vergrendeld. Deze superfunctie van Postgres stelt ons in staat om in verschillende threads te werken als we dat willen. Het kan in één stroom. En hier is er een CTE - dit is één verzoek. En we hebben een echte verwijdering gaande op de tweede verdieping van deze CTE - returning *. U kunt id retourneren, maar het is beter *als u niet veel gegevens op elke regel hebt.
Waarom hebben we het nodig? Dit is wat we terug moeten melden. We hebben nu in feite zoveel regels verwijderd. En we hebben grenzen op ID of op deze manier. Je kunt min, max. Er kan iets anders worden gedaan. Je kunt hier heel veel kwijt. En het is erg handig voor monitoring.
Er is nog een opmerking over de index. Als we besluiten dat we een speciale index nodig hebben voor deze taak, dan moeten we ervoor zorgen dat het niet alleen heap tuples-updates bederft. Dat wil zeggen, Postgres heeft dergelijke statistieken. Dit is te zien in pg_stat_user_tables voor uw tabel. U kunt zien of er hot updates worden gebruikt of niet.
Er zijn situaties waarin uw nieuwe index ze gewoon kan afsnijden. En je hebt alle andere updates die al werken, vertragen. Niet alleen omdat de index verscheen (elke index vertraagt updates een beetje, maar een beetje), maar hier verpest het het nog steeds. En het is onmogelijk om speciale optimalisatie voor deze tabel te maken. Dit gebeurt soms. Dit is zo'n subtiliteit die maar weinig mensen onthouden. En deze hark is gemakkelijk om op te stappen. Soms gebeurt het dat je een benadering van de andere kant moet vinden en toch deze nieuwe index moet missen, of een andere index moet maken, of op een andere manier, je kunt bijvoorbeeld de tweede methode gebruiken.
Maar dit is de meest optimale strategie, hoe te splitsen in batches en met één verzoek op batches te schieten, een klein beetje te verwijderen, enz.
Lange transacties
Geblokkeerde autovacuüm -
probleem met blokkeren -
Fout #5 is een grote. Nikolai van Okmeter sprak over Postgres-monitoring. Ideale Postgres-monitoring bestaat helaas niet. Sommige zijn dichterbij, sommige zijn verder weg. Okmeter is bijna perfect, maar er ontbreekt veel en moet worden toegevoegd. Je moet hier klaar voor zijn.
Dode tupels kunnen bijvoorbeeld het beste worden gecontroleerd. Als je veel dode dingen in de tabel hebt, dan is er iets mis. Het is beter om nu te reageren, anders kan er degradatie optreden en kunnen we gaan liggen. Het gebeurt.
Als er een grote IO is, dan is het duidelijk dat dit niet goed is.
Ook lange transacties. Lange transacties mogen niet worden toegestaan op OLTP. En hier is een link naar een fragment waarmee u dit fragment kunt nemen en al wat lange transacties kunt volgen.
Waarom zijn lange transacties slecht? Omdat alle sloten pas aan het einde worden vrijgegeven. En we naaien iedereen. Bovendien blokkeren we autovacuüm voor alle tafels. Het is helemaal niet goed. Zelfs als je hot standby hebt ingeschakeld op de replica, is het nog steeds slecht. Over het algemeen is het nergens beter om lange transacties te vermijden.
Als we veel tafels hebben die niet gestofzuigd zijn, dan moeten we een melding hebben. Hier is zo'n situatie mogelijk. We kunnen indirect de werking van autovacuüm beïnvloeden. Dit is een fragment uit Avito, dat ik enigszins heb verbeterd. En het bleek een interessant hulpmiddel om te zien wat we hebben met autovacuüm. Sommige tafels wachten daar bijvoorbeeld en wachten niet op hun beurt. Je moet het ook in monitoring plaatsen en een waarschuwing hebben.
En geeft blokken uit. Bos van blokbomen. Ik neem graag iets van iemand over en verbeter het. Hier nam ik een coole recursieve CTE van Data Egret die een bos van sluisbomen laat zien. Dit is een goed diagnostisch hulpmiddel. En op basis daarvan kun je ook monitoring bouwen. Maar dit moet zorgvuldig gebeuren. Je moet een kleine statement_timeout voor jezelf maken. En lock_timeout is wenselijk.
Soms komen al deze fouten bij elkaar op.
Naar mijn mening is de grootste fout hier organisatorisch. Het is organisatorisch, want de techniek trekt niet. Dit is nummer 2 - ze hebben op de verkeerde plaats ingecheckt.
We hebben op de verkeerde plaats ingecheckt, omdat we geen productiekloon hadden, wat gemakkelijk te controleren is. Een ontwikkelaar heeft mogelijk helemaal geen toegang tot productie.
En we hebben daar niet gecontroleerd. Als we daar hadden gekeken, hadden we het zelf gezien. De ontwikkelaar zag het allemaal zelfs zonder een DBA als hij het in een goede omgeving controleerde, waar dezelfde hoeveelheid gegevens en een identieke locatie is. Hij zou al deze degradatie hebben gezien en hij zou zich schamen.
Meer over autovacuüm. Nadat we een massale sweep van enkele miljoenen regels hebben gedaan, moeten we nog steeds REPACK doen. Dit is vooral belangrijk voor indexen. Ze zullen zich slecht voelen nadat we alles daar hebben schoongemaakt.
En als je het dagelijkse schoonmaakwerk terug wilt halen, dan zou ik voorstellen om het vaker te doen, maar dan kleiner. Het kan een keer per minuut zijn of zelfs vaker een klein beetje. En je moet twee dingen in de gaten houden: dat dit ding geen fouten bevat en dat het niet achterblijft. De truc die ik liet zien lost dit gewoon op.
Wat wij doen is open source. Het is gepost op GitLab. En we zorgen ervoor dat mensen ook zonder DBA kunnen controleren. We doen een databaselab, dat wil zeggen, we noemen de basiscomponent waaraan Joe momenteel werkt. En je kunt een kopie van de productie pakken. Nu is er een implementatie van Joe voor speling, je kunt daar zeggen: "leg dat en dat verzoek uit" en krijg meteen het resultaat voor je kopie van de database. Je kunt daar zelfs VERWIJDEREN, en niemand zal het opmerken.
Laten we zeggen dat je 10 terabyte hebt, we maken database lab ook 10 terabyte. En met gelijktijdige databases van 10 terabyte kunnen 10 ontwikkelaars tegelijkertijd werken. Iedereen kan doen wat hij wil. Kan verwijderen, neerzetten, enz. Dat is zo'n fantasie. We zullen hier morgen over praten.
Dit wordt thin provisioning genoemd. Dit is een subtiele bevoorrading. Dit is een soort fantasie die vertragingen in ontwikkeling en testen aanzienlijk wegneemt en de wereld in dit opzicht een betere plek maakt. Dat wil zeggen, hiermee kunt u problemen met bulkbewerkingen voorkomen.
Voorbeeld: database van 5 terabyte, een kopie in minder dan 30 seconden. En het hangt niet eens af van de grootte, dat wil zeggen, het maakt niet uit hoeveel terabytes.
Vandaag kun je naar en duik in onze tools. U kunt zich registreren om te zien wat er is. Je kunt deze bot installeren. Het is gratis. Schrijven.
vragen
Heel vaak blijkt in reële situaties dat de gegevens die in de tabel moeten blijven, veel minder zijn dan wat moet worden verwijderd. Dat wil zeggen, in een dergelijke situatie is het vaak gemakkelijker om een dergelijke benadering te implementeren, wanneer het gemakkelijker is om een nieuw object te maken, alleen de benodigde gegevens daarheen te kopiëren en de oude tabel te trunkeren. Het is duidelijk dat er op dit moment een programmatische aanpak nodig is, terwijl je gaat switchen. Hoe is deze aanpak?
Dit is een zeer goede aanpak en een zeer goede taak. Het lijkt erg op wat pg_repack doet, het lijkt erg op wat je moet doen als je ID's van 4 bytes maakt. Veel frameworks deden dit een paar jaar geleden, en alleen de platen zijn volwassen geworden en moeten worden geconverteerd naar 8 bytes.
Deze taak is vrij moeilijk. We hebben het gedaan. En je moet heel voorzichtig zijn. Er zijn sloten etc. Maar er wordt aan gewerkt. Dat wil zeggen, de standaardbenadering is om te gaan met pg_repack. U declareert zo'n label. En voordat u begint met het uploaden van momentopnamegegevens, declareert u ook één plaat die alle wijzigingen bijhoudt. Er is een truc dat je sommige wijzigingen misschien niet eens bijhoudt. Er zijn subtiliteiten. En dan wissel je door middel van rollende wissels. Er zal een korte pauze zijn wanneer we iedereen afsluiten, maar over het algemeen wordt dit gedaan.
Als je kijkt naar pg_repack op GitHub, dan was er, toen er een taak was om een ID van int 4 naar int 8 te converteren, een idee om pg_repack zelf te gebruiken. Dit is ook mogelijk, maar het is een beetje een hack, maar hier zal het ook voor werken. U kunt ingrijpen in de trigger die pg_repack gebruikt en daar zeggen: "We hebben deze gegevens niet nodig", d.w.z. we dragen alleen over wat we nodig hebben. En dan schakelt hij gewoon over en dat is alles.
Met deze aanpak krijgen we toch een tweede kopie van de tabel, waarin de gegevens al zijn geïndexeerd en zeer gelijkmatig zijn gestapeld met prachtige indexen.
Bloat is niet aanwezig, het is een goede aanpak. Maar ik weet dat er pogingen zijn om hiervoor een automatisering te ontwikkelen, d.w.z. een universele oplossing te maken. Ik kan u in contact brengen met deze automatisering. Het is geschreven in Python, wat een goede zaak is.
Ik kom maar een klein beetje uit de wereld van MySQL, dus ik kwam luisteren. En we gebruiken deze aanpak.
Maar het is alleen als we 90% hebben. Als we 5% hebben, is het niet erg goed om het te gebruiken.
Bedankt voor het verslag! Als er geen bronnen zijn om een volledige kopie van de productie te maken, is er dan een algoritme of formule om de belasting of grootte te berekenen?
Goede vraag. Tot nu toe kunnen we databases van meerdere terabytes vinden. Ook al is de hardware daar niet hetzelfde, bijvoorbeeld minder geheugen, minder processor en schijven zijn niet precies hetzelfde, maar toch doen we het. Als er absoluut nergens is, moet je nadenken. Laat me nadenken tot morgen, je bent gekomen, we zullen praten, dit is een goede vraag.
Bedankt voor het verslag! Je begon eerst over het feit dat er een coole Postgres is, die die en die beperkingen heeft, maar die zich ontwikkelt. En dit is over het algemeen allemaal een kruk. Is dit niet allemaal in strijd met de ontwikkeling van Postgres zelf, waarin een DELETE deferent zal verschijnen of iets anders dat op een laag niveau zou moeten houden wat we hier met onze vreemde middelen proberen te smeren?
Als we in SQL zouden zeggen om veel records in één transactie te verwijderen of bij te werken, hoe kan Postgres het dan daar distribueren? We zijn fysiek beperkt in operaties. We zullen het nog lang doen. En we zullen op dit moment vergrendelen, enz.
Gedaan met indexen.
Ik kan aannemen dat dezelfde checkpoint-afstemming kan worden geautomatiseerd. Op een dag zou het kunnen zijn. Maar dan begrijp ik de vraag niet zo goed.
De vraag is, is er zo'n vector van ontwikkeling die hier en daar gaat, en hier gaat die van jou parallel? Die. Hebben ze er nog niet over nagedacht?
Ik sprak over de principes die nu kunnen worden gebruikt. Er is nog een robot , hiermee kun je geautomatiseerde checkpoint-tuning doen. Zal het ooit in Postgres zijn? Ik weet het niet, het is nog niet eens besproken. Daar zijn we nog ver van verwijderd. Maar er zijn wetenschappers die nieuwe systemen maken. En ze duwen ons in automatische indexen. Er zijn ontwikkelingen. U kunt bijvoorbeeld kijken naar automatisch afstemmen. Het selecteert parameters automatisch. Maar hij zal nog geen checkpoint-tuning voor je doen. Dat wil zeggen, het zal verbeteren voor prestaties, shell-buffer, enz.
En voor het afstemmen van checkpoints kunt u dit doen: als u duizend clusters en verschillende hardware, verschillende virtuele machines in de cloud heeft, kunt u onze bot gebruiken automatisering doen. En max_wal_size wordt automatisch geselecteerd op basis van uw doelinstellingen. Maar tot nu toe komt dit helaas niet eens in de buurt van de kern.
Goedemiddag U had het over de gevaren van lange transacties. U zei dat autovacuüm wordt geblokkeerd in geval van verwijderingen. Hoe kan het ons anders schaden? Omdat we het meer hebben over het vrijmaken van ruimte en het kunnen gebruiken ervan. Wat missen we nog meer?
Autovacuüm is hier misschien niet het grootste probleem. En het feit dat een lange transactie andere transacties kan vergrendelen, deze mogelijkheid is gevaarlijker. Ze kan elkaar wel of niet ontmoeten. Als ze elkaar heeft ontmoet, kan het heel erg zijn. En met autovacuüm - dit is ook een probleem. Er zijn twee problemen met lange transacties in OLTP: sloten en autovacuüm. En als u hot standby-feedback hebt ingeschakeld op de replica, ontvangt u nog steeds een autovacuümvergrendeling op de master, deze komt uit de replica. Maar er zullen tenminste geen sloten zijn. En er zullen loks zijn. We hebben het over gegevenswijzigingen, dus sloten zijn hier een belangrijk punt. En als dit allemaal voor een lange, lange tijd is, dan worden steeds meer transacties vergrendeld. Ze kunnen anderen stelen. En lokbomen verschijnen. Ik heb een link naar het fragment gegeven. En dit probleem wordt sneller merkbaar dan het probleem met autovacuüm, dat zich alleen maar kan ophopen.
Bedankt voor het verslag! U begon uw melding door te zeggen dat u verkeerd hebt getest. We gingen door met ons idee dat we dezelfde apparatuur moeten nemen, met de basis op dezelfde manier. Laten we zeggen dat we de ontwikkelaar een basis hebben gegeven. En hij voldeed aan het verzoek. En hij lijkt in orde te zijn. Maar hij checkt niet voor live, maar voor live hebben we bijvoorbeeld een belasting van 60-70%. En zelfs als we deze afstemming gebruiken, werkt het niet erg goed.
Het is belangrijk om een expert in het team te hebben en DBA-experts te gebruiken die kunnen voorspellen wat er zal gebeuren met een echte achtergrondbelasting. Als we net onze schone veranderingen hebben doorgevoerd, zien we de foto. Maar een meer geavanceerde benadering, toen we hetzelfde opnieuw deden, maar met een belasting gesimuleerd met productie. Het is best gaaf. Tot die tijd moet je volwassen worden. Het is als een volwassene. We hebben alleen gekeken naar wat we hebben en ook gekeken of we genoeg middelen hebben. Dat is een goede vraag.
Wanneer we al bezig zijn met een vuilnisselectie en we hebben bijvoorbeeld een verwijderde vlag
Dit is wat autovacuum automatisch doet in Postgres.
O, doet hij het?
Autovacuum is de vuilnisman.
Dank je wel!
Bedankt voor het verslag! Is er een optie om direct een database met partitionering zo in te richten dat al het afval van de hoofdtabel ergens aan de zijkant vies wordt?
Natuurlijk.
Is het dan mogelijk om onszelf te beschermen als we een tafel hebben afgesloten die niet gebruikt mag worden?
Natuurlijk hebben. Maar het is als een kip en het ei vraag. Als we allemaal weten wat er in de toekomst gaat gebeuren, dan gaan we natuurlijk alles cool doen. Maar het bedrijf verandert, er zijn nieuwe kolommen, nieuwe verzoeken. En dan – oeps, we willen het verwijderen. Maar deze ideale situatie komt in het leven voor, maar niet altijd. Maar over het algemeen is het een goed idee. Gewoon inkorten en dat is alles.
Bron: www.habr.com