Nekoč v daljni prihodnosti bo avtomatsko odstranjevanje nepotrebnih podatkov ena izmed pomembnih nalog DBMS [1]. Medtem pa moramo sami poskrbeti za brisanje ali selitev nepotrebnih podatkov v cenejše pomnilniške sisteme. Recimo, da se odločite izbrisati nekaj milijonov vrstic. Precej preprosta naloga, sploh če je stanje znano in obstaja ustrezen indeks. "DELETE FROM table1 WHERE col1 = :value" - kaj bi lahko bilo bolj preprosto, kajne?
Video:
-
V programskem odboru Highload sem že od prvega leta, torej od leta 2007.
-
Pri Postgresu sem zaposlen od leta 2005. Uporabil ga je v številnih projektih.
-
Skupina z RuPostges tudi od leta 2007.
-
Na Meetupu smo zrasli na 2100+ udeležencev. Je drugi na svetu za New Yorkom, za dolgo časa ga je prehitel San Francisco.
-
Že nekaj let živim v Kaliforniji. Več se ukvarjam z ameriškimi podjetji, tudi velikimi. So aktivni uporabniki Postgresa. In tam je marsikaj zanimivega.
je moje podjetje. Ukvarjamo se z avtomatizacijo opravil, ki odpravljajo upočasnitve razvoja.
Če nekaj počnete, potem so včasih kakšni čepi okoli Postgresa. Recimo, da morate počakati, da skrbnik namesto vas nastavi testno stojalo, ali pa morate počakati, da vam DBA odgovori. In takšna ozka grla najdemo v procesu razvoja, testiranja in administracije ter jih poskušamo odpraviti s pomočjo avtomatizacije in novih pristopov.
Pred kratkim sem bil na VLDB v Los Angelesu. To je največja konferenca o bazah podatkov. In tam je bilo poročilo, da v prihodnosti DBMS ne bo samo shranjeval, ampak tudi samodejno brisal podatke. To je nova tema.
Podatkov v svetu zetabajtov je vedno več – to je 1 petabajtov. In zdaj že ocenjujejo, da imamo na svetu shranjenih več kot 000 zetabajtov podatkov. In vedno več jih je.
In kaj storiti z njim? Očitno ga je treba odstraniti. Tukaj je povezava do tega zanimivega poročila. Vendar to doslej ni bilo implementirano v DBMS.
Tisti, ki znajo šteti denar, želijo dvoje. Želijo, da izbrišemo, tako da bi tehnično morali to narediti.
Naslednjič bom povedal neko abstraktno situacijo, ki vključuje kopico realnih situacij, torej nekakšno kompilacijo tega, kar se je meni in okoliškim bazam dejansko dogajalo večkrat, mnogo let. Grablje so vsepovsod in vsi ves čas stopajo nanje.
Recimo, da imamo bazo ali več baz, ki rastejo. In nekateri zapisi so očitno smeti. Na primer, uporabnik je tam nekaj začel delati, vendar tega ni končal. In čez nekaj časa vemo, da tega nedokončanega ni več mogoče shraniti. To pomeni, da bi radi očistili nekaj smeti, da bi prihranili prostor, izboljšali zmogljivost itd.
Na splošno je naloga avtomatizirati odstranitev določenih stvari, določenih vrstic v neki tabeli.
In imamo tako zahtevo, o kateri bomo danes govorili, torej o odvozu smeti.
Za to smo prosili izkušenega razvijalca. Vzel je to zahtevo, jo sam preveril - vse deluje. Preizkušeno na uprizoritvi - vse je v redu. Razvaljano - vse deluje. Enkrat na dan ga izvajamo - vse je v redu.
Baza podatkov raste in raste. Dnevni DELETE začne delovati nekoliko počasneje.
Potem ugotovimo, da imamo zdaj tržno podjetje in bo promet nekajkrat večji, zato se odločimo, da začasno ustavimo nepotrebne stvari. In pozabi vrniti.
Nekaj mesecev kasneje so se spomnili. In ta razvijalec je zapustil ali je zaposlen z nečim drugim, drugemu je naročil, naj ga vrne.
Preveril je dev, staging - vse je v redu. Seveda morate še vedno počistiti, kar se je nabralo. Preveril je, da vse deluje.
Kaj se zgodi potem? Takrat se nam vse podre. Pade tako, da na neki točki vse pade dol. Vsi so v šoku, nihče ne razume, kaj se dogaja. In potem se izkaže, da je bila zadeva v tem IZBRISU.
Nekaj je šlo narobe? Tukaj je seznam, kaj bi lahko šlo narobe. Kateri od teh je najpomembnejši?
-
Na primer, pregleda ni bilo, to pomeni, da ga strokovnjak DBA ni pogledal. Z izkušenim očesom bi takoj našel težavo, poleg tega pa ima dostop do proda, kjer se je nabralo več milijonov vrstic.
-
Mogoče so kaj narobe preverili.
-
Morda je strojna oprema zastarela in morate to osnovo nadgraditi.
-
Ali pa je nekaj narobe s samo bazo podatkov in moramo preiti s Postgresa na MySQL.
-
Ali pa je morda kaj narobe z operacijo.
-
So morda kakšne napake v organizaciji dela in morate nekoga odpustiti in zaposliti najboljše ljudi?
Preverjanja DBA ni bilo. Če bi obstajal DBA, bi videl teh nekaj milijonov vrstic in bi tudi brez poskusov rekel: "Tega ne počnejo." Recimo, če bi bila ta koda v GitLabu, GitHubu in bi obstajal postopek pregleda kode in ne bi bilo tako, da bi brez odobritve DBA ta operacija potekala na produktu, potem bi očitno DBA rekel: »Tega ni mogoče storiti. ”
In rekel bi, da boš imel težave z IO diska in da bodo vsi procesi ponoreli, lahko pride do zaklepanja, pa tudi avtovakuum boš blokiral za kup minut, tako da to ni dobro.
Druga napaka - preverili so na napačnem mestu. Naknadno smo videli, da se je na prodju nabralo veliko neželenih podatkov, vendar razvijalec ni imel zbranih podatkov v tej zbirki podatkov in nihče ni ustvaril teh smeti med uprizarjanjem. V skladu s tem je bilo 1 vrstic, ki so se hitro obnesle.
Zavedamo se, da so naši testi šibki, kar pomeni, da zgrajeni proces ne odkrije težav. Ustrezen poskus DB ni bil izveden.
Idealen poskus je po možnosti izveden na isti opremi. Tega ni vedno mogoče narediti na isti opremi, vendar je zelo pomembno, da gre za kopijo baze podatkov v polni velikosti. To je tisto, kar pridigam že nekaj let. In pred enim letom sem govoril o tem, vse si lahko ogledate na YouTubu.
Mogoče je naša oprema slaba? Če pogledate, potem je latenca poskočila. Videli smo, da je izkoriščenost 100-odstotna. Seveda, če bi bili to sodobni diski NVMe, potem bi nam bilo verjetno veliko lažje. In morda se od tega ne bi ulegli.
Če imate oblake, potem nadgradnjo enostavno izvedete tam. Izdelal nove replike na novi strojni opremi. preklopiti. In vse je dobro. Precej enostavno.
Ali se je mogoče nekako dotakniti manjših diskov? In tukaj se samo s pomočjo DBA poglobimo v določeno temo, imenovano nastavitev kontrolnih točk. Izkazalo se je, da nismo imeli nastavitve kontrolne točke.
Kaj je kontrolna točka? Je v kateri koli DBMS. Ko imate v pomnilniku podatke, ki se spremenijo, se ne zapišejo takoj na disk. Informacija, da so se podatki spremenili, se najprej zapiše v dnevnik vnaprejšnjega pisanja. In na neki točki se DBMS odloči, da je čas za izpis dejanskih strani na disk, tako da lahko, če pride do napake, naredimo manj REDO. Je kot igrača. Če nas ubijejo, bomo igro začeli od zadnje kontrolne točke. In vsi DBMS to izvajajo.
Nastavitve v Postgresu zaostajajo. Zasnovani so za 10–15 let stare količine podatkov in transakcij. In kontrolna točka ni izjema.
Tukaj so informacije iz našega poročila o pregledu Postgres, tj. samodejni zdravstveni pregled. In tukaj je nekaj terabajtov baze podatkov. In dobro se vidi, da so prisilne kontrolne točke skoraj v 90% primerov.
Kaj to pomeni? Tam sta dve nastavitvi. Kontrolna točka lahko pride po časovni omejitvi, na primer v 10 minutah. Lahko pa pride, ko je izpolnjenih precej podatkov.
Privzeto je max_wal_saze nastavljen na 1 gigabajt. Pravzaprav se to res zgodi v Postgresu po 300-400 megabajtih. Spremenili ste toliko podatkov in zgodi se vaša kontrolna točka.
In če je nihče ni prilagodil in je storitev rasla in podjetje zasluži veliko denarja, ima veliko transakcij, potem kontrolna točka pride enkrat na minuto, včasih vsakih 30 sekund, včasih pa se celo prekriva. To je precej slabo.
In poskrbeti moramo, da prihaja manj pogosto. To pomeni, da lahko povečamo max_wal_size. In prihajalo bo manj pogosto.
Razvili pa smo celotno metodologijo, kako to narediti pravilneje, torej kako se odločiti o izbiri nastavitev, jasno na podlagi konkretnih podatkov.
V skladu s tem izvajamo dve seriji poskusov na bazah podatkov.
Prva serija - spremenimo max_wal_size. In izvajamo obsežno operacijo. Najprej to naredimo s privzeto nastavitvijo 1 gigabajt. In naredimo veliko DELETE več milijonov vrstic.
Saj vidite, kako nam je težko. Vidimo, da je disk IO zelo slab. Pogledamo, koliko WAL smo ustvarili, ker je to zelo pomembno. Poglejmo, kolikokrat se je kontrolna točka zgodila. In vidimo, da ni dobro.
Nato povečamo max_wal_size. Ponavljamo. Povečujemo, ponavljamo. In tako velikokrat. Načeloma je dobro 10 točk, kjer je 1, 2, 4, 8 gigabajtov. In pogledamo obnašanje določenega sistema. Jasno je, da mora biti tukaj oprema kot na prod. Imeti morate enake diske, enako količino pomnilnika in enake nastavitve Postgres.
In na ta način bomo zamenjali naš sistem in vemo, kako se bo DBMS obnašal v primeru slabe množične DELETE, kako bo kontrolno točko.
Kontrolna točka v ruščini so kontrolne točke.
Primer: DELETE več milijonov vrstic po indeksu, vrstice so "razpršene" po straneh.
Tukaj je primer. To je neka baza. In s privzeto nastavitvijo 1 gigabajta za max_wal_size je zelo jasno, da gredo naši diski na polico za snemanje. Ta slika je tipičen simptom zelo bolnega bolnika, to pomeni, da se je res slabo počutil. In bila je ena sama operacija, samo DELETE več milijonov vrstic.
Če je taka operacija dovoljena v produ, potem se bomo kar ulegli, ker je jasno, da nas en DELETE ubije v polico.
Nadalje, kjer je 16 gigabajtov, je jasno, da so zobje že odšli. Zobje so že boljši, se pravi, trkamo po stropu, a ni tako slabo. Tam je bilo nekaj svobode. Na desni je zapis. In število operacij - drugi graf. In jasno je, da že pri 16 gigabajtih nekoliko lažje dihamo.
In kje se vidi 64 gigabajtov, da je postal popolnoma boljši. Zobje so že izraziti, več je možnosti preživeti druge operacije in narediti nekaj z diskom.
Zakaj tako?
Malo se bom poglobil v podrobnosti, toda ta tema, kako izvajati nastavitev kontrolnih točk, lahko privede do celotnega poročila, zato ne bom veliko nalagal, ampak bom malo opisal, kakšne težave obstajajo.
Če se kontrolna točka zgodi prepogosto in svoje vrstice ne posodabljamo zaporedno, ampak poiščemo po indeksu, kar je dobro, ker ne izbrišemo celotne tabele, potem se lahko zgodi, da smo se najprej dotaknili prve strani, nato tisoče, in se nato vrnil k prvemu. In če jo je checkpoint med temi obiski prve strani že shranil na disk, potem jo bo shranil še enkrat, ker smo jo drugič umazali.
In večkrat bomo prisilili kontrolno točko, da jo reši. Kako bi mu bile odvečne operacije.
A to še ni vse. Strani so velike 8 kilobajtov v Postgresu in 4 kilobajte v Linuxu. In obstaja nastavitev full_page_writes. Privzeto je omogočeno. In to je prav, saj če ga izklopimo, potem obstaja nevarnost, da se ob sesutju shrani le polovica strani.
Vedenje pisanja v WAL dnevnika posredovanja je takšno, da ko imamo kontrolno točko in prvič spremenimo stran, pride celotna stran, tj. vseh 8 kilobajtov, v dnevnik posredovanja, čeprav smo spremenili samo vrstica, ki tehta 100 bajtov. In zapisati moramo celotno stran.
V nadaljnjih spremembah bo le določena torka, prvič pa zapišemo vse.
In v skladu s tem, če se je kontrolna točka ponovila, potem moramo znova začeti vse iz nič in potisniti celotno stran. Pri pogostih kontrolnih točkah, ko hodimo po istih straneh, bo full_page_writes = on več, kot bi lahko bilo, tj. ustvarimo več WAL. Več se pošlje v replike, v arhiv, na disk.
In v skladu s tem imamo dva presežka.
Če povečamo max_wal_size, se izkaže, da poenostavimo tako kontrolno točko kot zapisovalca wala. In to je super.
Vstavimo terabajt in živimo z njim. Kaj je na tem slabega? To je slabo, ker se bomo v primeru neuspeha vzpenjali ure in ure, saj je bila kontrolna točka že dolgo nazaj in se je že marsikaj spremenilo. In vse to moramo PONOVITI. In tako naredimo drugo serijo poskusov.
Izvedemo operacijo in vidimo, kdaj bo kontrolna točka končana, namenoma ubijemo -9 Postgres.
In potem ga znova zaženemo in vidimo, kako dolgo se bo dvigoval na tej opremi, tj. koliko bo PONOVIL v tej slabi situaciji.
Dvakrat bom opozoril, da je stanje slabo. Prvič, strmoglavili smo tik pred koncem kontrolne točke, tako da lahko veliko izgubimo. In drugič, imeli smo obsežno operacijo. In če bi bile kontrolne točke v časovni omejitvi, bi bilo najverjetneje ustvarjeno manj WAL od zadnje kontrolne točke. To pomeni, da je dvojni poraženec.
Takšno situacijo merimo za različne velikosti max_wal_size in razumemo, da če je max_wal_size 64 gigabajtov, potem bomo v dvojnem najslabšem primeru plezali 10 minut. In razmišljamo, ali nam ustreza ali ne. To je poslovno vprašanje. To sliko moramo pokazati tistim, ki so odgovorni za poslovne odločitve, in se vprašati: »Koliko časa lahko največ ležimo v primeru težave? Ali se lahko v najslabšem položaju uležemo 3-5 minut? In ti se odloči.
In tukaj je zanimiva točka. Na konferenci imamo nekaj poročil o Patroniju. In morda ga uporabljate. To je samodejni preklop za Postgres. GitLab in Data Egret sta govorila o tem.
In če imate samodejni preklop, ki pride v 30 sekundah, potem morda lahko ležimo za 10 minut? Ker bomo do tega trenutka prešli na repliko in bo vse v redu. To je sporna točka. Ne poznam jasnega odgovora. Preprosto čutim, da ta tema ni le okrevanje po zrušitvi.
Če imamo po neuspehu dolgo okrevanje, potem nam bo v mnogih drugih situacijah neprijetno. Na primer pri istih poskusih, ko nekaj počnemo in moramo včasih čakati 10 minut.
Še vedno ne bi šel predaleč, tudi če imamo samodejno preklop. Praviloma so vrednosti, kot je 64, 100 gigabajtov, dobre vrednosti. Včasih se celo splača izbrati manj. Na splošno je to subtilna znanost.
Če želite izvesti iteracije, na primer max_wal_size =1, 8, morate množično operacijo ponoviti večkrat. Uspelo ti je. In na isti bazi, ki jo želite ponoviti, pa ste že vse izbrisali. Kaj storiti?
Pozneje bom govoril o naši rešitvi, kaj naredimo, da ponovimo v takih situacijah. In to je najbolj pravilen pristop.
Toda v tem primeru smo imeli srečo. Če, kot piše tukaj "ZAČNI, IZBRIŠI, POVRNI NAZAD", potem lahko ponovimo IZBRIS. Se pravi, če smo ga sami preklicali, potem ga lahko ponovimo. In fizično pri vas bodo podatki ležali na istem mestu. Sploh ne dobiš napihnjenosti. Takšne DELETE lahko ponavljate.
Ta funkcija DELETE with ROLLBACK je idealna za nastavitev kontrolnih točk, tudi če nimate pravilno razporejenih laboratorijev baze podatkov.
Naredili smo ploščo z enim stolpcem "i". Postgres ima pomožne stolpce. Nevidni so, razen če se to posebej zahteva. To so: ctid, xmid, xmax.
Ctid je fizični naslov. Ničelna stran, prvi niz na strani.
Vidi se, da je po ROOLBACKu tuple ostal na istem mestu. To pomeni, da lahko poskusimo znova, obnašalo se bo enako. To je glavna stvar.
Xmax je čas smrti tuple. Bila je žigosana, vendar Postgres ve, da je bila transakcija vrnjena nazaj, tako da ni pomembno, ali je 0 ali je transakcija vrnjena nazaj. To nakazuje, da je mogoče ponoviti DELETE in preveriti množične operacije vedenja sistema. Za revne lahko naredite laboratorije podatkovnih baz.
Tu gre za programerje. Tudi o DBA vedno grajajo programerje zaradi tega: "Zakaj delate tako dolge in težke operacije?". To je povsem druga perpendikularna tema. Včasih je bila administracija, zdaj bo razvoj.
Očitno nismo razpadli na koščke. To je jasno. Nemogoče je, da ne bi razbili takšnega DELETE za kup milijonov vrstic na dele. To bo storjeno 20 minut in vse bo ležalo. Toda na žalost tudi izkušeni razvijalci delajo napake, tudi v zelo velikih podjetjih.
Zakaj je pomembno zlomiti?
-
Če vidimo, da je disk trd, ga upočasnimo. In če smo zlomljeni, potem lahko dodamo premore, lahko upočasnimo dušenje.
-
In drugih še dolgo ne bomo blokirali. V nekaterih primerih ni pomembno, če brišete prave smeti, s katerimi se nihče ne ukvarja, potem najverjetneje ne boste nikogar blokirali, razen avtovakuumskega dela, ker bo počakalo na dokončanje transakcije. Če pa odstraniš nekaj, kar lahko nekdo drug zahteva, potem bo blokiran, prišlo bo do neke vrste verižne reakcije. Na spletnih mestih in v mobilnih aplikacijah se je treba izogibati dolgim transakcijam.
To je zanimivo. Pogosto vidim, da razvijalci sprašujejo: "Kakšno velikost paketa naj izberem?".
Jasno je, da večja kot je velikost svežnja, manjši so režijski stroški transakcij, tj. dodatni režijski stroški zaradi transakcij. Toda hkrati se podaljša čas za to transakcijo.
Imam zelo preprosto pravilo: vzemite čim več, vendar ne prekoračite izvedljivih datotek na sekundo.
Zakaj drugo? Razlaga je zelo preprosta in razumljiva vsem, tudi netehničnim ljudem. Vidimo reakcijo. Vzemimo 50 milisekund. Če se je nekaj spremenilo, se bo naše oko odzvalo. Če manj, potem težje. Če se nekaj odzove po 100 milisekundah, na primer, ste kliknili z miško in vam je odgovorila po 100 milisekundah, že čutite to rahlo zamudo. Sekunda se že dojema kot zavore.
V skladu s tem, če naše množične operacije razdelimo na 10-sekundne rafale, potem obstaja tveganje, da bomo nekoga blokirali. In delovalo bo nekaj sekund in ljudje bodo to že opazili. Zato raje ne naredim več kot sekundo. Toda hkrati ga ne razdrobite zelo drobno, ker bodo opazni režijski stroški transakcije. Podlaga bo trša in lahko se pojavijo druge različne težave.
Izberemo velikost paketa. V vsakem primeru lahko naredimo drugače. Lahko se avtomatizira. In prepričani smo o učinkovitosti obdelave enega pakiranja. To pomeni, da naredimo DELETE enega paketa ali UPDATE.
Mimogrede, vse, o čemer govorim, ni samo DELETE. Kot ste uganili, so to vse množične operacije s podatki.
In vidimo, da je načrt odličen. Ogledate si lahko skeniranje indeksa, skeniranje samo indeksa je še boljše. In vpletenih imamo majhno količino podatkov. In manj kot sekunda se izpolni. Super.
In še vedno moramo zagotoviti, da ne pride do degradacije. Zgodi se, da se prvi paketi hitro obnesejo, potem pa je vedno slabše in slabše. Postopek je tak, da morate veliko testirati. Prav temu so namenjeni laboratoriji za baze podatkov.
In še vedno moramo nekaj pripraviti, da bomo lahko temu pravilno sledili v proizvodnji. V dnevnik lahko na primer zapišemo čas, lahko napišemo, kje smo zdaj in koga smo zdaj izbrisali. In to nam bo omogočilo, da kasneje razumemo, kaj se dogaja. In če gre kaj narobe, hitro poiščite težavo.
Če moramo preveriti učinkovitost zahtev in moramo večkrat ponoviti, potem obstaja nekaj takega kot kolega bot. Je že pripravljen. Dnevno ga uporablja na desetine razvijalcev. In ve, kako na zahtevo v 30 sekundah dati ogromno terabajtno bazo podatkov, vašo lastno kopijo. In tam lahko nekaj izbrišete in rečete PONASTAVITE ter znova izbrišete. Z njim lahko eksperimentirate na ta način. Vidim prihodnost za to stvar. In to že počnemo.
Kaj so strategije delitve? Vidim 3 različne strategije particioniranja, ki jih uporabljajo razvijalci na paketu.
Prvi je zelo preprost. Imamo številčni ID. In razdelimo ga na različne intervale in delajmo s tem. Slaba stran je jasna. V prvem segmentu imamo lahko 100 vrstic prave smeti, v drugem 5 vrstic ali pa sploh ne ali pa se bo vseh 1 vrstic izkazalo za smeti. Zelo neenakomerno delo, vendar ga je enostavno zlomiti. Vzeli so maksimalno osebno izkaznico in jo razbili. To je naiven pristop.
Druga strategija je uravnotežen pristop. Uporablja se v Gitlabu. Vzeli so in skenirali mizo. Našli smo meje ID paketov, tako da je imel vsak paket točno 10 zapisov. In jih postavite v čakalno vrsto. In potem obdelamo. To lahko storite v več nitih.
Mimogrede, tudi v prvi strategiji lahko to storite v več nitih. Ni težko.
Vendar obstaja hladnejši in boljši pristop. To je tretja strategija. In ko je mogoče, je bolje, da ga izberete. To naredimo na podlagi posebnega indeksa. V tem primeru bo to najverjetneje indeks v skladu z našim stanjem smeti in ID-jem. ID bomo vključili tako, da bo to samo skeniranje indeksa, da ne bomo šli na kopico.
Na splošno je skeniranje samo indeksa hitrejše od skeniranja indeksa.
In hitro najdemo svoje ID-je, ki jih želimo odstraniti. BATCH_SIZE izberemo vnaprej. In ne samo, da jih dobimo, dobimo jih na poseben način in jih takoj vdremo. Zaklepamo pa zato, da če so že zaklenjene, jih ne zaklenemo, ampak gremo naprej in vzamemo naslednje. To je za zaklenjen preskok posodobitve. Ta super lastnost Postgresa nam omogoča delo v več nitih, če želimo. Možno je v enem toku. In tukaj je CTE - to je ena zahteva. In v drugem nadstropju tega CTE poteka resnično brisanje - returning *. ID lahko vrnete, vendar je bolje *če nimate veliko podatkov o vsaki vrstici.
Zakaj ga potrebujemo? To je tisto, o čemer moramo poročati. Zdaj smo dejansko izbrisali toliko vrstic. In imamo meje po ID-ju ali po created_at, kot je ta. Naredite lahko min, max. Lahko se še kaj naredi. Tukaj lahko natrpaš marsikaj. In to je zelo priročno za spremljanje.
Še ena opomba glede kazala. Če se odločimo, da za to nalogo potrebujemo poseben indeks, se moramo prepričati, da ne pokvari posodobitev samo kopice. To pomeni, da ima Postgres takšno statistiko. To lahko vidite v pg_stat_user_tables za vašo tabelo. Vidite lahko, ali se uporabljajo vroče posodobitve ali ne.
Obstajajo situacije, ko jih lahko vaš novi indeks preprosto odreže. In imate vse druge posodobitve, ki že delujejo, počasi. Ne samo zato, ker se je indeks pojavil (vsak indeks malo upočasni posodobitve, ampak malo), tukaj pa ga še vedno uniči. In za to tabelo je nemogoče narediti posebno optimizacijo. To se zgodi včasih. To je tako subtilnost, ki se je malo ljudi spomni. In na te grablje je lahko stopiti. Včasih se zgodi, da morate najti pristop z druge strani in še vedno storiti brez tega novega indeksa ali narediti drug indeks ali kako drugače, na primer, lahko uporabite drugo metodo.
Ampak to je najbolj optimalna strategija, kako se z eno zahtevo razdeliti na serije in streljati na serije, malo izbrisati itd.
Dolge transakcije
Blokiran avtovakuum -
težava z blokiranjem -
Napaka št. 5 je velika. Nikolai iz podjetja Okmeter je govoril o spremljanju Postgresa. Idealno spremljanje Postgres žal ne obstaja. Nekateri so bližje, drugi dlje. Okmeter je dovolj blizu popolnosti, vendar veliko manjka in ga je treba dodati. Na to morate biti pripravljeni.
Na primer, mrtve tuple je najbolje spremljati. Če imate v tabeli veliko mrtvih stvari, je nekaj narobe. Bolje je, da reagiramo zdaj, sicer lahko pride do degradacije in se lahko uležemo. Zgodi se.
Če je IO velik, potem je jasno, da to ni dobro.
Tudi dolge transakcije. Dolge transakcije na OLTP ne bi smele biti dovoljene. In tukaj je povezava do delčka, ki vam omogoča, da vzamete ta delček in že sledite dolgim transakcijam.
Zakaj so dolge transakcije slabe? Ker se bodo vse ključavnice sprostile šele na koncu. In zajebemo vse. Poleg tega blokiramo avtomatski vakuum za vse mize. Sploh ni dobro. Tudi če imate na replici omogočeno vročo pripravljenost, je še vedno slabo. Na splošno se nikjer ni bolje izogibati dolgim transakcijam.
Če imamo veliko miz, ki niso posesane, potem moramo imeti opozorilo. Tu je takšna situacija možna. Na delovanje avtovakuma lahko vplivamo posredno. To je delček iz Avita, ki sem ga nekoliko izboljšal. In izkazalo se je, da je zanimivo orodje, da vidimo, kaj imamo z avtovakuumom. Na primer, nekatere mize tam čakajo in ne bodo počakale na vrsto. Prav tako ga morate dati v nadzor in imeti opozorilo.
In izda bloke. Gozd blokovskih dreves. Rad vzamem nekaj od nekoga in izboljšam. Tu sem vzel kul rekurzivni CTE iz Data Egret, ki prikazuje gozd dreves ključavnic. To je dobro diagnostično orodje. In na njegovi podlagi lahko zgradite tudi spremljanje. Toda to je treba storiti previdno. Zase morate narediti majhen statement_timeout. In lock_timeout je zaželen.
Včasih se vse te napake pojavijo skupaj.
Po mojem mnenju je tu glavna napaka organizacijska. Je organizacijsko, saj tehnika ne vleče. To je številka 2 - preverili so na napačnem mestu.
Preverili smo na napačnem mestu, ker nismo imeli proizvodnega klona, ki ga je enostavno preveriti. Razvijalec morda sploh nima dostopa do proizvodnje.
In tam nismo preverili. Če bi tam preverili, bi to videli tudi sami. Razvijalec je vse videl tudi brez DBA, če je preveril v dobrem okolju, kjer je enaka količina podatkov in identična lokacija. Videl bi vso to degradacijo in bi ga bilo sram.
Več o avtovakumu. Ko smo opravili obsežno brisanje več milijonov vrstic, moramo še vedno izvesti REPACK. To je še posebej pomembno za indekse. Počutili se bodo slabo, ko bomo tam vse očistili.
In če želite vrniti vsakodnevno delo čiščenja, predlagam, da to počnete pogosteje, vendar manj. Lahko enkrat na minuto ali celo pogosteje po malem. In spremljati morate dve stvari: da ta stvar nima napak in da ne zaostaja. Trik, ki sem ga pokazal, bo rešil to.
Kar delamo, je odprtokodno. Objavljeno je na GitLabu. In naredimo tako, da lahko ljudje preverijo tudi brez DBA. Delamo bazo podatkov, to je, imenujemo osnovno komponento, na kateri Joe trenutno dela. In lahko zgrabite kopijo proizvodnje. Zdaj obstaja implementacija Joe za slack, tam lahko rečete: "razloži takšno in takšno zahtevo" in takoj dobite rezultat za svojo kopijo baze podatkov. Tam lahko celo IZBRIŠEŠ, pa tega ne bo nihče opazil.
Recimo, da imate 10 terabajtov, naredimo bazo podatkov laboratorija tudi 10 terabajtov. S sočasnimi 10 terabajtnimi bazami podatkov lahko 10 razvijalcev dela hkrati. Vsak lahko počne, kar hoče. Lahko izbriše, spusti itd. To je taka fantazija. O tem bomo govorili jutri.
To se imenuje tanko zagotavljanje. To je subtilno zagotavljanje. To je neke vrste fantazija, ki močno odpravi zamude pri razvoju, pri testiranju in naredi svet v tem pogledu boljši. To pomeni, da vam samo omogoča, da se izognete težavam z množičnimi operacijami.
Primer: baza podatkov s 5 terabajti, pridobitev kopije v manj kot 30 sekundah. In sploh ni odvisno od velikosti, torej ni pomembno, koliko terabajtov.
Danes lahko greš na in se poglobite v naša orodja. Lahko se registrirate, da vidite, kaj je tam. Ta bot lahko namestite. Zastonj je. Pišite.
vprašanja
Zelo pogosto se v resničnih situacijah izkaže, da je podatkov, ki bi morali ostati v tabeli, veliko manj, kot jih je treba izbrisati. To pomeni, da je v takšni situaciji pogosto lažje izvajati takšen pristop, ko je lažje ustvariti nov objekt, tam kopirati samo potrebne podatke in razdeliti staro tabelo. Jasno je, da je v tem trenutku potreben programski pristop, medtem ko boste menjavali. Kakšen je ta pristop?
To je zelo dober pristop in zelo dobra naloga. Zelo podobno je temu, kar počne pg_repack, zelo podobno je temu, kar morate storiti, ko ID-je naredite 4-bajtne. Veliko ogrodij je to storilo pred nekaj leti in ravno plošče so zrasle in jih je treba pretvoriti v 8 bajtov.
Ta naloga je precej težka. Uspelo nam je. In moraš biti zelo previden. Obstajajo ključavnice itd. Ampak to se dela. To pomeni, da je standardni pristop uporaba pg_repack. Takšno oznako prijaviš. In preden začnete vanj nalagati posnetke podatkov, deklarirate tudi eno ploščo, ki spremlja vse spremembe. Obstaja trik, da nekaterim spremembam morda sploh ne sledite. Obstajajo tankosti. In potem preklapljate s premikanjem sprememb. Nastala bo kratka pavza, ko bomo vse zaprli, a na splošno se to dela.
Če pogledate pg_repack na GitHubu, potem je tam, ko je obstajala naloga za pretvorbo ID-ja iz int 4 v int 8, obstajala ideja, da bi uporabili sam pg_repack. Tudi to je možno, vendar je malo kramp, vendar bo delovalo tudi za to. Lahko posežete v sprožilec, ki ga uporablja pg_repack, in tam rečete: "Teh podatkov ne potrebujemo", kar pomeni, da prenesemo samo tisto, kar potrebujemo. In potem samo zamenja in to je to.
S tem pristopom še vedno dobimo drugo kopijo tabele, v kateri so podatki že indeksirani in zelo enakomerno zloženi s čudovitimi indeksi.
Napihnjenost ni prisotna, je dober pristop. Vem pa, da se za to poskuša razviti avtomatizacija, torej narediti univerzalno rešitev. Lahko te povežem s to avtomatizacijo. Napisan je v Pythonu, kar je dobro.
Sem samo malo iz sveta MySQL, zato sem prišel poslušat. In ta pristop uporabljamo.
Ampak to je le, če imamo 90%. Če imamo 5 %, potem ga ni zelo dobro uporabiti.
Hvala za poročilo! Če ni sredstev za izdelavo popolne kopije izdelka, ali obstaja kakšen algoritem ali formula za izračun obremenitve ali velikosti?
Dobro vprašanje. Zaenkrat lahko najdemo večterabajtne baze podatkov. Tudi če tam strojna oprema ni enaka, na primer manj pomnilnika, manj procesorja in diskov ni povsem enako, a vseeno to počnemo. Če ni popolnoma nikjer, potem morate razmišljati. Naj pomislim do jutri, prišel si, se bova pogovorila, to je dobro vprašanje.
Hvala za poročilo! Najprej ste začeli s tem, da obstaja kul Postgres, ki ima takšne in drugačne omejitve, a se razvija. In vse to je na splošno bergla. Ali ni to vse v konfliktu s samim razvojem Postgresa, v katerem se bo pojavil kakšen DELETE deferent ali kaj drugega, kar bi moralo držati na nizkem nivoju to, kar hočemo zamazati z nekimi našimi čudnimi sredstvi tukaj?
Če smo v SQL rekli, da izbrišemo ali posodobimo veliko zapisov v eni transakciji, kako lahko potem Postgres to tam distribuira? V delovanju smo fizično omejeni. To bomo še dolgo počeli. In v tem času bomo zaklenili itd.
Končano z indeksi.
Predvidevam lahko, da bi lahko isto nastavitev kontrolne točke avtomatizirali. Nekoč bo morda. Ampak potem res ne razumem vprašanja.
Vprašanje je, ali obstaja tak vektor razvoja, ki gre sem in tja, tukaj pa gre vaš vzporedno? Tisti. Ali o tem še niso razmišljali?
Govoril sem o načelih, ki jih je mogoče uporabiti zdaj. Obstaja še en bot , s tem lahko izvedete samodejno nastavitev kontrolne točke. Bo nekoč v Postgresu? Ne vem, o tem se sploh še ni razpravljalo. Še daleč smo od tega. Toda obstajajo znanstveniki, ki ustvarjajo nove sisteme. In nas porinejo v avtomatske indekse. Obstaja razvoj dogodkov. Ogledate si lahko na primer samodejno uglaševanje. Samodejno izbere parametre. Ampak še ne bo naredil nastavitve kontrolnih točk namesto vas. To pomeni, da se bo pobral glede zmogljivosti, medpomnilnika lupine itd.
In za nastavitev kontrolnih točk lahko naredite tole: če imate tisoč gruč in različno strojno opremo, različne virtualne stroje v oblaku, lahko uporabite našega bota narediti avtomatizacijo. In max_wal_size bo samodejno izbran glede na vaše ciljne nastavitve. A zaenkrat to v jedru žal ni niti približno.
Dober večer Govorili ste o nevarnostih dolgih transakcij. Rekli ste, da je avtovakuum blokiran v primeru izbrisov. Kako nam sicer škodi? Ker govorimo bolj o tem, da sprostimo prostor in ga lahko uporabimo. Kaj nam še manjka?
Avtovakuum tukaj morda ni največji problem. In dejstvo, da lahko dolga transakcija zaklene druge transakcije, je ta možnost bolj nevarna. Lahko se sreča ali pa tudi ne. Če se je srečala, potem je lahko zelo slabo. In z avtovakuumom - to je tudi problem. Pri dolgih transakcijah v OLTP obstajata dve težavi: zaklepanje in samodejno vakuumiranje. In če imate na replici omogočeno povratno informacijo v vročem stanju pripravljenosti, boste še vedno prejeli samodejno vakuumsko ključavnico na masterju, ki bo prispela iz replike. A vsaj ključavnic ne bo. Pa še loki bodo. Govorimo o spremembah podatkov, zato so ključavnice tu pomembna točka. In če vse to traja dolgo, dolgo, potem je vse več transakcij zaklenjenih. Druge lahko ukradejo. In pojavijo se drevesa lok. Dal sem povezavo do izrezka. In ta težava postane bolj opazna hitreje kot težava z avtovakuumom, ki se lahko samo kopiči.
Hvala za poročilo! Svoje poročilo ste začeli z besedami, da ste testirali napačno. Nadaljevali smo z našo idejo, da moramo vzeti isto opremo, z osnovo na enak način. Recimo, da smo razvijalcu dali osnovo. In prošnji je ugodil. In zdi se, da je v redu. Ampak on ne preverja za živo, ampak za živo, na primer, imamo obremenitev 60-70%. In tudi če uporabimo to uglasitev, ne deluje zelo dobro.
Pomembno je imeti strokovnjaka v ekipi in uporabiti strokovnjake DBA, ki lahko predvidijo, kaj se bo zgodilo z dejansko obremenitvijo v ozadju. Ko smo pravkar izvedli čiste spremembe, vidimo sliko. Toda naprednejši pristop, ko smo spet naredili isto, vendar z obremenitvijo, simulirano s proizvodnjo. Je čisto kul. Do takrat pa moraš odrasti. Je kot odrasel. Pogledali smo le, kaj imamo, in tudi, ali imamo dovolj sredstev. To je dobro vprašanje.
Ko že delamo garbage select in imamo na primer izbrisano zastavico
To je tisto, kar autovacuum naredi samodejno v Postgresu.
Oh, ali to počne?
Avtovakuum je zbiralnik smeti.
Hvala!
Hvala za poročilo! Ali obstaja možnost, da takoj zasnujete bazo s particioniranjem tako, da se vse smeti umažejo iz glavne tabele nekam ob strani?
Seveda so.
Ali se potem lahko zaščitimo, če imamo zaklenjeno mizo, ki je ne bi smeli uporabljati?
Seveda imajo. Ampak to je kot vprašanje kokoš in jajce. Če vsi vemo, kaj se bo zgodilo v prihodnosti, potem bomo seveda naredili vse kul. Toda posel se spreminja, nove so rubrike, nove zahteve. In potem – ups, želimo ga odstraniti. Toda ta idealna situacija se v življenju zgodi, vendar ne vedno. Toda na splošno je to dobra ideja. Samo skrajšaj in to je to.
Vir: www.habr.com