Negdje u dalekoj budućnosti, automatsko uklanjanje nepotrebnih podataka bit će jedan od važnih zadataka DBMS-a [1]. U međuvremenu se sami trebamo pobrinuti za brisanje ili premještanje nepotrebnih podataka u jeftinije sustave za pohranu. Recimo da odlučite izbrisati nekoliko milijuna redaka. Prilično jednostavan zadatak, pogotovo ako je stanje poznato i postoji odgovarajući indeks. "DELETE FROM table1 WHERE col1 = :value" - što bi moglo biti jednostavnije, zar ne?
Video:
-
U odboru programa Highload sam od prve godine, odnosno od 2007. godine.
-
A u Postgresu sam od 2005. Koristio ga u mnogim projektima.
-
Grupa s RuPostges također od 2007.
-
Na Meetupu smo narasli na 2100+ sudionika. Drugi je u svijetu nakon New Yorka, dugo ga je pretekao San Francisco.
-
Živim u Kaliforniji nekoliko godina. Više radim s američkim tvrtkama, uključujući velike. Aktivni su korisnici Postgresa. A ima tu svašta zanimljivog.
je moja tvrtka. Bavimo se automatizacijom zadataka koji eliminiraju usporavanje razvoja.
Ako nešto radite, onda ponekad postoje nekakvi čepovi oko Postgresa. Recimo da trebate pričekati da vam administrator postavi testni štand ili trebate pričekati da vam DBA odgovori. A mi pronalazimo takva uska grla u procesu razvoja, testiranja i administracije i pokušavamo ih otkloniti uz pomoć automatizacije i novih pristupa.
Nedavno sam bio na VLDB-u u Los Angelesu. Ovo je najveća konferencija o bazama podataka. I bilo je izvješće da u budućnosti DBMS neće samo pohranjivati, već i automatski brisati podatke. Ovo je nova tema.
Sve je više podataka u svijetu zetabajta – to je 1 petabajta. A sada se već procjenjuje da imamo više od 000 zetabajta podataka pohranjenih u svijetu. A takvih je sve više.
I što učiniti s tim? Očito ga treba ukloniti. Evo poveznice na ovo zanimljivo izvješće. Ali do sada to nije implementirano u DBMS.
Oni koji znaju brojati novac žele dvije stvari. Žele da izbrišemo, tako da bismo tehnički to trebali moći učiniti.
Ono što ću dalje ispričati je neka apstraktna situacija koja uključuje gomilu stvarnih situacija, tj. neku vrstu kompilacije onoga što se stvarno dogodilo meni i okolnim bazama podataka mnogo puta, mnogo godina. Grablje su posvuda i svi stalno gaze po njima.
Recimo da imamo bazu ili nekoliko baza koje rastu. A neki zapisi su očito smeće. Na primjer, korisnik je tamo počeo nešto raditi, ali nije dovršio. I nakon nekog vremena znamo da se ovo nedovršeno više ne može skladištiti. Odnosno, željeli bismo očistiti neke smeće kako bismo uštedjeli prostor, poboljšali performanse itd.
Općenito, zadatak je automatizirati uklanjanje određenih stvari, određenih redaka u nekoj tablici.
I mi imamo takav zahtjev o kojem ćemo danas govoriti, odnosno o odvozu smeća.
Zamolili smo iskusnog programera da to učini. Uzeo je ovaj zahtjev, provjerio ga za sebe - sve radi. Testirano na pozornici - sve je u redu. Razvaljano - sve radi. Jednom dnevno ga pokrenemo - sve je u redu.
Baza podataka raste i raste. Dnevni DELETE počinje raditi malo sporije.
Onda shvatimo da sada imamo marketinšku tvrtku i da će promet biti nekoliko puta veći, pa odlučujemo privremeno pauzirati nepotrebne stvari. I zaboraviti se vratiti.
Nekoliko mjeseci kasnije sjetili su se. I taj programer je dao otkaz ili je zauzet nečim drugim, uputio je drugog da ga vrati.
Provjerio je na devu, na stagingu - sve je OK. Naravno, i dalje morate počistiti ono što se nakupilo. Provjerio je da sve radi.
Što je slijedeće? Tada nam se sve raspada. Pada tako da u jednom trenutku sve padne. Svi su u šoku, nikome nije jasno što se događa. I onda se pokaže da je stvar bila u ovom DELETE-u.
Nešto je pošlo po zlu? Ovdje je popis onoga što je moglo poći po zlu. Što je od toga najvažnije?
-
Na primjer, nije bilo pregleda, tj. DBA stručnjak ga nije pogledao. On bi iskusnim okom odmah pronašao problem, a osim toga ima pristup produ, gdje se nakupilo nekoliko milijuna redaka.
-
Možda su nešto krivo provjerili.
-
Možda je hardver zastario i morate nadograditi ovu bazu.
-
Ili nešto nije u redu sa samom bazom podataka, pa moramo prijeći s Postgresa na MySQL.
-
Ili možda nešto nije u redu s operacijom.
-
Možda ima grešaka u organizaciji posla pa treba nekoga otpustiti i zaposliti najbolje ljude?
Nije bilo DBA provjere. Da postoji DBA, on bi vidio tih nekoliko milijuna redaka i čak i bez ikakvih eksperimenata rekao bi: "Oni to ne rade." Pretpostavimo da je ovaj kod u GitLabu, GitHubu i da postoji proces pregleda koda i da ne postoji takva stvar da bi se bez odobrenja DBA ova operacija odvijala na proizvodu, tada bi očito DBA rekao: "Ovo se ne može učiniti .”
I rekao bi da ćeš imati problema s IO diska i da će svi procesi poludjeti, može doći do zaključavanja, a također ćeš blokirati autovacuum na hrpu minuta, tako da ovo nije dobro.
Druga greška - provjerili su na krivom mjestu. Naknadno smo vidjeli da se gomila bezvrijednih podataka nakupila na proizvodu, ali programer nije imao akumulirane podatke u ovoj bazi podataka i nitko nije stvorio ovo smeće tijekom faze. Sukladno tome, bilo je 1 redaka koji su brzo uspjeli.
Shvaćamo da su naši testovi slabi, odnosno da proces koji je izgrađen ne otkriva probleme. Nije proveden odgovarajući DB eksperiment.
Idealan pokus poželjno je provesti na istoj opremi. Nije uvijek moguće to učiniti na istoj opremi, ali je vrlo važno da to bude kopija baze podataka u punoj veličini. To je ono što propovijedam već nekoliko godina. I prije godinu dana sam pričao o ovome, sve možete pogledati na YouTubeu.
Možda nam je oprema loša? Ako pogledate, onda je latencija skočila. Vidjeli smo da je iskorištenost 100%. Naravno, da su to moderni NVMe diskovi, onda bi nam vjerojatno bilo puno lakše. A možda i ne bismo legli od toga.
Ako imate oblake, tamo se nadogradnja lako izvodi. Podignuo nove replike na novom hardveru. zamijeniti. I sve je dobro. Poprilično jednostavno.
Je li moguće nekako dotaknuti manje diskove? I ovdje, samo uz pomoć DBA, uranjamo u određenu temu koja se zove podešavanje kontrolnih točaka. Ispostavilo se da nismo imali podešavanje kontrolne točke.
Što je kontrolna točka? Nalazi se u bilo kojem DBMS-u. Kada imate podatke u memoriji koji se mijenjaju, oni se ne zapisuju odmah na disk. Informacija da su podaci promijenjeni prvo se upisuje u dnevnik pisanja unaprijed. I u nekom trenutku, DBMS odluči da je vrijeme da ispiše stvarne stranice na disk, tako da ako imamo kvar, možemo raditi manje REDO. Kao igračka je. Ako poginemo, počet ćemo igru od posljednje kontrolne točke. I svi DBMS-ovi to implementiraju.
Postavke u Postgresu zaostaju. Dizajnirani su za količine podataka i transakcija stare 10-15 godina. Ni kontrolna točka nije iznimka.
Ovdje su podaci iz našeg izvješća o provjeri stanja u Postgresu, tj. automatskoj provjeri zdravlja. A ovdje je neka baza podataka od nekoliko terabajta. A dobro se vidi da su prisilne kontrole u gotovo 90% slučajeva.
Što to znači? Postoje dvije postavke. Kontrolna točka može doći nakon isteka vremena, na primjer, za 10 minuta. Ili se može pojaviti kada se popuni dosta podataka.
I prema zadanim postavkama max_wal_saze je postavljen na 1 gigabajt. Zapravo, to se stvarno događa u Postgresu nakon 300-400 megabajta. Promijenili ste toliko podataka i dogodila se vaša kontrolna točka.
A ako ga nitko nije prilagodio, a usluga je rasla, a tvrtka zarađuje puno novca, ima puno transakcija, tada kontrolna točka dolazi jednom u minuti, ponekad svakih 30 sekundi, a ponekad se čak i preklapa. Ovo je jako loše.
I moramo se pobrinuti da dolazi rjeđe. Odnosno, možemo povećati max_wal_size. I dolazit će rjeđe.
Ali razvili smo čitavu metodologiju kako to učiniti ispravnije, odnosno kako donijeti odluku o odabiru postavki, jasno na temelju konkretnih podataka.
Sukladno tome, radimo dvije serije eksperimenata na bazama podataka.
Prva serija - mijenjamo max_wal_size. I radimo veliku operaciju. Prvo, to radimo na zadanoj postavci od 1 gigabajta. I radimo masovno BRISANJE mnogo milijuna redaka.
Vidite kako nam je teško. Vidimo da je disk IO vrlo loš. Gledamo koliko smo WAL-ova generirali jer je to vrlo važno. Da vidimo koliko se puta dogodila kontrolna točka. A vidimo da nije dobro.
Zatim povećavamo max_wal_size. ponavljamo. Povećavamo, ponavljamo. I toliko puta. U principu, 10 bodova je dobro, gdje je 1, 2, 4, 8 gigabajta. I gledamo ponašanje određenog sustava. Jasno je da bi ovdje oprema trebala biti kao na prod. Morate imati iste diskove, istu količinu memorije i iste Postgres postavke.
I na taj način ćemo razmijeniti naš sustav, a znamo kako će se DBMS ponašati u slučaju lošeg masovnog DELETE-a, kako će kontrolno pokazivati.
Kontrolna točka na ruskom su kontrolne točke.
Primjer: DELETE nekoliko milijuna redaka po indeksu, redovi su "razbacani" po stranicama.
Evo primjera. Ovo je neka baza. A sa zadanom postavkom od 1 gigabajta za max_wal_size, vrlo je jasno da naši diskovi idu na policu za snimanje. Ova slika je tipičan simptom jako bolesnog pacijenta, odnosno on se stvarno loše osjećao. I bila je jedna jedina operacija, bilo je samo DELETE nekoliko milijuna redaka.
Ako je takva operacija dozvoljena u produ, onda ćemo samo ležati, jer jasno je da nas jedan DELETE ubija u policu.
Dalje, gdje je 16 gigabajta, jasno je da su zubi već otišli. Zubi su već bolji, odnosno kucamo u plafon, ali nije tako loše. Bilo je tu neke slobode. Desno je zapis. I broj operacija - drugi grafikon. I jasno je da već malo lakše dišemo kada je 16 gigabajta.
A gdje se vidi 64 gigabajta da je postao skroz bolji. Već su zubi izraženi, ima više mogućnosti preživjeti druge operacije i učiniti nešto s diskom.
Zašto je to?
Malo ću zaroniti u detalje, ali ova tema, kako provesti podešavanje kontrolnih točaka, može rezultirati cijelim izvješćem, tako da neću puno učitati, ali ću malo ocrtati koje poteškoće postoje.
Ako se kontrolna točka događa prečesto, a naše retke ne ažuriramo sekvencijalno, već pronalazimo po indeksu, što je dobro, jer ne brišemo cijelu tablicu, tada se može dogoditi da smo prvo dotakli prvu stranicu, zatim tisućitu, a zatim se vratio na prvi . A ako je između ovih posjeta prvoj stranici checkpoint to već spremio na disk, onda će ga opet spremiti, jer smo ga drugi put zaprljali.
I prisilit ćemo kontrolnu točku da je spasi mnogo puta. Kako bi mu bile suvišne operacije.
Ali to nije sve. Stranice imaju 8 kilobajta u Postgresu i 4 kilobajta u Linuxu. Tu je i postavka full_page_writes. Omogućeno je prema zadanim postavkama. I to je točno, jer ako ga isključimo, onda postoji opasnost da će se spasiti samo pola stranice ako se sruši.
Ponašanje pisanja u WAL dnevnika prosljeđivanja je takvo da kada imamo kontrolnu točku i promijenimo stranicu prvi put, cijela stranica, tj. svih 8 kilobajta, ulazi u dnevnik prosljeđivanja, iako smo promijenili samo linija, koja teži 100 bajtova. I moramo zapisati cijelu stranicu.
U sljedećim izmjenama bit će samo određena torka, ali po prvi put zapisujemo sve.
I, shodno tome, ako se opet dogodila kontrolna točka, onda moramo opet sve ispočetka i gurati cijelu stranicu. S čestim kontrolnim točkama, kada prolazimo kroz iste stranice, full_page_writes = on bit će više nego što bi moglo biti, tj. generiramo više WAL-a. Više se šalje u replike, u arhivu, na disk.
I, sukladno tome, imamo dva viška radnika.
Ako povećamo max_wal_size, ispada da olakšavamo i kontrolnu točku i wal pisca. I to je super.
Stavimo terabajt i živimo s njim. Što je tu loše? To je loše, jer u slučaju neuspjeha penjati ćemo se satima, jer je kontrolna točka bila davno i puno se toga već promijenilo. I moramo sve ovo PONOVITI. I tako radimo drugu seriju eksperimenata.
Izvodimo operaciju i vidimo kada će kontrolna točka završiti, namjerno ubijamo -9 Postgresa.
I nakon toga ga ponovo pokrećemo, i vidimo koliko će se dizati na ovoj opremi, tj. koliko će PONOVITI u ovoj lošoj situaciji.
Dvaput ću primijetiti da je stanje loše. Prvo, srušili smo se neposredno prije završetka kontrolne točke, tako da imamo puno za izgubiti. I drugo, imali smo veliku operaciju. A ako su kontrolne točke bile na vremenskom ograničenju, tada bi se najvjerojatnije generiralo manje WAL-a od zadnje kontrolne točke. Odnosno, dvostruki je gubitnik.
Mjerimo takvu situaciju za različite veličine max_wal_size i razumijemo da ako je max_wal_size 64 gigabajta, tada ćemo se u dvostrukom najgorem slučaju penjati 10 minuta. I razmišljamo da li nam to odgovara ili ne. Ovo je poslovno pitanje. Ovu sliku trebamo pokazati onima koji su odgovorni za poslovne odluke i pitati se: „Koliko možemo najviše ležati u slučaju problema? Možemo li u najgoroj situaciji leći 3-5 minuta? I doneseš odluku.
I ovdje je zanimljiva točka. Imamo nekoliko izvještaja o Patroniju na konferenciji. A možda ga i koristite. Ovo je autofailover za Postgres. GitLab i Data Egret razgovarali su o tome.
A ako imate autofailover koji dolazi za 30 sekundi, onda možda možemo leći 10 minuta? Zato što ćemo do ovog trenutka prijeći na repliku i sve će biti u redu. Ovo je sporna točka. Ne znam jasan odgovor. Osjećam da ova tema nije samo oporavak od sudara.
Ako imamo dug oporavak nakon neuspjeha, tada će nam biti neugodno u mnogim drugim situacijama. Na primjer, u istim eksperimentima, kada nešto radimo i ponekad moramo čekati 10 minuta.
I dalje ne bih išao predaleko, čak i ako imamo autofailover. U pravilu, vrijednosti kao što su 64, 100 gigabajta su dobre vrijednosti. Ponekad se čak isplati izabrati manje. Općenito, ovo je suptilna znanost.
Za izvođenje iteracija, na primjer, max_wal_size =1, 8, trebate ponoviti masovnu operaciju mnogo puta. Uspio si. I na istoj bazi želite to ponoviti, ali ste već sve izbrisali. Što uraditi?
Kasnije ću govoriti o našem rješenju, o tome što radimo da bismo ponovili u takvim situacijama. I ovo je najispravniji pristup.
Ali u ovom slučaju smo imali sreće. Ako, kao što ovdje piše "POČNI, IZBRIŠI, VRATI NA VRATI", tada možemo ponoviti DELETE. Odnosno, ako smo sami otkazali, onda možemo ponoviti. I fizički kod vas podaci će ležati na istom mjestu. Nemaš čak ni nadutost. Možete iterirati preko takvih DELETE-ova.
Ovaj DELETE s ROLLBACK idealan je za podešavanje kontrolnih točaka, čak i ako nemate pravilno raspoređene laboratorije baze podataka.
Napravili smo ploču s jednim stupcem "i". Postgres ima pomoćne stupce. Nevidljivi su osim ako se to posebno ne zatraži. To su: ctid, xmid, xmax.
Ctid je fizička adresa. Nulta stranica, prva torka na stranici.
Vidi se da je nakon ROOLBACK-a tuple ostao na istom mjestu. Odnosno, možemo pokušati ponovno, ponašat će se na isti način. Ovo je glavna stvar.
Xmax je vrijeme smrti torke. Označeno je, ali Postgres zna da je transakcija vraćena, tako da nije važno je li 0 ili je vraćena transakcija. Ovo sugerira da je moguće iterirati preko DELETE i provjeriti skupne operacije ponašanja sustava. Možete napraviti laboratorije za baze podataka za siromašne.
Ovdje se radi o programerima. Što se tiče DBA, također uvijek grde programere zbog ovoga: "Zašto radite tako duge i teške operacije?". Ovo je sasvim druga okomita tema. Nekad je bila administracija, a sada će biti razvoja.
Očito, nismo se raspali na komade. To je jasno. Nemoguće je ne razbiti takav DELETE za hrpu milijuna redaka na dijelove. Radit će se 20 minuta, i sve će leći. Ali, nažalost, čak i iskusni programeri griješe, čak iu vrlo velikim tvrtkama.
Zašto je važno prekinuti?
-
Ako vidimo da je disk tvrd, onda ga usporimo. A ako smo slomljeni, onda možemo dodati pauze, možemo usporiti prigušivanje.
-
I nećemo još dugo blokirati druge. U nekim slučajevima nije bitno, ako brišete pravo smeće na kojem nitko ne radi, onda najvjerojatnije nećete nikoga blokirati osim rada autovacuum-a, jer će čekati da se transakcija završi. Ali ako uklonite nešto što netko drugi može zatražiti, onda će biti blokiran, bit će nekakva lančana reakcija. Duge transakcije treba izbjegavati na web stranicama i mobilnim aplikacijama.
Ovo je zanimljivo. Često vidim da programeri pitaju: "Koju veličinu pakiranja trebam odabrati?".
Jasno je da što je veća veličina paketa, to su manji troškovi transakcije, tj. dodatni troškovi transakcija. Ali u isto vrijeme, vrijeme se povećava za ovu transakciju.
Imam vrlo jednostavno pravilo: uzmite što više možete, ali nemojte prelaziti s izvršnim datotekama u sekundi.
Zašto sekundu? Objašnjenje je vrlo jednostavno i razumljivo svima, čak i netehničarima. Vidimo reakciju. Uzmimo 50 milisekundi. Ako se nešto promijenilo, tada će naše oko reagirati. Ako manje, onda teže. Ako nešto odgovori nakon 100 milisekundi, npr. kliknuli ste mišem, a on vam odgovori nakon 100 milisekundi, već osjetite to malo kašnjenje. Sekunda se već doživljava kao kočnica.
Sukladno tome, ako naše masovne operacije razbijemo u nizove od 10 sekundi, tada postoji rizik da ćemo nekoga blokirati. I djelovat će nekoliko sekundi, a ljudi će to već primijetiti. Stoga radije ne radim više od sekunde. Ali u isto vrijeme, nemojte ga usitniti jer će troškovi transakcije biti vidljivi. Podloga će biti tvrđa i mogu se pojaviti različiti problemi.
Mi biramo veličinu pakiranja. U svakom slučaju, možemo to učiniti drugačije. Može se automatizirati. I mi smo uvjereni u učinkovitost obrade jednog pakiranja. Odnosno, radimo DELETE jednog paketa ili UPDATE.
Inače, sve o čemu govorim nije samo DELETE. Kao što ste pogodili, ovo su sve skupne operacije na podacima.
I vidimo da je plan odličan. Možete vidjeti skeniranje indeksa, skeniranje samo indeksa je još bolje. I imamo malu količinu uključenih podataka. I manje od sekunde ispunjava. Super.
I dalje se moramo pobrinuti da ne dođe do degradacije. Dešava se da prva pakovanja brzo prođu, a onda bude sve gore, gore i gore. Proces je takav da treba puno testirati. Upravo tome služe laboratoriji baze podataka.
I još uvijek moramo pripremiti nešto tako da će nam omogućiti da to ispravno pratimo u proizvodnji. Na primjer, možemo napisati vrijeme u dnevnik, možemo napisati gdje smo sada i koga smo sada izbrisali. A to će nam omogućiti da kasnije shvatimo što se događa. A u slučaju da nešto pođe po zlu, brzo pronađite problem.
Ako trebamo provjeriti učinkovitost zahtjeva i trebamo ponavljati mnogo puta, onda postoji takva stvar kao kolega bot. Već je spreman. Dnevno ga koriste deseci programera. I zna kako dati ogromnu terabajtnu bazu podataka na zahtjev u 30 sekundi, vlastitu kopiju. I tu možete nešto izbrisati i reći RESET, pa opet izbrisati. Možete eksperimentirati s tim na ovaj način. Vidim budućnost za ovu stvar. I mi to već radimo.
Što su strategije podjele? Vidim 3 različite strategije particioniranja koje programeri na paketu koriste.
Prvi je vrlo jednostavan. Imamo numerički ID. Podijelimo to na različite intervale i poradimo na tome. Loša strana je jasna. U prvom segmentu možemo imati 100 redaka pravog smeća, u drugom 5 redaka ili uopće ne, ili će svih 1 redaka ispasti smeće. Vrlo neravnomjeran rad, ali se lako slomi. Uzeli su maksimalnu iskaznicu i razbili je. Ovo je naivan pristup.
Druga strategija je uravnotežen pristup. Koristi se u Gitlabu. Uzeli su i skenirali stol. Pronašli smo granice ID paketa tako da je svaki paket imao točno 10 zapisa. I stavite ih u red. I onda obrađujemo. To možete učiniti u više niti.
Usput, iu prvoj strategiji to možete učiniti u nekoliko niti. Nije teško.
Ali postoji hladniji i bolji pristup. Ovo je treća strategija. A kad je moguće, bolje je izabrati to. To radimo na temelju posebnog indeksa. U ovom slučaju, to će najvjerojatnije biti indeks prema našem stanju otpada i ID-u. Uključit ćemo ID tako da bude samo skeniranje indeksa tako da ne idemo na hrpu.
Općenito, skeniranje samo indeksa je brže od skeniranja indeksa.
I brzo pronalazimo svoje ID-ove koje želimo ukloniti. BATCH_SIZE odabiremo unaprijed. I ne samo da ih dobivamo, mi ih dobivamo na poseban način i odmah hakiramo. Ali zaključavamo tako da ako su već zaključane, ne zaključavamo ih, nego idemo dalje i uzimamo sljedeće. Ovo je za zaključano preskakanje ažuriranja. Ova super značajka Postgresa omogućuje nam rad u nekoliko niti ako želimo. Moguće je u jednom toku. I ovdje postoji CTE - ovo je jedan zahtjev. I imamo stvarno brisanje u tijeku na drugom katu ovog CTE-a - returning *. Možete vratiti ID, ali to je bolje *ako nemate puno podataka o svakoj liniji.
Zašto nam to treba? To je ono što moramo izvijestiti. Izbrisali smo zapravo toliko redaka. I imamo granice prema ID-u ili prema created_at ovako. Možete napraviti min, max. Može se još nešto učiniti. Ovdje možete svašta natrpati. I vrlo je zgodan za praćenje.
Ima još jedna napomena o indeksu. Ako odlučimo da nam je potreban poseban indeks za ovaj zadatak, tada moramo biti sigurni da ne kvari ažuriranja gomile samo tuplesa. Odnosno, Postgres ima takvu statistiku. Ovo se može vidjeti u pg_stat_user_tables za vašu tablicu. Možete vidjeti koriste li se vruća ažuriranja ili ne.
Postoje situacije kada ih vaš novi indeks može jednostavno odrezati. I imate sva ostala ažuriranja koja već rade, usporite. Ne samo zato što se pojavio indeks (svaki indeks malo, ali malo usporava ažuriranja), ali ovdje ga još uvijek uništava. I nemoguće je napraviti posebnu optimizaciju za ovu tablicu. To se ponekad događa. Ovo je takva suptilnost koje se malo ljudi sjeća. A na ove grablje je lako stati. Ponekad se dogodi da trebate pronaći pristup s druge strane i dalje bez ovog novog indeksa, ili napraviti drugi indeks, ili na neki drugi način, na primjer, možete koristiti drugu metodu.
Ali ovo je najoptimalnija strategija, kako se podijeliti u serije i pucati u serije jednim zahtjevom, brisati malo itd.
Duge transakcije
Blokiran autovakuum -
problem blokiranja -
Pogreška broj 5 je velika. Nikolai iz Okmetera govorio je o Postgres monitoringu. Idealan Postgres nadzor, nažalost, ne postoji. Neki su bliže, neki dalje. Okmeter je dovoljno blizu savršenosti, ali puno toga nedostaje i treba dodati. Morate biti spremni na ovo.
Na primjer, mrtve torke najbolje je pratiti. Ako imate puno mrtvih stvari u tablici, onda nešto nije u redu. Bolje je odmah reagirati, inače može doći do degradacije, a mi možemo leći. Događa se.
Ako je veliki IO, onda je jasno da to nije dobro.
Duge transakcije također. Duge transakcije ne bi trebale biti dopuštene na OLTP-u. A ovdje je poveznica na isječak koji vam omogućuje da uzmete ovaj isječak i već pratite duge transakcije.
Zašto su duge transakcije loše? Jer će sve brave biti otpuštene tek na kraju. I zajebemo sve. Plus, blokiramo autovakuum za sve stolove. Uopće nije dobro. Čak i ako imate omogućeno vruće stanje pripravnosti na replici, i dalje je loše. Općenito, nigdje nije bolje izbjegavati duge transakcije.
Ako imamo mnogo stolova koji nisu usisani, onda moramo imati upozorenje. Ovdje je takva situacija moguća. Neizravno možemo utjecati na rad autovakuma. Ovo je isječak iz Avita, koji sam malo poboljšao. I pokazalo se da je to zanimljiv alat za vidjeti što imamo s autovakuumom. Na primjer, neki stolovi tamo čekaju i neće dočekati svoj red. Također ga morate staviti u nadzor i imati upozorenje.
I izdaje blokove. Šuma blokova drveća. Volim uzeti nešto od nekoga i poboljšati to. Ovdje sam uzeo cool rekurzivni CTE iz Data Egreta koji prikazuje šumu stabala brava. Ovo je dobar dijagnostički alat. I na njegovoj osnovi također možete izgraditi praćenje. Ali to se mora učiniti pažljivo. Morate napraviti mali statement_timeout za sebe. I lock_timeout je poželjan.
Ponekad se sve te pogreške pojavljuju zajedno.
Po meni je ovdje glavna greška organizacijska. Organizacijski je, jer tehnika ne vuče. Ovo je broj 2 - provjerili su na krivom mjestu.
Provjerili smo na krivom mjestu, jer nismo imali proizvodni klon, što je lako provjeriti. Razvojni programer možda uopće nema pristup produkciji.
I tamo nismo provjerili. Da smo tamo provjerili, vidjeli bismo i sami. Programer je sve to vidio i bez DBA ako je provjerio u dobrom okruženju, gdje postoji ista količina podataka i identična lokacija. Vidio bi svu tu degradaciju i bilo bi ga sram.
Više o autovakumu. Nakon što smo obavili masivno brisanje od nekoliko milijuna redaka, još uvijek trebamo napraviti REPAKIRANJE. Ovo je posebno važno za indekse. Osjećat će se loše nakon što tamo sve očistimo.
A ako želite vratiti svakodnevni posao čišćenja, predlažem da to radite češće, ali manje. To može biti jednom u minuti ili čak malo češće. I treba paziti na dvije stvari: da ta stvar nema greške i da ne zaostaje. Trik koji sam pokazao upravo će riješiti ovo.
Ono što mi radimo je open source. Objavljeno je na GitLabu. I činimo to tako da ljudi mogu provjeriti čak i bez DBA. Mi radimo bazu podataka lab, odnosno zovemo baznu komponentu na kojoj Joe trenutno radi. I možete zgrabiti kopiju proizvodnje. Sada postoji implementacija Joea za slack, tamo možete reći: "objasnite takav i takav zahtjev" i odmah dobijete rezultat za svoju kopiju baze podataka. Tamo možete čak i DELETE, i nitko to neće primijetiti.
Recimo da imate 10 terabajta, mi napravimo bazu podataka laboratorija također 10 terabajta. A s istodobnim bazama podataka od 10 terabajta, 10 programera može raditi istovremeno. Svatko može raditi što hoće. Može brisati, ispuštati, itd. To je takva fantazija. O ovome ćemo razgovarati sutra.
To se zove tanko osiguravanje. Ovo je suptilno opskrbljivanje. Ovo je neka vrsta fantazije koja uvelike uklanja kašnjenja u razvoju, u testiranju i čini svijet boljim mjestom u tom pogledu. To jest, samo vam omogućuje da izbjegnete probleme sa skupnim operacijama.
Primjer: baza podataka od 5 terabajta, dobivanje kopije za manje od 30 sekundi. I to čak ne ovisi o veličini, odnosno nije važno koliko terabajta.
Danas možete ići na i kopamo po našim alatima. Možete se registrirati da vidite što ima. Možete instalirati ovaj bot. Slobodno je. Pisati.
pitanja
Vrlo često se u stvarnim situacijama pokaže da je podataka koji bi trebali ostati u tablici puno manje od onih koje treba izbrisati. Odnosno, u takvoj situaciji često je lakše implementirati takav pristup, kada je lakše stvoriti novi objekt, tamo kopirati samo potrebne podatke i trunkirati staru tablicu. Jasno je da je za ovaj trenutak potreban programski pristup, dok ćete se vi mijenjati. Kakav je ovaj pristup?
Ovo je vrlo dobar pristup i vrlo dobar zadatak. Vrlo je slično onome što radi pg_repack, vrlo je slično onome što morate učiniti kada napravite ID od 4 bajta. Mnogi okviri su to učinili prije nekoliko godina, a ploče su narasle i potrebno ih je pretvoriti u 8 bajtova.
Ovaj zadatak je prilično težak. Uspjeli smo. I morate biti jako oprezni. Ima brava itd. Ali radi se. To jest, standardni pristup je koristiti pg_repack. Vi deklarirate takvu oznaku. I prije nego što počnete učitavati podatke o snimkama u nju, deklarirate i jednu ploču koja prati sve promjene. Postoji trik da neke promjene možda nećete ni pratiti. Postoje suptilnosti. I onda se prebacujete rolajući promjenama. Bit će kratka stanka kad sve ugasimo, ali općenito se to radi.
Ako pogledate pg_repack na GitHubu, tada je tamo, kada je postojao zadatak pretvoriti ID iz int 4 u int 8, tada je postojala ideja da se koristi sam pg_repack. Ovo je također moguće, ali to je pomalo hakirana metoda, ali će raditi i za ovo. Možete intervenirati u okidač koji pg_repack koristi i tamo reći: "Ne trebaju nam ovi podaci", tj. prenosimo samo ono što nam treba. I onda se samo prebaci i to je to.
Ovim pristupom još uvijek dobivamo drugu kopiju tablice u kojoj su podaci već indeksirani i složeni vrlo ravnomjerno s prekrasnim indeksima.
Nadutost nije prisutna, to je dobar pristup. Ali znam da se pokušava razviti automatizacija za to, tj. napraviti univerzalno rješenje. Mogu vas povezati s ovom automatizacijom. Napisano je u Pythonu, što je dobra stvar.
Ja sam samo malo iz svijeta MySQL-a, pa sam došao poslušati. I mi koristimo ovaj pristup.
Ali to je samo ako imamo 90%. Ako imamo 5%, onda to nije baš dobro koristiti.
Hvala na izvješću! Ako nema resursa za izradu potpune kopije proizvoda, postoji li neki algoritam ili formula za izračunavanje opterećenja ili veličine?
Dobro pitanje. Do sada smo u mogućnosti pronaći baze podataka od više terabajta. Čak i ako tamo hardver nije isti, npr. manje memorije, manje procesora i diskova nije potpuno isto, ali ipak mi to radimo. Ako nema apsolutno nigdje, onda morate razmisliti. Da razmislim do sutra, došao si, razgovarat ćemo, ovo je dobro pitanje.
Hvala na izvješću! Prvo ste počeli o tome da postoji cool Postgres, koji ima ta i ona ograničenja, ali se razvija. A ovo je sve uglavnom štaka. Nije li to sve u koliziji s razvojem samog Postgresa u kojem će se pojaviti neki DELETE deferent ili nešto drugo što bi trebalo držati na niskoj razini ono što mi ovdje pokušavamo zamazati nekim našim čudnim sredstvima?
Ako smo u SQL-u rekli da izbrišemo ili ažuriramo mnogo zapisa u jednoj transakciji, kako onda to Postgres može tamo distribuirati? Fizički smo ograničeni u radu. Još ćemo dugo to raditi. I mi ćemo zaključati u ovo vrijeme, itd.
Gotovo s indeksima.
Mogu pretpostaviti da bi se isto podešavanje kontrolne točke moglo automatizirati. Jednog dana bi moglo biti. Ali onda stvarno ne razumijem pitanje.
Pitanje je postoji li takav vektor razvoja koji ide tu i tamo, a ovdje vaš ide paralelno? Oni. Zar još nisu razmišljali o tome?
Govorio sam o principima koji se sada mogu koristiti. Postoji još jedan bot , s ovim možete napraviti automatizirano podešavanje kontrolne točke. Hoće li jednog dana biti u Postgresu? Ne znam, o tome se još nije ni razgovaralo. Još smo daleko od toga. Ali postoje znanstvenici koji stvaraju nove sustave. I guraju nas u automatske indekse. Ima razvoja događaja. Na primjer, možete pogledati automatsko podešavanje. Automatski odabire parametre. Ali on još neće raditi podešavanje kontrolnih točaka za vas. Odnosno, pokupit će se za performanse, međuspremnik ljuske itd.
A za podešavanje kontrolnih točaka možete učiniti ovo: ako imate tisuću klastera i različit hardver, različite virtualne strojeve u oblaku, možete koristiti našeg bota napraviti automatizaciju. A max_wal_size automatski će se odabrati prema vašim ciljnim postavkama. Ali to zasad nije ni blizu u srži, nažalost.
Dobar dan Govorili ste o opasnostima dugih transakcija. Rekli ste da se autovacuum blokira u slučaju brisanja. Kako nam inače šteti? Jer mi više govorimo o oslobađanju prostora i mogućnosti njegovog korištenja. Što nam još nedostaje?
Autovakuum možda nije najveći problem ovdje. A činjenica da duga transakcija može zaključati druge transakcije, ova je mogućnost opasnija. Ona se može i ne mora sresti. Ako se srela, onda može biti vrlo loše. A s autovakuumom - to je također problem. Postoje dva problema s dugim transakcijama u OLTP-u: zaključavanje i autovacuum. A ako na replici imate uključen hot standby feedback, onda ćete i dalje dobiti autovacuum lock na masteru, stići će iz replike. Ali barem neće biti brava. I bit će lokova. Govorimo o promjenama podataka, pa su brave ovdje važna točka. A ako je sve ovo dugo, dugo, onda je sve više i više transakcija zaključano. Oni mogu ukrasti druge. I pojavljuju se stabla lok. Dao sam poveznicu na isječak. I taj problem postaje uočljiviji brže od problema s autovakuumom koji se može samo nakupljati.
Hvala na izvješću! Započeli ste svoje izvješće rekavši da ste pogrešno testirali. Nastavili smo našu ideju da trebamo uzeti istu opremu, s bazom na isti način. Recimo da smo programeru dali bazu. I udovoljio je zahtjevu. I čini se da je dobro. Ali on ne provjerava za live, ali za live, na primjer, imamo opterećenje od 60-70%. Čak i ako koristimo ovo ugađanje, ne radi baš dobro.
Važno je imati stručnjaka u timu i koristiti DBA stručnjake koji mogu predvidjeti što će se dogoditi sa stvarnim pozadinskim opterećenjem. Kad smo samo proveli naše čiste promjene, vidimo sliku. Ali napredniji pristup, kada smo ponovno napravili istu stvar, ali s opterećenjem simuliranim s proizvodnjom. Prilično je cool. Do tada moraš odrasti. To je kao odrasla osoba. Samo smo gledali što imamo i također smo gledali imamo li dovoljno sredstava. To je dobro pitanje.
Kad već radimo garbage select i imamo npr. deleted flag
To je ono što autovacuum radi automatski u Postgresu.
Oh, radi li on to?
Autovakuum je sakupljač smeća.
Hvala vam!
Hvala na izvješću! Postoji li opcija da se odmah napravi baza podataka s particioniranjem na način da se svo smeće prlja iz glavne tablice negdje sa strane?
Naravno da jesu.
Možemo li se onda zaštititi ako smo zaključali stol koji se ne smije koristiti?
Naravno da jesu. Ali to je kao pitanje o kokoši i jajetu. Ako svi znamo što će se dogoditi u budućnosti, onda ćemo, naravno, sve učiniti cool. Ali posao se mijenja, nove su rubrike, novi zahtjevi. A onda – ups, želimo ga ukloniti. Ali ova idealna situacija se u životu događa, ali ne uvijek. Ali općenito je to dobra ideja. Samo skrati i to je to.
Izvor: www.habr.com