Iewers in die verre toekoms sal die outomatiese verwydering van onnodige data een van die belangrike take van die DBBS wees [1]. Intussen moet ons self sorg vir die uitvee of skuif van onnodige data na minder duur bergingstelsels. Kom ons sê jy besluit om 'n paar miljoen rye uit te vee. 'n Redelik eenvoudige taak, veral as die toestand bekend is en daar 'n geskikte indeks is. "DELETE FROM table1 WHERE col1 = :value" - wat kan eenvoudiger wees, reg?
Video:
-
Ek is sedert die eerste jaar op die Highload-programkomitee, dit wil sê sedert 2007.
-
En ek is sedert 2005 by Postgres. Het dit in baie projekte gebruik.
-
Groepeer ook sedert 2007 met RuPostges.
-
Ons het gegroei tot 2100+ deelnemers by Meetup. Dit is tweede in die wêreld ná New York, wat lank deur San Francisco ingehaal is.
-
Ek woon al 'n paar jaar in Kalifornië. Ek het meer te doen met Amerikaanse maatskappye, insluitend groot maatskappye. Hulle is aktiewe gebruikers van Postgres. En daar is allerhande interessante dinge.
is my maatskappy. Ons is besig om take te outomatiseer wat ontwikkelingsvertragings uitskakel.
As jy iets doen, dan is daar soms 'n soort proppe rondom Postgres. Kom ons sê jy moet wag vir die admin om 'n toetsstand vir jou op te stel, of jy moet wag dat die DBA op jou reageer. En ons vind sulke knelpunte in die ontwikkeling-, toets- en administrasieproses en probeer dit uitskakel met behulp van outomatisering en nuwe benaderings.
Ek was onlangs by VLDB in Los Angeles. Dit is die grootste konferensie oor databasisse. En daar was 'n berig dat DBMS in die toekoms nie net data sal stoor nie, maar ook outomaties sal uitvee. Dit is 'n nuwe onderwerp.
Daar is meer en meer data in die wêreld van zettagrepe – dit is 1 000 000 petagrepe. En nou word daar reeds beraam dat ons meer as 100 zettagrepe data in die wêreld gestoor het. En daar is meer en meer van hulle.
En wat om daarmee te doen? Dit is duidelik dat dit verwyder moet word. Hier is 'n skakel na hierdie interessante verslag. Maar tot dusver is dit nie in die DBBS geïmplementeer nie.
Diegene wat geld kan tel, wil twee dinge hê. Hulle wil hê ons moet uitvee, so tegnies behoort ons dit te kan doen.
Wat ek volgende sal vertel, is een of ander abstrakte situasie wat 'n klomp werklike situasies insluit, dit wil sê 'n soort samestelling van wat eintlik baie keer, baie jare met my en die omliggende databasisse gebeur het. Harke is oral en almal trap heeltyd daarop.
Kom ons sê ons het 'n basis of verskeie basisse wat groei. En sommige rekords is natuurlik gemors. Die gebruiker het byvoorbeeld iets daar begin doen, maar dit nie voltooi nie. En na 'n rukkie weet ons dat hierdie onvoltooide nie meer gestoor kan word nie. Dit wil sê, ons wil graag 'n paar vullisgoed skoonmaak om spasie te bespaar, werkverrigting te verbeter, ens.
Oor die algemeen is die taak om die verwydering van spesifieke dinge, spesifieke lyne in een of ander tabel te outomatiseer.
En ons het so 'n versoek, waaroor ons vandag sal praat, dit wil sê oor vullisverwydering.
Ons het 'n ervare ontwikkelaar gevra om dit te doen. Hy het hierdie versoek geneem, dit self nagegaan – alles werk. Getoets op verhoog – alles is in orde. Uitgerol - alles werk. Een keer per dag hardloop ons dit - alles is reg.
Die databasis groei en groei. Daily DELETE begin 'n bietjie stadiger werk.
Dan verstaan ons dat ons nou 'n bemarkingsmaatskappy het en die verkeer 'n paar keer groter sal wees, daarom besluit ons om onnodige dinge tydelik te onderbreek. En vergeet om terug te keer.
’n Paar maande later het hulle onthou. En daardie ontwikkelaar het opgehou of met iets anders besig is, 'n ander opdrag gegee om dit terug te gee.
Hy het gekyk op ontwikkelaar, op verhoog – alles is reg. Natuurlik moet jy nog skoonmaak wat opgehoop het. Hy het gekontroleer alles werk.
Wat gebeur volgende? Dan val alles vir ons uitmekaar. Dit val so dat alles op 'n stadium val. Almal is in skok, niemand verstaan wat aan die gebeur is nie. En dan blyk dit dat die saak in hierdie DELETE was.
Iets het verkeerd geloop? Hier is 'n lys van wat verkeerd kon gegaan het. Watter hiervan is die belangrikste?
-
Daar was byvoorbeeld geen resensie nie, dit wil sê die DBA-deskundige het nie daarna gekyk nie. Hy sou dadelik die probleem met 'n ervare oog vind, en boonop het hy toegang tot prod, waar 'n paar miljoen lyne opgehoop het.
-
Miskien het hulle iets verkeerd nagegaan.
-
Miskien is die hardeware verouderd en moet jy hierdie basis opgradeer.
-
Of iets is fout met die databasis self, en ons moet van Postgres na MySQL beweeg.
-
Of dalk is daar iets fout met die operasie.
-
Miskien is daar 'n paar foute in die organisasie van werk en moet jy iemand afdank en die beste mense aanstel?
Daar was geen DBA-tjek nie. As daar 'n DBA was, sou hy hierdie etlike miljoen reëls sien en selfs sonder enige eksperimente sou sê: "Hulle doen dit nie." Gestel as hierdie kode in GitLab, GitHub was en daar 'n kode-hersieningsproses sou wees en dit was nie so dat sonder die goedkeuring van die DBA hierdie bewerking op prod sou plaasvind nie, dan sou die DBA natuurlik sê: "Dit kan nie gedoen word nie. ”
En hy sou sê dat jy probleme met skyf IO sal hê en alle prosesse sal mal word, daar kan slotte wees, en jy sal ook outovakuum blokkeer vir 'n klomp minute, so dit is nie goed nie.
Die tweede fout - hulle het op die verkeerde plek nagegaan. Ons het ná die feit gesien dat baie gemorsdata op prod opgehoop het, maar die ontwikkelaar het nie opgehoopte data in hierdie databasis gehad nie, en niemand het hierdie gemors tydens die opvoering geskep nie. Gevolglik was daar 1 000 reëls wat vinnig uitgewerk het.
Ons verstaan dat ons toetse swak is, dit wil sê die proses wat gebou word, vang nie probleme op nie. 'n Voldoende DB-eksperiment is nie uitgevoer nie.
'n Ideale eksperiment word verkieslik op dieselfde toerusting uitgevoer. Dit is nie altyd moontlik om dit op dieselfde toerusting te doen nie, maar dit is baie belangrik dat dit 'n volgrootte kopie van die databasis is. Dit is wat ek nou al vir etlike jare verkondig. En 'n jaar gelede het ek hieroor gepraat, jy kan dit alles op YouTube kyk.
Dalk is ons toerusting sleg? As jy kyk, dan het die latency gespring. Ons het gesien dat benutting 100% is. Natuurlik, as dit moderne NVMe-aandrywers was, sou dit waarskynlik vir ons baie makliker wees. En miskien sou ons nie daarvan gaan lê nie.
As jy wolke het, word die opgradering maklik daar gedoen. Nuwe replikas op die nuwe hardeware opgestel. oorskakeling. En alles is goed. Redelik maklik.
Is dit moontlik om op een of ander manier aan die kleiner skywe te raak? En hier, net met die hulp van DBA, duik ons in 'n sekere onderwerp genaamd checkpoint tuning. Dit blyk dat ons nie kontrolepuntinstelling gehad het nie.
Wat is kontrolepunt? Dit is in enige DBBS. Wanneer jy data in die geheue het wat verander, word dit nie dadelik na skyf geskryf nie. Die inligting dat die data verander het, word eers na die vooruitskryf-log geskryf. En op 'n sekere punt besluit die DBBS dat dit tyd is om regte bladsye na skyf te dump, sodat as ons 'n mislukking het, ons minder HERDOEN kan doen. Dit is soos 'n speelding. As ons doodgemaak word, sal ons die wedstryd vanaf die laaste kontrolepunt begin. En alle DBMS implementeer dit.
Die instellings in Postgres bly agter. Hulle is ontwerp vir 10-15 jaar oue volumes data en transaksies. En kontrolepunt is geen uitsondering nie.
Hier is die inligting uit ons Postgres-kontroleverslag, dit wil sê outomatiese gesondheidsondersoek. En hier is 'n databasis van verskeie teragrepe. En dit kan goed gesien word dat gedwonge kontrolepunte in byna 90% van die gevalle.
Wat beteken dit? Daar is twee instellings daar. Kontrolepunt kan byvoorbeeld binne 10 minute met time-out kom. Of dit kan kom wanneer heelwat data ingevul is.
En by verstek is max_wal_saze op 1 gigagreep gestel. Trouens, dit gebeur regtig in Postgres na 300-400 megagrepe. Jy het soveel data verander en jou kontrolepunt gebeur.
En as niemand dit ingestel het nie, en die diens het gegroei, en die maatskappy verdien baie geld, het dit baie transaksies, dan kom die kontrolepunt een keer per minuut, soms elke 30 sekondes, en soms selfs oorvleuel. Dit is nogal erg.
En ons moet seker maak dat dit minder gereeld kom. Dit wil sê, ons kan max_wal_size verhoog. En dit sal minder gereeld kom.
Maar ons het 'n hele metodologie ontwikkel vir hoe om dit meer korrek te doen, dit wil sê hoe om 'n besluit te neem oor die keuse van instellings, duidelik gebaseer op spesifieke data.
Gevolglik doen ons twee reekse eksperimente op databasisse.
Die eerste reeks - ons verander max_wal_size. En ons doen 'n massiewe operasie. Eerstens doen ons dit op die verstekinstelling van 1 gigagreep. En ons doen 'n massiewe DELETE van baie miljoene lyne.
Jy kan sien hoe moeilik dit vir ons is. Ons sien dat skyf IO baie sleg is. Ons kyk hoeveel WAL's ons gegenereer het, want dit is baie belangrik. Kom ons kyk hoeveel keer die kontrolepunt gebeur het. En ons sien dat dit nie goed is nie.
Volgende verhoog ons max_wal_size. Ons herhaal. Ons verhoog, ons herhaal. En soveel keer. In beginsel is 10 punte goed, waar 1, 2, 4, 8 gigagrepe. En ons kyk na die gedrag van 'n bepaalde stelsel. Dit is duidelik dat die toerusting hier moet wees soos op prod. Jy moet dieselfde skywe, dieselfde hoeveelheid geheue en dieselfde Postgres-instellings hê.
En op hierdie manier sal ons ons stelsel uitruil, en ons weet hoe die DBMS sal optree in die geval van 'n slegte massa DELETE, hoe dit kontrolepunt sal wees.
Kontrolepunt in Russies is kontrolepunte.
Voorbeeld: SKEE 'n paar miljoen rye uit volgens indeks, rye is "verstrooi" oor bladsye.
Hier is 'n voorbeeld. Dit is een of ander basis. En met die verstekinstelling van 1 gigagreep vir max_wal_size, is dit baie duidelik dat ons skywe na die rak gaan vir opname. Hierdie prentjie is 'n tipiese simptoom van 'n baie siek pasiënt, dit wil sê, hy het regtig sleg gevoel. En daar was een enkele operasie, daar was net 'n DELETE van etlike miljoen reëls.
As so 'n operasie in prod toegelaat word, dan gaan lê ons maar, want dit is duidelik dat een DELETE ons in die regiment doodmaak.
Verder, waar 16 gigagrepe, is dit duidelik dat die tande reeds weg is. Tande is al beter, dit wil sê, ons klop aan die plafon, maar nie so erg nie. Daar was 'n mate van vryheid. Aan die regterkant is die rekord. En die aantal bewerkings - die tweede grafiek. En dit is duidelik dat ons reeds 'n bietjie makliker asemhaal wanneer 16 gigagrepe.
En waar 64 gigagrepe gesien kan word dat dit heeltemal beter geword het. Reeds die tande word uitgespreek, daar is meer geleenthede om ander operasies te oorleef en iets met die skyf te doen.
Hoekom so?
Ek sal 'n bietjie in die besonderhede duik, maar hierdie onderwerp, hoe om kontrolepuntinstelling uit te voer, kan 'n hele verslag tot gevolg hê, so ek sal nie veel laai nie, maar ek sal 'n bietjie uiteensit watter probleme daar is.
As die kontrolepunt te dikwels gebeur, en ons werk ons lyne nie opeenvolgend op nie, maar vind volgens indeks, wat goed is, omdat ons nie die hele tabel uitvee nie, dan kan dit gebeur dat ons eers die eerste bladsy aangeraak het, dan die duisendste, en toe teruggekeer na die eerste . En as tussen hierdie besoeke aan die eerste bladsy, checkpoint dit reeds op skyf gestoor het, dan sal dit dit weer stoor, want ons het dit 'n tweede keer vuil gemaak.
En ons sal kontrolepunt baie keer dwing om dit te red. Hoe sou daar oortollige operasies vir hom wees.
Maar dit is nie al nie. Bladsye is 8 kilogrepe in Postgres en 4 kilogrepe in Linux. En daar is 'n full_page_writes-instelling. Dit is by verstek geaktiveer. En dit is korrek, want as ons dit afskakel, dan is die gevaar dat net die helfte van die bladsy gestoor sal word as dit ineenstort.
Die gedrag om na die WAL van die voorwaartse log te skryf is so dat wanneer ons 'n kontrolepunt het en ons die bladsy vir die eerste keer verander, die hele bladsy, dit wil sê al 8 kilogrepe, in die voorwaartse log kom, alhoewel ons net die lyn, wat 100 grepe weeg. En ons moet die hele bladsy neerskryf.
In daaropvolgende veranderinge sal daar net 'n spesifieke tupel wees, maar vir die eerste keer skryf ons alles neer.
En dienooreenkomstig, as die kontrolepunt weer gebeur het, dan moet ons alles weer van voor af begin en die hele bladsy deurdruk. Met gereelde kontrolepunte, wanneer ons deur dieselfde bladsye stap, sal full_page_writes = on meer wees as wat dit kan wees, dit wil sê ons genereer meer WAL. Meer word na replikas, na die argief, na skyf gestuur.
En dienooreenkomstig het ons twee afdankings.
As ons max_wal_size verhoog, blyk dit dat ons dit makliker maak vir beide kontrolepunt en wal skrywer. En dit is wonderlik.
Kom ons sit 'n teragreep in en leef daarmee saam. Wat is sleg daaraan? Dit is erg, want in geval van 'n mislukking sal ons ure lank klim, want die kontrolepunt was lank gelede en baie het reeds verander. En ons moet al hierdie REDO doen. En so doen ons die tweede reeks eksperimente.
Ons doen 'n operasie en kyk wanneer die kontrolepunt voltooi is, ons maak -9 Postgres doelbewus dood.
En daarna begin ons dit weer, en kyk hoe lank dit sal styg op hierdie toerusting, dit wil sê hoeveel dit sal HERDOEN in hierdie slegte situasie.
Ek sal twee keer opmerk dat die situasie sleg is. Eerstens het ons neergestort net voor die kontrolepunt verby was, so ons het baie om te verloor. En tweedens, ons het 'n massiewe operasie gehad. En as kontrolepunte op time-out was, dan sou waarskynlik minder WAL gegenereer word sedert die laaste kontrolepunt. Dit wil sê, dit is 'n dubbele verloorder.
Ons meet so 'n situasie vir verskillende max_wal_size groottes en verstaan dat as max_wal_size 64 gigagrepe is, dan sal ons in 'n dubbel ergste geval vir 10 minute klim. En ons dink of dit ons pas of nie. Dit is 'n besigheidsvraag. Ons moet hierdie prentjie aan diegene wat verantwoordelik is vir besigheidsbesluite wys en vra: “Hoe lank kan ons hoogstens lê in geval van 'n probleem? Kan ons vir 3-5 minute in die ergste situasie gaan lê? En jy neem 'n besluit.
En hier is 'n interessante punt. Ons het 'n paar verslae oor Patroni by die konferensie. En miskien gebruik jy dit. Dit is 'n outo-failover vir Postgres. GitLab en Data Egret het hieroor gepraat.
En as jy 'n outo-failover het wat binne 30 sekondes kom, dan kan ons dalk vir 10 minute gaan lê? Want ons sal teen hierdie punt oorskakel na die replika, en alles sal reg wees. Dit is 'n betwiste punt. Ek ken nie 'n duidelike antwoord nie. Ek voel net dat hierdie onderwerp nie net oor ongelukherstel gaan nie.
As ons 'n lang herstel na 'n mislukking het, dan sal ons ongemaklik wees in baie ander situasies. Byvoorbeeld, in dieselfde eksperimente, wanneer ons iets doen en soms vir 10 minute moet wag.
Ek sal steeds nie te ver gaan nie, selfs al het ons 'n outo-failover. As 'n reël is waardes soos 64, 100 gigagrepe goeie waardes. Soms is dit selfs die moeite werd om minder te kies. Oor die algemeen is dit 'n subtiele wetenskap.
Om iterasies te doen, byvoorbeeld, max_wal_size =1, 8, moet jy die massabewerking baie keer herhaal. Jy het dit gemaak. En op dieselfde basis wil jy dit weer doen, maar jy het reeds alles uitgevee. Wat om te doen?
Ek sal later praat oor ons oplossing, wat ons doen om in sulke situasies te herhaal. En dit is die mees korrekte benadering.
Maar in hierdie geval was ons gelukkig. As, soos hier staan "BEGIN, DELETE, ROLLBACK", dan kan ons DELETE herhaal. Dit wil sê, as ons dit self gekanselleer het, dan kan ons dit herhaal. En fisies by jou sal die data op dieselfde plek lê. Jy kry nie eens opblaas nie. Jy kan oor sulke DELETEs herhaal.
Hierdie DELETE met ROLLBACK is ideaal vir kontrolepuntinstelling, selfs al het jy nie 'n behoorlik ontplooide databasislaboratoriums nie.
Ons het 'n bord gemaak met een kolom "i". Postgres het nutskolomme. Hulle is onsigbaar tensy spesifiek daarvoor gevra word. Dit is: ctid, xmid, xmax.
Ctid is 'n fisiese adres. Nul bladsy, die eerste tupel in die bladsy.
Dit kan gesien word dat na ROOLBACK die tupel op dieselfde plek gebly het. Dit wil sê, ons kan weer probeer, dit sal op dieselfde manier optree. Dit is die belangrikste ding.
Xmax is die tyd van dood van die tupel. Dit is gestempel, maar Postgres weet dat die transaksie teruggerol is, so dit maak nie saak of dit 0 is of dit 'n teruggerolde transaksie is nie. Dit dui daarop dat jy oor DELETE kan herhaal en die grootmaat bewerkings van die stelselgedrag nagaan. Jy kan databasislaboratoriums vir armes maak.
Dit gaan oor programmeerders. Ook oor DBA skel hulle altyd programmeerders hiervoor uit: “Hoekom doen julle sulke lang en moeilike bewerkings?”. Dit is 'n heeltemal ander loodregte onderwerp. Daar was voorheen administrasie, en nou sal daar ontwikkeling wees.
Dit is duidelik dat ons nie in stukke gebreek het nie. Dit is duidelik. Dit is onmoontlik om nie so DELETE vir 'n hoop van miljoene lyne in dele op te breek nie. Dit sal vir 20 minute gedoen word, en alles sal gaan lê. Maar ongelukkig maak selfs ervare ontwikkelaars foute, selfs in baie groot maatskappye.
Hoekom is dit belangrik om te breek?
-
As ons sien dat die skyf hard is, laat ons dit stadiger maak. En as ons stukkend is, dan kan ons pouses byvoeg, ons kan die versnelling vertraag.
-
En ons sal ander nie vir 'n lang tyd blokkeer nie. In sommige gevalle maak dit nie saak nie, as jy ware vullis uitvee waaraan niemand werk nie, dan sal jy heel waarskynlik niemand blokkeer nie, behalwe die outovakuumwerk, want dit sal wag vir die transaksie om te voltooi. Maar as jy iets verwyder wat iemand anders kan versoek, dan sal hulle geblokkeer word, daar sal 'n soort kettingreaksie wees. Lang transaksies moet op webwerwe en mobiele toepassings vermy word.
Dit is interessant. Ek sien dikwels dat ontwikkelaars vra: "Watter pakgrootte moet ek kies?".
Dit is duidelik dat hoe groter die bondelgrootte, hoe kleiner is die transaksiebokoste, dit wil sê die bykomende bokoste van transaksies. Maar terselfdertyd neem die tyd vir hierdie transaksie toe.
Ek het 'n baie eenvoudige reël: neem soveel as wat jy kan, maar moenie uitvoerbare items per sekonde oorskry nie.
Hoekom 'n sekonde? Die verduideliking is baie eenvoudig en verstaanbaar vir almal, selfs nie-tegniese mense. Ons sien 'n reaksie. Kom ons neem 50 millisekondes. As iets verander het, dan sal ons oog reageer. As minder, dan moeiliker. As iets byvoorbeeld ná 100 millisekondes reageer, jy het die muis geklik, en dit het jou ná 100 millisekondes geantwoord, voel jy reeds hierdie geringe vertraging. 'n Sekonde word reeds as remme beskou.
Gevolglik, as ons ons massa-operasies in 10-sekonde-sarsies opbreek, het ons 'n risiko dat ons iemand sal blokkeer. En dit sal vir 'n paar sekondes werk, en mense sal dit reeds agterkom. Daarom verkies ek om nie meer as 'n sekonde te doen nie. Maar moet dit terselfdertyd nie baie fyn opbreek nie, want die transaksiebokoste sal merkbaar wees. Die basis sal moeiliker wees, en ander verskillende probleme kan opduik.
Ons kies die grootte van die pakkie. In elke geval kan ons dit anders doen. Kan geoutomatiseer word. En ons is oortuig van die doeltreffendheid van die verwerking van een pak. Dit wil sê, ons DELETE van een pakkie of UPDATE.
Terloops, alles waarvan ek praat gaan nie net oor DELETE nie. Soos u geraai het, is dit enige grootmaatbewerkings op data.
En ons sien dat die plan uitstekend is. U kan die indeksskandering sien, slegs indeksskandering is nog beter. En ons het 'n klein hoeveelheid data betrokke. En minder as 'n sekonde vervul. Super.
En ons moet steeds seker maak dat daar geen agteruitgang is nie. Dit gebeur dat die eerste pakke vinnig uitwerk, en dan word dit erger, erger en erger. Die proses is so dat jy baie moet toets. Dit is presies waarvoor databasislaboratoriums is.
En ons moet nog iets voorberei sodat dit ons in staat sal stel om dit reg te volg in produksie. Ons kan byvoorbeeld die tyd in die log skryf, ons kan skryf waar ons nou is en wie ons nou uitgevee het. En dit sal ons toelaat om te verstaan wat later gebeur. En as iets verkeerd loop, vind die probleem vinnig.
As ons die doeltreffendheid van versoeke moet kontroleer en ons moet baie keer herhaal, dan is daar iets soos 'n mede-bot. Hy is reeds gereed. Dit word daagliks deur dosyne ontwikkelaars gebruik. En hy weet hoe om 'n groot teragreep-databasis op versoek in 30 sekondes jou eie kopie te gee. En jy kan iets daar uitvee en sê RESET, en dit weer uitvee. Jy kan op hierdie manier daarmee eksperimenteer. Ek sien 'n toekoms vir hierdie ding. En ons doen dit reeds.
Wat is partisiestrategieë? Ek sien 3 verskillende partisiestrategieë wat die ontwikkelaars op die pakket gebruik.
Die eerste een is baie eenvoudig. Ons het 'n numeriese ID. En kom ons breek dit af in verskillende intervalle en werk daarmee. Die nadeel is duidelik. In die eerste segment kan ons 100 reëls regte vullis hê, in die tweede 5 reëls of glad nie, of al 1 000 reëls sal as vullis blyk te wees. Baie ongelyke werk, maar dit is maklik om te breek. Hulle het die maksimum ID geneem en dit verpletter. Dit is 'n naïewe benadering.
Die tweede strategie is 'n gebalanseerde benadering. Dit word in Gitlab gebruik. Hulle het die tafel gevat en geskandeer. Ons het die grense van die ID-pakke gevind sodat elke pak presies 10 000 rekords gehad het. En sit hulle in 'n tou. En dan verwerk ons. Jy kan dit in verskeie drade doen.
Terloops in die eerste strategie kan jy dit ook in verskeie drade doen. Dit is nie moeilik nie.
Maar daar is 'n koeler en beter benadering. Dit is die derde strategie. En wanneer moontlik, is dit beter om dit te kies. Ons doen dit op grond van 'n spesiale indeks. In hierdie geval sal dit heel waarskynlik 'n indeks wees volgens ons vullistoestand en ID. Ons sal die ID insluit sodat dit slegs 'n indeks skandering is sodat ons nie na die hoop gaan nie.
Oor die algemeen is slegs indeksskandering vinniger as indeksskandering.
En ons kry vinnig ons ID's wat ons wil uitvee. BATCH_SIZE kies ons vooraf. En ons kry hulle nie net nie, ons kry hulle op 'n spesiale manier en hack hulle dadelik. Maar ons sluit so dat as hulle reeds gesluit is, ons hulle nie sluit nie, maar aanbeweeg en die volgende vat. Dit is vir opdatering oorslaan gesluit. Hierdie super kenmerk van Postgres stel ons in staat om in verskeie drade te werk as ons wil. Dit is moontlik in een stroom. En hier is daar 'n CTE - dit is een versoek. En ons het 'n ware skrapping aan die gang in die tweede verdieping van hierdie CTE - returning *. Jy kan ID terugstuur, maar dit is beter *as jy nie veel data op elke lyn het nie.
Hoekom het ons dit nodig? Dit is wat ons moet terug rapporteer. Ons het nou eintlik soveel reëls uitgevee. En ons het grense deur ID of deur created_at soos hierdie. Jy kan min, maks. Iets anders kan gedoen word. Hier kan jy baie dinge doen. En dit is baie gerieflik vir monitering.
Daar is nog een nota oor die indeks. As ons besluit dat ons 'n spesiale indeks vir hierdie taak nodig het, dan moet ons seker maak dat dit nie hope net tuples updates bederf nie. Dit wil sê, Postgres het sulke statistieke. Dit kan gesien word in pg_stat_user_tables vir jou tabel. Jy kan sien of warm opdaterings gebruik word of nie.
Daar is situasies wanneer jou nuwe indeks hulle eenvoudig kan afsny. En jy het al die ander opdaterings wat reeds werk, vertraag. Nie net omdat die indeks verskyn het nie (elke indeks vertraag opdaterings 'n bietjie, maar 'n bietjie), maar hier ruïneer dit dit steeds. En dit is onmoontlik om spesiale optimalisering vir hierdie tafel te maak. Dit gebeur soms. Dit is so 'n subtiliteit wat min mense onthou. En hierdie hark is maklik om op te trap. Soms gebeur dit dat jy 'n benadering van die ander kant moet vind en steeds sonder hierdie nuwe indeks klaarkom, of 'n ander indeks moet maak, of op 'n ander manier, byvoorbeeld, kan jy die tweede metode gebruik.
Maar dit is die mees optimale strategie, hoe om in bondels te verdeel en op bondels te skiet met een versoek, 'n bietjie uitvee, ens.
Lang transaksies
Geblokkeerde outovakuum -
blokkeer kwessie -
Fout #5 is 'n groot een. Nikolai van Okmeter het oor Postgres-monitering gepraat. Ideal Postgres-monitering bestaan ongelukkig nie. Sommige is nader, sommige is verder. Okmeter is naby genoeg om perfek te wees, maar baie ontbreek en moet bygevoeg word. Jy moet gereed wees hiervoor.
Byvoorbeeld, dooie tupels word die beste gemonitor. As jy baie dooie goed in die tabel het, dan is iets fout. Dit is beter om nou te reageer, anders kan daar agteruitgang wees, en ons kan gaan lê. Dit gebeur.
As daar 'n groot IO is, dan is dit duidelik dat dit nie goed is nie.
Lang transaksies ook. Lang transaksies moet nie op OLTP toegelaat word nie. En hier is 'n skakel na 'n brokkie wat jou toelaat om hierdie brokkie te neem en reeds 'n paar lang transaksies dop te hou.
Hoekom is lang transaksies sleg? Want al die slotte sal eers aan die einde losgemaak word. En ons moer almal. Boonop blokkeer ons outovakuum vir alle tafels. Dit is glad nie goed nie. Selfs as jy warm bystand op die replika geaktiveer het, is dit steeds sleg. Oor die algemeen is dit nêrens beter om lang transaksies te vermy nie.
As ons baie tafels het wat nie gesuig is nie, dan moet ons 'n waarskuwing hê. Hier is so 'n situasie moontlik. Ons kan indirek die werking van outovakuum beïnvloed. Dit is 'n brokkie van Avito, wat ek effens verbeter het. En dit was 'n interessante hulpmiddel om te sien wat ons met outovakuum het. Sommige tafels wag byvoorbeeld daar en sal nie wag vir hul beurt nie. Jy moet dit ook in monitering plaas en 'n waarskuwing hê.
En gee blokke uit. Bos van blokbome. Ek hou daarvan om iets van iemand af te neem en dit te verbeter. Hier het Data Egret 'n koel rekursiewe CTE geneem wat 'n woud van slotbome toon. Dit is 'n goeie diagnostiese hulpmiddel. En op grond daarvan kan u ook monitering bou. Maar dit moet versigtig gedoen word. Jy moet 'n klein statement_timeout vir jouself maak. En lock_timeout is wenslik.
Soms kom al hierdie foute in som.
Na my mening is die grootste fout hier organisatories. Dit is organisatories, want die tegniek trek nie. Dit is nommer 2 – hulle het op die verkeerde plek nagegaan.
Ons het op die verkeerde plek nagegaan, want ons het nie 'n produksiekloon gehad nie, wat maklik is om na te kyk. 'n Ontwikkelaar het dalk glad nie toegang tot produksie nie.
En ons het nie daar nagegaan nie. As ons daar nagegaan het, sou ons dit self gesien het. Die ontwikkelaar het dit alles gesien selfs sonder 'n DBA as hy dit nagegaan het in 'n goeie omgewing, waar daar dieselfde hoeveelheid data en 'n identiese ligging is. Hy sou al hierdie agteruitgang gesien het en hy sou skaam wees.
Meer oor outovacuum. Nadat ons 'n massiewe vee van 'n paar miljoen lyne gedoen het, moet ons nog HERPAK doen. Dit is veral belangrik vir indekse. Hulle sal sleg voel nadat ons alles daar skoongemaak het.
En as jy die daaglikse skoonmaakwerk wil terugbring, dan sal ek voorstel om dit meer gereeld te doen, maar kleiner. Dit kan een keer per minuut of selfs meer dikwels 'n bietjie wees. En jy moet twee dinge monitor: dat hierdie ding geen foute het nie en dat dit nie agterbly nie. Die truuk wat ek gewys het, sal dit net oplos.
Wat ons doen is oopbron. Dit is op GitLab geplaas. En ons maak dit so dat mense kan kyk selfs sonder 'n DBA. Ons doen 'n databasislaboratorium, dit wil sê, ons noem die basiskomponent waaraan Joe tans werk. En jy kan 'n kopie van die produksie gryp. Nou is daar 'n implementering van Joe vir slack, jy kan daar sê: "verduidelik so en so 'n versoek" en kry dadelik die resultaat vir jou kopie van die databasis. Jy kan selfs daar DELETE, en niemand sal dit agterkom nie.
Kom ons sê jy het 10 teragrepe, ons maak databasislaboratorium ook 10 teragrepe. En met gelyktydige 10 teragreep databasisse, kan 10 ontwikkelaars gelyktydig werk. Almal kan doen wat hulle wil. Kan delete, drop, ens. Dis so 'n fantasie. Ons sal môre hieroor praat.
Dit word dun voorsiening genoem. Dit is subtiele voorsiening. Dit is 'n soort fantasie wat vertragings in ontwikkeling, in toetsing grootliks verwyder en die wêreld 'n beter plek in hierdie verband maak. Dit wil sê, dit laat jou net toe om probleme met grootmaat bedrywighede te vermy.
Voorbeeld: 5 teragreep databasis, kry 'n kopie in minder as 30 sekondes. En dit hang nie eers van die grootte af nie, dit wil sê, dit maak nie saak hoeveel teragrepe nie.
Vandag kan jy gaan na en grawe in ons gereedskap. Jy kan registreer om te sien wat daar is. Jy kan hierdie bot installeer. Dit is gratis. Skryf.
vrae
Baie dikwels in werklike situasies blyk dit dat die data wat in die tabel moet bly, baie minder is as wat uitgevee moet word. Dit wil sê, in so 'n situasie is dit dikwels makliker om so 'n benadering te implementeer, wanneer dit makliker is om 'n nuwe voorwerp te skep, net die nodige data daarheen te kopieer en die ou tabel te stamp. Dit is duidelik dat 'n programmatiese benadering nodig is vir hierdie oomblik, terwyl jy gaan oorskakel. Hoe is hierdie benadering?
Dit is 'n baie goeie benadering en 'n baie goeie taak. Dit is baie soortgelyk aan wat pg_repack doen, dit is baie soortgelyk aan wat jy moet doen wanneer jy ID's 4 grepe maak. Baie raamwerke het dit 'n paar jaar gelede gedoen, en net die plate het grootgeword, en hulle moet omgeskakel word na 8 grepe.
Hierdie taak is nogal moeilik. Ons het dit gedoen. En jy moet baie versigtig wees. Daar is slotte, ens. Maar dit word gedoen. Dit wil sê, die standaardbenadering is om met pg_repack te gaan. Jy verklaar so 'n etiket. En voordat jy momentopnamedata daarin begin oplaai, verklaar jy ook een plaat wat alle veranderinge naspoor. Daar is 'n truuk dat jy dalk nie eers sommige veranderinge opspoor nie. Daar is subtiliteite. En dan skakel jy oor deur veranderinge te rol. Daar sal 'n kort pouse wees wanneer ons almal afskakel, maar oor die algemeen word dit gedoen.
As jy kyk na pg_repack op GitHub, dan daar, wanneer daar 'n taak was om 'n ID van int 4 na int 8 om te skakel, dan was daar 'n idee om pg_repack self te gebruik. Dit is ook moontlik, maar dit is 'n bietjie van 'n hack, maar dit sal ook hiervoor werk. Jy kan ingryp in die sneller wat pg_repack gebruik en daar sê: "Ons het nie hierdie data nodig nie", dit wil sê ons dra net oor wat ons nodig het. En dan skakel hy net oor en dit is dit.
Met hierdie benadering kry ons steeds 'n tweede kopie van die tabel, waarin die data reeds geïndekseer is en baie eweredig gestapel is met pragtige indekse.
Opblaas is nie teenwoordig nie, dit is 'n goeie benadering. Maar ek weet dat daar pogings is om 'n outomatisering hiervoor te ontwikkel, dit wil sê om 'n universele oplossing te maak. Ek kan jou in kontak bring met hierdie outomatisering. Dit is in Python geskryf, wat 'n goeie ding is.
Ek is net 'n bietjie van die wêreld van MySQL, so ek het kom luister. En ons gebruik hierdie benadering.
Maar dit is net as ons 90% het. As ons 5% het, dan is dit nie baie goed om dit te gebruik nie.
Dankie vir die verslag! As daar geen hulpbronne is om 'n volledige kopie van prod te maak nie, is daar enige algoritme of formule om die vrag of grootte te bereken?
Goeie vraag. Tot dusver is ons in staat om multi-teragreep databasisse te vind. Selfs al is die hardeware daar nie dieselfde nie, byvoorbeeld, minder geheue, minder verwerker en skywe is nie presies dieselfde nie, maar tog doen ons dit. As daar absoluut nêrens is nie, dan moet jy dink. Laat my dink tot môre, jy het gekom, ons sal praat, dit is 'n goeie vraag.
Dankie vir die verslag! Jy het eers begin oor die feit dat daar 'n koel Postgres is, wat sulke en sulke beperkings het, maar dit is besig om te ontwikkel. En dit is alles oor die algemeen 'n kruk. Is dit nie alles in stryd met die ontwikkeling van Postgres self, waarin een of ander DELETE deferent sal verskyn of iets anders wat op 'n lae vlak behoort te hou wat ons met van ons vreemde middele hier probeer afsmeer nie?
As ons in SQL gesê het om baie rekords in een transaksie uit te vee of op te dateer, hoe kan Postgres dit dan daar versprei? Ons is fisies beperk in bedrywighede. Ons sal dit nog lank doen. En ons sal op hierdie tydstip sluit, ens.
Klaar met indekse.
Ek kan aanvaar dat dieselfde kontrolepunt-instelling geoutomatiseer kan word. Eendag kan dit wees. Maar dan verstaan ek nie regtig die vraag nie.
Die vraag is, is daar so 'n vektor van ontwikkeling wat hier en daar gaan, en hier gaan joune parallel? Dié. Het hulle nog nie daaraan gedink nie?
Ek het gepraat oor die beginsels wat nou gebruik kan word. Daar is nog 'n bot , hiermee kan jy outomatiese kontrolepuntinstelling doen. Sal dit eendag in Postgres wees? Ek weet nie, dit is nog nie eers bespreek nie. Ons is nog ver daarvan. Maar daar is wetenskaplikes wat nuwe stelsels maak. En hulle druk ons in outomatiese indekse. Daar is ontwikkelings. Byvoorbeeld, jy kan kyk na outomatiese tuning. Dit kies parameters outomaties. Maar hy sal nog nie kontrolepuntinstelling vir jou doen nie. Dit wil sê, dit sal optel vir prestasie, dopbuffer, ens.
En vir kontrolepuntinstelling kan jy dit doen: as jy duisend groepe en verskillende hardeware, verskillende virtuele masjiene in die wolk het, kan jy ons bot gebruik outomatisering doen. En max_wal_size sal outomaties volgens jou teikeninstellings gekies word. Maar tot dusver is dit ongelukkig nie eens naby in die kern nie.
Goeie middag Jy het gepraat oor die gevare van lang transaksies. Jy het gesê dat outovakuum geblokkeer word in die geval van skrappings. Hoe anders benadeel dit ons? Want ons praat meer daarvan om spasie vry te maak en om dit te kan gebruik. Wat mis ons nog?
Autovacuum is dalk nie die grootste probleem hier nie. En die feit dat 'n lang transaksie ander transaksies kan sluit, hierdie moontlikheid is gevaarliker. Sy mag of mag nie ontmoet nie. As sy ontmoet het, kan dit baie erg wees. En met outovakuum - dit is ook 'n probleem. Daar is twee probleme met lang transaksies in OLTP: slotte en outovakuum. En as jy warm bystand-terugvoer op die replika geaktiveer het, sal jy steeds 'n outovakuumslot op die meester ontvang, dit sal van die replika af kom. Maar daar sal ten minste geen slotte wees nie. En daar sal loks wees. Ons praat van dataveranderings, so slotte is 'n belangrike punt hier. En as dit alles vir 'n lang, lang tyd is, dan word meer en meer transaksies gesluit. Hulle kan ander steel. En lok bome verskyn. Ek het 'n skakel na die brokkie verskaf. En hierdie probleem word vinniger opvallend as die probleem met outovakuum, wat net kan ophoop.
Dankie vir die verslag! Jy het jou verslag begin deur te sê dat jy verkeerd getoets het. Ons het ons idee voortgesit dat ons dieselfde toerusting moet neem, met die basis op dieselfde manier. Kom ons sê ons het die ontwikkelaar 'n basis gegee. En hy het aan die versoek voldoen. En dit lyk of hy goed gaan. Maar hy kyk nie vir lewendig nie, maar vir lewendig, byvoorbeeld, het ons 'n vrag van 60-70%. En selfs al gebruik ons hierdie stemming, werk dit nie baie goed nie.
Dit is belangrik om 'n kundige in die span te hê en DBA-kundiges te gebruik wat kan voorspel wat met 'n werklike agtergrondlading gaan gebeur. Toe ons net ons skoon veranderinge gery het, sien ons die prentjie. Maar 'n meer gevorderde benadering, toe ons weer dieselfde ding gedoen het, maar met 'n las gesimuleer met produksie. Dis nogal gaaf. Tot dan moet jy groot word. Dit is soos 'n volwassene. Ons het net gekyk na wat ons het en ook gekyk of ons genoeg hulpbronne het. Dis 'n goeie vraag.
Wanneer ons reeds 'n vullisseleksie doen en ons het byvoorbeeld 'n verwyderde vlag
Dit is wat outovakuum outomaties in Postgres doen.
O, doen hy dit?
Autovacuum is die vullisverwyderaar.
Dankie!
Dankie vir die verslag! Is daar 'n opsie om dadelik 'n databasis met partisionering so te ontwerp dat alle vullis iewers na die kant van die hooftafel af vuil word?
Natuurlik het.
Is dit dan moontlik om onsself te beskerm as ons 'n tafel gesluit het wat nie gebruik moet word nie?
Natuurlik het. Maar dit is soos 'n hoender-en-eier-vraag. As ons almal weet wat in die toekoms gaan gebeur, dan sal ons natuurlik alles cool doen. Maar die besigheid is besig om te verander, daar is nuwe kolomme, nuwe versoeke. En dan – oeps, ons wil dit verwyder. Maar hierdie ideale situasie, in die lewe kom dit voor, maar nie altyd nie. Maar oor die algemeen is dit 'n goeie idee. Knip net af en dit is dit.
Bron: will.com