Eartiids yn 'e fiere takomst sil de automatyske ferwidering fan ûnnedige gegevens ien fan' e wichtige taken fan 'e DBMS [1] wêze. Yn 'e tuskentiid moatte wy sels soargje foar it wiskjen of ferpleatse fan ûnnedige gegevens nei minder djoere opslachsystemen. Litte we sizze dat jo beslute om in pear miljoen rigels te wiskjen. In frij ienfâldige taak, benammen as de betingst bekend is en der in gaadlike yndeks is. "DELETE FROM table1 WHERE col1 = :wearde" - wat kin ienfâldiger wêze, krekt?
Video:
-
Ik sit sûnt it earste jier yn de programmakommisje Highload, dus sûnt 2007.
-
En ik bin sûnt 2005 by Postgres. Brûkte it yn in protte projekten.
-
Groep mei RuPostges ek sûnt 2007.
-
Wy binne útgroeid ta 2100+ dielnimmers by Meetup. It is twadde yn 'e wrâld nei New York, in lange tiid ynhelle troch San Francisco.
-
Ik haw ferskate jierren yn Kalifornje wenne. Ik gean mear mei Amerikaanske bedriuwen, ynklusyf grutte. Se binne aktive brûkers fan Postgres. En der binne allerhanne nijsgjirrige dingen.
is myn bedriuw. Wy binne yn it bedriuw fan it automatisearjen fan taken dy't ûntjouwingsferlies eliminearje.
As jo wat dogge, dan binne d'r soms in soarte fan pluggen om Postgres hinne. Litte wy sizze dat jo moatte wachtsje foar de admin om in teststand foar jo yn te stellen, of jo moatte wachtsje oant de DBA op jo reagearret. En wy fine sokke knelpunten yn it proses fan ûntwikkeling, testen en administraasje en besykje se te eliminearjen mei help fan automatisearring en nije oanpak.
Ik wie koartlyn by VLDB yn Los Angeles. Dit is de grutste konferinsje oer databases. En d'r wie in rapport dat yn 'e takomst DBMS net allinich gegevens opslaan, mar ek automatysk wiskje. Dit is in nij ûnderwerp.
D'r binne hieltyd mear gegevens yn 'e wrâld fan zettabytes - dat is 1 petabytes. En no wurdt al rûsd dat wy mear as 000 zettabytes oan gegevens hawwe opslein yn 'e wrâld. En der binne mear en mear fan harren.
En wat te dwaan mei it? Fansels moat it fuorthelle wurde. Hjir is in keppeling nei dit nijsgjirrige rapport. Mar oant no ta is dit net ynfierd yn 'e DBMS.
Wa't jild telle kin, wol twa dingen. Se wolle dat wy wiskje, dus technysk soene wy it moatte kinne.
Wat ik folgjende sil fertelle is wat abstrakte situaasje dy't in bulte echte situaasjes omfettet, dus in soarte fan kompilaasje fan wat my en de omlizzende databases eins in protte kearen, in protte jierren bard binne. Raken binne oeral en elkenien stapt der de hiele tiid op.
Litte wy sizze dat wy in basis hawwe as ferskate basen dy't groeie. En guon records binne fansels rommel. Bygelyks, de brûker begon dêr wat te dwaan, mar makke it net ôf. En nei in skoft witte wy dat dit ûnfoltôge net mear opslein wurde kin. Dat is, wy wolle graach wat jiskefet skjinmeitsje om romte te besparjen, prestaasjes te ferbetterjen, ensfh.
Yn 't algemien is de taak om it wiskjen fan spesifike dingen, spesifike rigels yn guon tabel te automatisearjen.
En wy hawwe sa'n fersyk, dêr't wy hjoed oer prate, dat is oer ôffalferwidering.
Wy hawwe in betûfte ûntwikkelder frege om it te dwaan. Hy naam dit fersyk, kontrolearre it foar himsels - alles wurket. Teste op staging - alles is goed. Útrôle - alles wurket. Ien kear deis rinne wy it - alles is goed.
De databank groeit en groeit. Daily DELETE begjint in bytsje stadiger te wurkjen.
Dan begripe wy dat wy no in marketingbedriuw hawwe en it ferkear ferskate kearen grutter sil wêze, dus beslute wy om tydlik ûnnedige dingen te stopjen. En ferjit werom te kommen.
In pear moanne letter wisten se. En dy ûntwikkelder hat ophâlden of mei wat oars dwaande is, hat in oare opdracht jûn om it werom te jaan.
Hy kontrolearre op dev, op staging - alles is OK. Fansels moatte jo noch skjinmeitsje wat sammele is. Hy kontrolearre alles wurket.
Wat bart der aanst? Dan falt alles foar ús útinoar. It sakket sa dat op in stuit alles falt. Elkenien is yn shock, gjinien begrypt wat der bart. En dan docht bliken dat de saak wie yn dizze DELETE.
Der is wat misgien? Hjir is in list fan wat koe hawwe gien ferkeard. Hokker fan dizze is it wichtichste?
-
Der wie bygelyks gjin resinsje, dus de DBA-ekspert seach der net nei. Hy soe fuortendaliks fine it probleem mei in betûfte each, en boppedat, hy hat tagong ta prod, dêr't ferskate miljoen rigels hawwe sammele.
-
Miskien hawwe se wat ferkeard kontrolearre.
-
Miskien is de hardware ferâldere en jo moatte dizze basis opwurdearje.
-
Of der is wat mis mei de databank sels, en wy moatte ferhúzje fan Postgres nei MySQL.
-
Of miskien is der wat mis mei de operaasje.
-
Miskien binne d'r wat flaters yn 'e organisaasje fan wurk en moatte jo ien ûntslaan en de bêste minsken oannimme?
D'r wie gjin DBA-kontrôle. As d'r in DBA wie, soe hy dizze ferskate miljoen rigels sjen en sels sûnder eksperiminten sizze: "Dat dogge se net." Stel dat as dizze koade yn GitLab, GitHub wie en d'r soe in proses foar koadebeoardieling wêze en d'r wie net sa'n ding dat sûnder de goedkarring fan 'e DBA dizze operaasje soe plakfine op prod, dan soe de DBA fansels sizze: "Dit kin net dien wurde .”
En hy soe sizze dat jo sille hawwe problemen mei skiif IO en alle prosessen sille gean gek, der kin wêze slûzen, en ek sil blokkearje autovacuum foar in bosk minuten, dus dit is net goed.
De twadde flater - se kontrolearre op it ferkearde plak. Wy seagen nei it feit dat in protte junkgegevens sammele op prod, mar de ûntwikkelder hie gjin gegevens sammele yn dizze databank, en gjinien makke dizze junk by it staging. Dêrtroch wiene d'r 1 rigels dy't fluch útwurke.
Wy begripe dat ús tests swak binne, dat wol sizze dat it proses dat is boud gjin problemen fangt. In adekwate DB-eksperimint waard net útfierd.
In ideaal eksperimint wurdt by foarkar útfierd op deselde apparatuer. It is net altyd mooglik om te dwaan dit op deselde apparatuer, mar it is hiel wichtich dat it in folsleine grutte kopy fan de databank. Dit is wat ik no al ferskate jierren preekje. En in jier lyn haw ik it oer dit, jo kinne it allegear besjen op YouTube.
Miskien is ús apparatuer min? As jo sjogge, dan sprong de latency. Wy hawwe sjoen dat it gebrûk 100% is. Fansels, as dit moderne NVMe-skiven wiene, dan soe it foar ús wierskynlik folle makliker wêze. En miskien soene wy der net fan dellizze.
As jo wolken hawwe, dan wurdt de upgrade dêr maklik dien. Nije replika's opwekke op 'e nije hardware. oerskeakelje. En alles is goed. Hiel maklik.
Is it mooglik om ien of oare wize oanreitsje de lytsere skiven? En hjir, krekt mei help fan DBA, dûke wy yn in bepaald ûnderwerp neamd checkpoint tuning. It docht bliken dat wy gjin checkpoint tuning hawwe.
Wat is checkpoint? It is yn elke DBMS. As jo hawwe gegevens yn it ûnthâld dat feroaret, it is net daliks skreaun op skiif. De ynformaasje dy't de gegevens feroare binne, wurdt earst skreaun nei it skriuw-foarút-log. En op in stuit beslút de DBMS dat it tiid is om echte siden op skiif te smiten, sadat as wy in mislearring hawwe, wy minder REDO kinne dwaan. It is as in boartersguod. As wy binne fermoarde, wy sille begjinne it spul fan de lêste checkpoint. En alle DBMS ymplementearje it.
De ynstellingen yn Postgres bliuwe efter. Se binne ûntworpen foar 10-15 jier âlde folumes fan gegevens en transaksjes. En checkpoint is gjin útsûndering.
Hjir is de ynformaasje fan ús Postgres-kontrôlerapport, oftewol automatyske sûnenskontrôle. En hjir is wat database fan ferskate terabytes. En it is goed te sjen dat twongen kontrôlepunten yn hast 90% fan de gefallen.
Wat betsjut dat? D'r binne twa ynstellingen dêr. Checkpoint kin komme troch time-out, bygelyks, yn 10 minuten. Of it kin komme as in soad gegevens binne ynfolle.
En standert is max_wal_saze ynsteld op 1 gigabyte. Yn feite bart dit echt yn Postgres nei 300-400 megabytes. Jo hawwe safolle gegevens feroare en jo kontrôle bart.
En as gjinien it ôfstimd hat, en de tsjinst groeide, en it bedriuw fertsjinnet in soad jild, it hat in protte transaksjes, dan komt it kontrôlepunt ien kear yn 'e minút, soms elke 30 sekonden, en soms sels oerlaapje. Dit is nochal min.
En wy moatte der foar soargje dat it minder faak komt. Dat is, wy kinne max_wal_size ferheegje. En it sil minder faak komme.
Mar wy hawwe in hiele metodyk ûntwikkele foar hoe't jo it krekter dwaan kinne, dat is hoe't jo in beslút meitsje oer it kiezen fan ynstellings, dúdlik basearre op spesifike gegevens.
Dêrtroch dogge wy twa searjes fan eksperiminten op databases.
De earste rige - wy feroarje max_wal_size. En wy dogge in massale operaasje. Earst dogge wy it op 'e standertynstelling fan 1 gigabyte. En wy dogge in massale DELETE fan in protte miljoenen rigels.
Jo kinne sjen hoe dreech it is foar ús. Wy sjogge dat skiif IO is hiel min. Wy sjogge nei hoefolle WAL's wy hawwe generearre, om't dit heul wichtich is. Litte wy sjen hoefolle kearen it kontrôlepunt barde. En wy sjogge dat it net goed is.
Folgjende ferheegje wy max_wal_size. Wy werhelje. Wy ferheegje, wy werhelje. En safolle kearen. Yn prinsipe is 10 punten goed, dêr't 1, 2, 4, 8 gigabytes. En wy sjogge nei it gedrach fan in bepaald systeem. It is dúdlik dat hjir de apparatuer moat wêze lykas op prod. Jo moatte deselde skiven, itselde bedrach fan ûnthâld, en deselde Postgres ynstellings.
En op dizze manier sille wy ús systeem útwikselje, en wy witte hoe't de DBMS sil gedrage yn gefal fan in minne massa DELETE, hoe't it sil checkpoint.
Checkpoint yn it Russysk binne checkpoints.
Foarbyld: DELETE ferskate miljoen rigen per yndeks, rigen binne "ferspraat" oer siden.
Hjir is in foarbyld. Dit is wat basis. En mei de standertynstelling fan 1 gigabyte foar max_wal_size, is it heul dúdlik dat ús skiven nei de planke gean foar opname. Dizze foto is in typysk symptoom fan in tige sike pasjint, dat is, hy fielde echt min. En d'r wie ien inkele operaasje, d'r wie gewoan in DELETE fan ferskate miljoen rigels.
As sa'n operaasje is tastien yn prod, dan sille wy gewoan lizzen, want it is dúdlik dat men DELETE deadet ús yn 'e planke.
Fierder, dêr't 16 gigabytes, it is dúdlik dat de tosken hawwe al gien. Tosken binne al better, dat is, wy klopje op it plafond, mar net sa slim. Dêr wie wat frijheid. Oan de rjochterkant is it rekord. En it oantal operaasjes - de twadde grafyk. En it is dúdlik dat wy al in bytsje makliker sykhelje as 16 gigabytes.
En wêr't 64 gigabyte te sjen is dat it folslein better wurden is. Al binne de tosken útsprutsen, der binne mear mooglikheden om oare operaasjes te oerlibjen en wat te dwaan mei de skiif.
Wêrom is it sa?
Ik sil in bytsje yn 'e details dûke, mar dit ûnderwerp, hoe't jo kontrôlepunt ôfstimme, kin resultearje yn in folslein rapport, dus ik sil net folle laden, mar ik sil in bytsje sketse hokker swierrichheden d'r binne.
As it kontrôlepunt te faak bart, en wy aktualisearje ús rigels net sequentieel, mar fine troch yndeks, wat goed is, om't wy de hiele tabel net wiskje, dan kin it barre dat wy earst de earste side oanrekke, dan de tûzenste, en doe werom nei de earste. En as tusken dizze besites oan 'e earste side, checkpoint it al op skiif bewarre hat, dan sil it it opnij bewarje, om't wy it in twadde kear smoarge hawwe.
En wy sille kontrôlepunt twinge om it in protte kearen te bewarjen. Hoe soe der oerstallige operaasjes foar him.
Mar dat is net alles. Siden binne 8 kilobytes yn Postgres en 4 kilobytes yn Linux. En d'r is in ynstelling foar full_page_writes. It is standert ynskeakele. En dit kloppet, want as wy it útsette, dan is it gefaar dat mar de helte fan de side bewarre wurdt as dy crasht.
It gedrach fan skriuwen nei de WAL fan it foarút log is sa dat as wy in kontrôle hawwe en wy feroarje de side foar de earste kear, de hiele side, dus alle 8 kilobytes, komt yn it foarút log, hoewol't wy allinne feroare de side line, dy't waacht 100 bytes. En wy moatte de hiele side opskriuwe.
Yn folgjende feroarings sil d'r mar in spesifike tuple wêze, mar foar it earst skriuwe wy alles op.
En sadwaande, as it kontrôlepunt wer barde, dan moatte wy alles opnij begjinne en de heule side drukke. Mei faak kontrôlepunten, as wy troch deselde siden rinne, sil full_page_writes = op mear wêze dan it koe wêze, dat wol sizze wy generearje mear WAL. Mear wurdt stjoerd nei replika's, nei it argyf, nei skiif.
En dêrom hawwe wy twa ûntslaggen.
As wy fergrutsje max_wal_size, docht bliken dat wy meitsje it makliker foar sawol checkpoint en wal skriuwer. En dat is geweldich.
Litte wy in terabyte ynsette en dermei libje. Wat is der min oan? Dit is slim, want by in mislearring sille wy oeren klimme, want de kontrôle wie lang lyn en der is al in soad feroare. En wy moatte dit alles REDO dwaan. En sa dogge wy de twadde searje fan eksperiminten.
Wy dogge in operaasje en sjogge wannear't it kontrôlepunt op it punt is om te foltôgjen, wy deadzje -9 Postgres mei opsetsin.
En nei dat wy begjinne it wer, en sjen hoe lang it sil opstean op dizze apparatuer, i.e. hoefolle it sil REDO yn dizze minne situaasje.
Twa kear sil ik konstatearje dat de situaasje min is. Earst ferûngelokke wy krekt foardat de kontrôle foarby wie, dus wy hawwe in protte te ferliezen. En twadde, wy hiene in massale operaasje. En as kontrôlepunten op time-out wiene, dan soe wierskynlik minder WAL wurde generearre sûnt it lêste kontrôlepunt. Dat is, it is in dûbele ferliezer.
Wy mjitte sa'n situaasje foar ferskate max_wal_size-grutte en begripe dat as max_wal_size 64 gigabytes is, dan sille wy yn in dûbeld slimste gefal 10 minuten klimme. En wy tinke oft it by ús past of net. Dit is in saaklike fraach. Wy moatte dizze foto sjen litte oan dyjingen dy't ferantwurdlik binne foar saaklike besluten en freegje: "Hoe lang kinne wy maximaal lizze yn gefal fan in probleem? Kinne wy 3-5 minuten yn 'e minste situaasje lizze? En jo meitsje in beslút.
En hjir is in nijsgjirrich punt. Wy hawwe in pear rapporten oer Patroni op 'e konferinsje. En miskien brûke jo it. Dit is in autofailover foar Postgres. GitLab en Data Egret prate oer dit.
En as jo in autofailover hawwe dy't yn 30 sekonden komt, dan kinne wy miskien 10 minuten lizze? Om't wy op dit punt sille oerstappe nei de replika, en alles sil goed wêze. Dit is in moot punt. Ik wit gjin dúdlik antwurd. Ik fiel gewoan dat dit ûnderwerp net allinich om crashherstel giet.
As wy in lange herstel hawwe nei in mislearring, dan sille wy yn in protte oare situaasjes ûngemaklik wêze. Bygelyks, yn deselde eksperiminten, as wy wat dogge en soms moatte wachtsje foar 10 minuten.
Ik soe noch net te fier gean, sels as wy in autofailover hawwe. As regel binne wearden lykas 64, 100 gigabytes goede wearden. Soms is it sels de muoite wurdich om minder te kiezen. Yn 't algemien is dit in subtile wittenskip.
Om iteraasjes te dwaan, bygelyks max_wal_size =1, 8, moatte jo de massa-operaasje in protte kearen werhelje. Do hast it helle. En op deselde basis wolle jo it nochris dwaan, mar jo hawwe alles al wiske. Wat te dwaan?
Ik sil letter prate oer ús oplossing, wat wy dogge om te iterearjen yn sokke situaasjes. En dit is de meast korrekte oanpak.
Mar yn dit gefal wiene wy gelok. As, sa't it hjir stiet "BEGIN, DELETE, ROLLBACK", dan kinne wy DELETE werhelje. Dat is, as wy it sels annulearje, dan kinne wy it werhelje. En fysyk by jo sille de gegevens op itselde plak lizze. Jo krije sels gjin blaas. Jo kinne iterearje oer sokke DELETEs.
Dizze DELETE mei ROLLBACK is ideaal foar tuning fan checkpoint, sels as jo gjin goed ynset databaselabs hawwe.
Wy makken in plaat mei ien kolom "i". Postgres hat nutskolommen. Se binne ûnsichtber útsein as spesifyk frege. Dit binne: ctid, xmid, xmax.
Ctid is in fysyk adres. Nul side, de earste tuple op 'e side.
It kin sjoen wurde dat nei ROOLBACK de tuple op itselde plak bleau. Dat is, wy kinne it nochris besykje, it sil op deselde manier gedrage. Dit is it wichtichste ding.
Xmax is de tiid fan 'e dea fan' e tuple. It waard stimpele, mar Postgres wit dat dizze transaksje waard rôle werom, dus it makket neat út oft it is 0 of it is in rôle werom transaksje. Dit suggerearret dat jo kinne iterearje oer DELETE en kontrolearje de bulk operaasjes fan it systeemgedrach. Jo kinne databaselabs meitsje foar de earmen.
Dit giet oer programmeurs. Ek oer DBA skele se programmeurs hjir altyd foar út: "Wêrom dogge jo sokke lange en drege operaasjes?". Dit is in folslein oar perpendicular ûnderwerp. Der wie eartiids administraasje, en no sil der ûntwikkeling komme.
Fansels binne wy net yn stikken brutsen. It is dúdlik. It is ûnmooglik net te brekken sokke DELETE foar in heap fan miljoenen rigels yn dielen. It sil dien wurde foar 20 minuten, en alles sil lizze. Mar, spitigernôch, sels betûfte ûntwikkelders meitsje flaters, sels yn heul grutte bedriuwen.
Wêrom is it wichtich om te brekken?
-
As wy sjogge dat de skiif hurd is, litte wy it dan fertrage. En as wy brutsen binne, dan kinne wy pauzes tafoegje, wy kinne it gas fertrage.
-
En wy sille oaren net foar in lange tiid blokkearje. Yn guon gefallen makket it net út, as jo echte jiskefet wiskje wêr't gjinien oan wurket, dan sille jo wierskynlik gjinien blokkearje útsein it autovacuümwurk, om't it sil wachtsje op 'e transaksje om te foltôgjen. Mar as jo wat ferwiderje dat in oar oanfreegje kin, dan wurde se blokkearre, d'r komt in soarte fan kettingreaksje. Lange transaksjes moatte wurde foarkommen op websiden en mobile applikaasjes.
Dit is nijsgjirrich. Ik sjoch faak dat ûntwikkelders freegje: "Hokker pakketgrutte moat ik kieze?".
It is dúdlik dat de grutter de bondelgrutte, de legere de transaksje-overhead, dus de ekstra overhead fan transaksjes. Mar tagelyk nimt de tiid ta foar dizze transaksje.
Ik haw in hiel ienfâldige regel: nim safolle as jo kinne, mar gean net oer útfierbere per sekonde.
Wêrom in sekonde? De útlis is hiel ienfâldich en begryplik foar elkenien, sels net-technyske minsken. Wy sjogge in reaksje. Lit ús nimme 50 millisekonden. As der wat feroare is, dan sil ús each reagearje. As minder, dan dreger. As eat reagearret nei 100 millisekonden, bygelyks, jo klikke op de mûs, en it antwurde jo nei 100 millisekonden, jo al fiele dizze lytse fertraging. In twadde wurdt al ûnderfûn as remmen.
Dêrom, as wy ús massa operaasjes brekke yn 10-sekonden bursts, dan hawwe wy it risiko dat wy blokkearje immen. En it sil in pear sekonden wurkje, en minsken sille it al fernimme. Dêrom doch ik leaver net mear as in sekonde. Mar tagelyk, brek it net heul fyn, om't de transaksje-overhead sil merkber wêze. De basis sil hurder wêze, en oare ferskillende problemen kinne ûntstean.
Wy kieze de grutte fan it pakket. Yn elk gefal kinne wy it oars dwaan. Kin wurde automatisearre. En wy binne oertsjûge fan de effisjinsje fan de ferwurking fan ien pakket. Dat is, wy dogge DELETE fan ien pakket of UPDATE.
Trouwens, alles wêr't ik it oer haw, giet net allinich oer DELETE. Lykas jo riede, binne dit alle bulkoperaasjes op gegevens.
En wy sjogge dat it plan poerbêst is. Jo kinne sjen de yndeks scan, yndeks allinne scan is noch better. En wy hawwe in lyts bedrach fan gegevens belutsen. En minder as in sekonde foldocht. Super.
En wy moatte noch soargje dat der gjin degradaasje is. It bart dat de earste pakken fluch wurkje, en dan wurdt it slimmer, slimmer en slimmer. It proses is sa dat jo in protte moatte testen. Dit is krekt wêr't databanklabs foar binne.
En wy moatte noch wat tariede sadat wy dit goed folgje kinne yn produksje. Wy kinne bygelyks de tiid yn it log skriuwe, wy kinne skriuwe wêr't wy no binne en wa't wy no wiske hawwe. En dit sil tastean ús te begripen wat der bart letter. En as der wat mis giet, fyn it probleem gau.
As wy de effisjinsje fan oanfragen moatte kontrolearje en wy moatte in protte kearen iterearje, dan is d'r sa'n ding as in kollega-bot. Hy is al klear. It wurdt deistich brûkt troch tsientallen ûntwikkelders. En hy wit hoe't jo in enoarme terabyte-database op oanfraach yn 30 sekonden jouwe, jo eigen kopy. En do kinst wiskje wat dêr en sizze RESET, en wiskje it wer. Jo kinne it op dizze manier eksperimintearje. Ik sjoch in takomst foar dit ding. En wy dogge it al.
Wat binne partitioneringsstrategyen? Ik sjoch 3 ferskillende partitioneringsstrategyen dy't de ûntwikkelders op it pakket brûke.
De earste is hiel ienfâldich. Wy hawwe in numerike ID. En lit ús it opsplitse yn ferskate yntervallen en dêrmei wurkje. It neidiel is dúdlik. Yn it earste segmint kinne wy 100 rigels fan echte jiskefet hawwe, yn 'e twadde 5 rigels of hielendal net, of alle 1 rigels sille blike te wêzen jiskefet. Hiel oneffen wurk, mar it is maklik te brekken. Se namen de maksimale ID en smieten dy. Dit is in naïve oanpak.
De twadde strategy is in lykwichtige oanpak. It wurdt brûkt yn Gitlab. Se namen en skennen de tafel. Wy fûnen de grinzen fan 'e ID-pakketten sadat elk pakket krekt 10 records hie. En set se yn in wachtrige. En dan ferwurkje wy. Jo kinne dit dwaan yn meardere threads.
Yn 'e earste strategy kinne jo dit trouwens ek dwaan yn ferskate diskusjes. It is net dreech.
Mar d'r is in koeler en bettere oanpak. Dit is de tredde strategy. En as it mooglik is, is it better om it te kiezen. Dat dogge wy op basis fan in spesjale yndeks. Yn dit gefal sil it nei alle gedachten in yndeks wêze neffens ús jiskefetstân en ID. Wy sille de ID opnimme sadat it allinich in yndeksscan is, sadat wy net nei de heap geane.
Yn 't algemien is scan allinnich yndeks flugger dan yndeks scan.
En wy fine gau ús ID's dy't wy wiskje wolle. BATCH_SIZE selektearje wy foarôf. En wy krije se net allinich, wy krije se op in spesjale manier en hack se fuortendaliks. Mar wy slute sa dat as se al op slot binne, wy se net slute, mar trochgean en de folgjende nimme. Dit is foar update skip beskoattele. Dizze superfunksje fan Postgres lit ús wurkje yn ferskate threaden as wy wolle. It is mooglik yn ien stream. En hjir is d'r in CTE - dit is ien fersyk. En wy hawwe in echte wiskje op 'e twadde ferdjipping fan dizze CTE - returning *. Jo kinne werom id, mar it is better *as jo net hawwe folle gegevens op eltse rigel.
Wêrom hawwe wy it nedich? Dit is wat wy moatte rapportearje werom. Wy hawwe no eins safolle rigels wiske. En wy hawwe grinzen troch ID of troch create_at lykas dit. Jo kinne min, max. Der kin noch wat dien wurde. Jo kinne hjir in protte ynfolje. En it is heul handich foar tafersjoch.
Der is noch ien opmerking oer de yndeks. As wy beslute dat wy nedich hawwe in spesjale yndeks foar dizze taak, dan moatte wy der wis fan dat it net bedjerre heap allinne tuples updates. Dat is, Postgres hat sokke statistiken. Dit kin sjoen wurde yn pg_stat_user_tables foar jo tabel. Jo kinne sjen oft hot updates wurde brûkt of net.
D'r binne situaasjes wêryn jo nije yndeks se gewoan kin ôfsnije. En jo hawwe alle oare updates dy't al wurkje, fertrage. Net allinnich om't de yndeks ferskynde (elke yndeks fertraget updates in bytsje, mar in bytsje), mar hjir ferneatiget it noch. En it is ûnmooglik om spesjale optimalisaasje te meitsjen foar dizze tafel. Dit bart soms. Dit is sa'n subtiliteit dat in pear minsken ûnthâlde. En dizze rake is maklik om op te stappen. Soms bart it dat jo in oanpak fan 'e oare kant moatte fine en dochs sûnder dizze nije yndeks dwaan moatte, of in oare yndeks meitsje, of op in oare manier kinne jo bygelyks de twadde metoade brûke.
Mar dit is de meast optimale strategy, hoe te splitsen yn batches en sjitte op batches mei ien fersyk, wiskje in bytsje, etc.
Lange transaksjes
Autovacuum blokkearre -
blokkearje probleem -
Flater # 5 is in grutte. Nikolai fan Okmeter spruts oer Postgres-monitoring. Ideale Postgres-monitoring bestiet spitigernôch net. Guon binne tichterby, guon binne fierder. Okmeter is tichtby genôch om perfekt te wêzen, mar in protte ûntbrekt en moat wurde tafoege. Jo moatte wêze klear foar dit.
Bygelyks, deade tupels wurde it bêste kontrolearre. As jo in protte deade dingen op 'e tafel hawwe, dan is der wat mis. It is better om no te reagearjen, oars kin der degradaasje komme, en kinne wy lizzen. It bart.
As der in grutte IO is, dan is it dúdlik dat dit net goed is.
Lange transaksjes ek. Lange transaksjes moatte net tastien wurde op OLTP. En hjir is in keppeling nei in snippet wêrmei jo dizze snippet kinne nimme en al wat folgjen fan lange transaksjes dwaan.
Wêrom binne lange transaksjes min? Want alle slûzen wurde pas oan 'e ein losmakke. En wy smyt elkenien. Plus, wy blokkearje autovacuum foar alle tabellen. It is hielendal net goed. Sels as jo hot standby ynskeakele hawwe op 'e replika, is it noch altyd min. Yn 't algemien is it nearne better om lange transaksjes te foarkommen.
As wy in protte tabellen hawwe dy't net stofsûge binne, dan moatte wy in warskôging hawwe. Hjir is sa'n situaasje mooglik. Wy kinne yndirekt ynfloed op de wurking fan autovacuum. Dit is in snippet fan Avito, dat ik wat ferbettere. En it die bliken in nijsgjirrich ark te wêzen om te sjen wat wy hawwe mei autovacuum. Bygelyks, guon tafels wachtsje dêr en sil net wachtsje op harren beurt. Jo moatte it ek yn tafersjoch sette en in warskôging hawwe.
En jout blokken út. Bosk fan blokbeammen. Ik wol graach wat fan immen nimme en it ferbetterje. Hjir naam Data Egret in koele rekursive CTE dy't in bosk fan slotbeammen toant. Dit is in goed diagnostysk ark. En op basis dêrfan kinne jo ek tafersjoch bouwe. Mar dit moat dien wurde foarsichtich. Jo moatte in lytse statement_timeout foar josels meitsje. En lock_timeout is winsklik.
Soms komme al dizze flaters yn totaal foar.
Neffens my is de wichtichste flater hjir organisatoarysk. It is organisatoarysk, om't de technyk net lûkt. Dit is nûmer 2 - se kontrolearre op it ferkearde plak.
Wy hawwe op it ferkearde plak kontrolearre, om't wy gjin produksjekloon hienen, wat maklik te kontrolearjen is. In ûntwikkelder hat miskien hielendal gjin tagong ta produksje.
En dêr ha wy net kontrolearre. As wy dêr kontrolearre hiene, hiene wy it sels sjoen. De ûntwikkelder seach it allegear sels sûnder in DBA as hy it kontrolearre yn in goede omjouwing, wêr't itselde bedrach fan gegevens en in identike lokaasje is. Hy soe al dizze degradaasje sjoen hawwe en hy soe him skamje.
Mear oer autovacuum. Neidat wy hawwe dien in massale sweep fan ferskate miljoen rigels, wy moatte noch dwaan REPACK. Dit is benammen wichtich foar yndeksen. Se sille fiele min neidat wy skjinmakke alles dêr.
En as jo it deistige skjinmakwurk werombringe wolle, dan soe ik foarstelle om it faker te dwaan, mar lytser. It kin ien kear yn 'e minút wêze of sels faker in bytsje. En jo moatte twa dingen kontrolearje: dat dit ding gjin flaters hat en dat it net efterbliuwt. De trúk dy't ik liet sjen sil dit gewoan oplosse.
Wat wy dogge is iepen boarne. It is pleatst op GitLab. En wy meitsje it sa dat minsken kinne kontrolearje sels sûnder in DBA. Wy dogge in databanklab, dat is, wy neame de basiskomponint wêrop Joe op it stuit wurket. En jo kinne in kopy fan produksje pakke. No is der in ymplemintaasje fan Joe foar slack, jo kinne dêr sizze: "ferklearje sa'n en sa'n fersyk" en krije daliks it resultaat foar jo kopy fan 'e databank. Jo kinne sels DELETE dêr, en gjinien sil fernimme it.
Litte wy sizze dat jo 10 terabyte hawwe, wy meitsje databanklab ek 10 terabyte. En mei simultane databases fan 10 terabyte kinne 10 ûntwikkelders tagelyk wurkje. Elkenien kin dwaan wat se wolle. Kin wiskje, drop, ensfh Dat is sa'n fantasy. Wy prate der moarn oer.
Dit wurdt tinne foarsjenning neamd. Dit is subtile foarsjenning. Dit is in soarte fan fantasy dy't fertragingen yn ûntwikkeling, yn testen en makket de wrâld in better plak yn dit ferbân. Dat is, it lit jo gewoan problemen mei bulk operaasjes foarkomme.
Foarbyld: 5 terabyte databank, krije in kopy yn minder dan 30 sekonden. En it hinget net iens ôf fan 'e grutte, dat is, it makket net út hoefolle terabytes.
Hjoed kinne jo gean nei en grave yn ús ark. Jo kinne registrearje om te sjen wat der is. Jo kinne dizze bot ynstallearje. It is fergees. Skriuwe.
Jo fragen
Hiel faak yn echte situaasjes docht bliken dat de gegevens dy't moatte bliuwe yn 'e tabel is folle minder as wat moat wurde wiske. Dat is, yn sa'n situaasje is it faak makliker om sa'n oanpak te realisearjen, as it makliker is om in nij foarwerp te meitsjen, allinich de nedige gegevens dêr te kopiearjen en de âlde tabel te romjen. It is dúdlik dat in programmatyske oanpak nedich is foar dit momint, wylst jo sille wikselje. Hoe is dizze oanpak?
Dit is in heul goede oanpak en in heul goede taak. It is hiel gelyk oan wat pg_repack docht, it is hiel gelyk oan wat jo moatte dwaan as jo meitsje IDs 4 bytes. In protte kaders diene dit in pear jier lyn, en krekt de platen binne opgroeid, en se moatte wurde omboud ta 8 bytes.
Dizze taak is frij dreech. Wy hawwe it dien. En jo moatte tige foarsichtich wêze. Der binne slûzen, ensfh Mar it wurdt dien. Dat is, de standert oanpak is om te gean mei pg_repack. Jo ferklearje sa'n label. En foardat jo begjinne mei it uploaden fan snapshotgegevens deryn, ferklearje jo ek ien plaat dy't alle feroarings folget. D'r is in trúk dat jo guon feroarings miskien net iens folgje. Der binne subtiliteiten. En dan wikselje jo troch feroaringen te rôljen. Der sil in koarte pauze wêze as wy elkenien ôfslute, mar yn 't algemien wurdt dit dien.
As jo sjogge nei pg_repack op GitHub, dan d'r, doe't d'r in taak wie om in ID fan int 4 nei int 8 te konvertearjen, dan wie d'r in idee om pg_repack sels te brûken. Dit is ek mooglik, mar it is in bytsje fan in hack, mar it sil ek wurkje foar dit. Jo kinne yngripe yn 'e trigger dy't pg_repack brûkt en dêr sizze: "Wy hawwe dizze gegevens net nedich", d.w.s. wy oerdrage allinich wat wy nedich binne. En dan skeakelt er mar en dat is it.
Mei dizze oanpak krije wy noch in twadde kopy fan 'e tabel, wêryn't de gegevens al yndeksearre binne en tige lykwichtich steapele binne mei prachtige yndeksen.
Bloat is net oanwêzich, it is in goede oanpak. Mar ik wit dat der besocht wurdt om dêr in automatisearring foar te ûntwikkeljen, dus in universele oplossing te meitsjen. Ik kin jo yn kontakt bringe mei dizze automatisearring. It is skreaun yn Python, dat is in goede saak.
Ik kom mar in bytsje út 'e wrâld fan MySQL, dus ik kaam om te harkjen. En wy brûke dizze oanpak.
Mar it is allinich as wy 90% hawwe. As wy 5% hawwe, dan is it net heul goed om it te brûken.
Tank foar it ferslach! As d'r gjin middels binne om in folsleine kopy fan prod te meitsjen, is d'r dan in algoritme of formule om de lading of grutte te berekkenjen?
Goeie fraach. Oant no kinne wy multi-terabyte databases fine. Sels as de hardware is der net itselde, Bygelyks, minder ûnthâld, minder prosessor en skiven binne net krekt itselde, mar dochs dogge wy it. As der hielendal nearne is, dan moatte jo tinke. Lit my tinke oant moarn, do kaamst, wy sille prate, dit is in goede fraach.
Tank foar it ferslach! Jo begon earst oer it feit dat d'r in koele Postgres is, dy't sokke en sokke beheiningen hat, mar it ûntwikkelet. En dit is allegear in kruk troch en grutte. Is dit net allegear yn striid mei de ûntwikkeling fan Postgres sels, wêryn't ien of oare DELETE deferent sil ferskine of wat oars dat op in leech nivo moat hâlde wat wy besykje te smarjen mei guon fan ús frjemde middels hjir?
As wy yn SQL seine om in protte records yn ien transaksje te wiskjen of te aktualisearjen, hoe kin Postgres it dêr dan distribuearje? Wy binne fysyk beheind yn operaasjes. Wy sille it noch lang dwaan. En wy sille op dit stuit slute, ensfh.
Dien mei yndeksen.
Ik kin oannimme dat deselde checkpoint tuning koe wurde automatisearre. Ienris kin it wêze. Mar dan begryp ik de fraach net echt.
De fraach is, is d'r sa'n fektor fan ûntwikkeling dy't hjir en dêr giet, en hjir giet jo parallel? Dy. Ha se der noch net oer neitocht?
Ik haw it oer de prinsipes dy't no brûkt wurde kinne. Der is in oare bot , Hjirmei kinne jo automatyske kontrôlepunttuning dwaan. Sil it ienris yn Postgres wêze? Ik wit it net, it is noch net iens besprutsen. Dêr binne wy noch fier fan. Mar d'r binne wittenskippers dy't nije systemen meitsje. En se skowe ús yn automatyske yndeksen. Der binne ûntjouwings. Jo kinne bygelyks sjen nei auto-tuning. It selekteart parameters automatysk. Mar hy sil noch gjin kontrôlepunt foar jo dwaan. Dat is, it sil opnimme foar prestaasjes, shellbuffer, ensfh.
En foar it ôfstimmen fan kontrôlepunten kinne jo dit dwaan: as jo tûzen klusters en ferskate hardware hawwe, ferskate firtuele masines yn 'e wolk, kinne jo ús bot brûke do automatisearring. En max_wal_size sil automatysk wurde selektearre neffens jo doelynstellingen. Mar oant no ta is dit net iens tichtby yn 'e kearn, spitigernôch.
Goeiemiddei Jo hawwe it oer de gefaren fan lange transaksjes. Jo hawwe sein dat autovacuum is blokkearre yn gefal fan wiskjen. Hoe oars docht it ús skea? Want wy ha it mear oer it frijmeitsjen fan romte en it brûke kinne. Wat misse wy noch?
Autovacuum is hjir miskien net it grutste probleem. En it feit dat in lange transaksje oare transaksjes kin beskoattelje, dizze mooglikheid is gefaarliker. Se kin wol of net moetsje. As se moete, dan kin it hiel slim. En mei autovacuum - dit is ek in probleem. D'r binne twa problemen mei lange transaksjes yn OLTP: slûzen en autovacuum. En as jo hjitte standby-feedback hawwe ynskeakele op 'e replika, dan krije jo noch in autovacuumslot op' e master, it sil oankomme fan 'e replika. Mar der sille teminsten gjin slûzen wêze. En der sil loks wêze. Wy hawwe it oer gegevensferoarings, dus slûzen binne hjir in wichtich punt. En as dit alles is foar in lange, lange tiid, dan wurde hieltyd mear transaksjes beskoattele. Se kinne oaren stelle. En lok beammen ferskine. Ik joech in keppeling nei it snippet. En dit probleem wurdt rapper merkber as it probleem mei autovacuum, dat allinich kin accumulearje.
Tank foar it ferslach! Jo hawwe jo rapport begon troch te sizzen dat jo ferkeard testen hawwe. Wy sette ús idee troch dat wy deselde apparatuer moatte nimme, mei de basis op deselde manier. Litte wy sizze dat wy de ûntwikkelder in basis joegen. En hy foldie oan it fersyk. En hy liket goed te wêzen. Mar hy kontrolearret net foar live, mar foar live, bygelyks, hawwe wy in lading fan 60-70%. En sels as wy dizze tuning brûke, wurket it net heul goed.
In ekspert yn it team hawwe en DBA-eksperts brûke dy't kinne foarsizze wat der barre sil mei in echte eftergrûnlading is wichtich. As wy krekt ús skjinne feroarings rieden, sjogge wy de foto. Mar in mear avansearre oanpak, doe't wy diene itselde ding wer, mar mei in lading simulearre mei produksje. It is aardich. Oant dan moatte jo opgroeie. It is as in folwoeksene. Wy hawwe gewoan sjoen wat wy hawwe en ek sjoen oft wy genôch middels hawwe. Dat is in goede fraach.
As wy al dogge in garbage selektearje en wy hawwe, bygelyks, in wiske flagge
Dit is wat autovacuum automatysk docht yn Postgres.
Och, docht er it?
Autovacuum is de garbage collector.
Tankewol!
Tank foar it ferslach! Is der in opsje om fuortendaliks in databank mei partitionearring op sa'n manier te ûntwerpen dat alle jiskefet fan 'e haadtafel earne oan 'e kant smoarch wurdt?
Fansels hawwe.
Is it dan mooglik om ússels te beskermjen as wy in tafel opsletten hawwe dy't net brûkt wurde moat?
Fansels hawwe. Mar it is as in kip en aai fraach. As wy allegearre witte wat der barre sil yn 'e takomst, dan sille wy fansels alles cool dwaan. Mar it bedriuw feroaret, d'r binne nije kolommen, nije oanfragen. En dan - oeps, wy wolle it fuorthelje. Mar dizze ideale situaasje, yn it libben komt it foar, mar net altyd. Mar oer it algemien is it in goed idee. Krekt truncate en dat is it.
Boarne: www.habr.com