Negdje u dalekoj budućnosti, automatsko uklanjanje nepotrebnih podataka bit će jedan od važnih zadataka DBMS-a [1]. U međuvremenu, sami moramo da se pobrinemo za brisanje ili premeštanje nepotrebnih podataka u jeftinije sisteme za skladištenje podataka. Recimo da ste odlučili da obrišete nekoliko miliona redova. Prilično jednostavan zadatak, pogotovo ako je uvjet poznat i postoji odgovarajući indeks. "DELETE FROM table1 WHERE col1 = :value" - šta može biti jednostavnije, zar ne?
Video:
-
U programskom komitetu Highload sam od prve godine, odnosno od 2007. godine.
-
A u Postgresu sam od 2005. Koristio ga u mnogim projektima.
-
Grupirajte sa RuPostges takođe od 2007.
-
Narasli smo na 2100+ učesnika na Meetup-u. Drugi je u svijetu nakon New Yorka, dugo ga je pretekao San Francisco.
-
Živim u Kaliforniji nekoliko godina. Više se bavim američkim kompanijama, uključujući i velike. Oni su aktivni korisnici Postgresa. I ima svakakvih zanimljivih stvari.
je moja kompanija. Bavimo se automatizacijom zadataka koji eliminišu usporavanje razvoja.
Ako nešto radite, ponekad postoje nekakvi utikači oko Postgresa. Recimo da trebate pričekati da administrator postavi testno postolje za vas, ili trebate čekati da vam DBA odgovori. A takva uska grla nalazimo u procesu razvoja, testiranja i administracije i pokušavamo ih otkloniti uz pomoć automatizacije i novih pristupa.
Nedavno sam bio u VLDB-u u Los Angelesu. Ovo je najveća konferencija o bazama podataka. I postojao je izvještaj da će u budućnosti DBMS ne 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 njih je sve više.
I šta s tim? Očigledno je potrebno ukloniti. Evo linka do ovog zanimljivog izvještaja. Ali do sada to nije implementirano u DBMS.
Oni koji umeju da broje novac žele dve stvari. Oni žele da ih izbrišemo, pa bi tehnički trebali biti u mogućnosti to učiniti.
Ono što ću dalje ispričati je neka apstraktna situacija koja uključuje gomilu stvarnih situacija, odnosno neku vrstu kompilacije onoga što se meni i okolnim bazama podataka dogodilo mnogo puta, mnogo godina. Grablje su posvuda i svi stalno gaze na njih.
Recimo da imamo bazu ili nekoliko baza koje rastu. A neki zapisi su očigledno smeće. Na primjer, korisnik je tamo počeo nešto raditi, ali to nije završio. I nakon nekog vremena znamo da se ovo nedovršeno više ne može čuvati. Odnosno, željeli bismo očistiti neke stvari od smeća kako bismo uštedjeli prostor, poboljšali performanse itd.
Općenito, zadatak je automatizirati brisanje određenih stvari, određenih linija u nekoj tabeli.
I mi imamo takav zahtjev, o kojem ćemo danas govoriti, odnosno o odvozu smeća.
Zamolili smo iskusnog programera da to uradi. Uzeo je ovaj zahtjev, provjerio sam - sve radi. Testirano na inscenaciji - sve je u redu. Razvaljen - sve radi. Jednom dnevno ga pokrećemo - sve je u redu.
Baza podataka raste i raste. Dnevni DELETE počinje raditi malo sporije.
Onda shvatimo da sada imamo marketinšku kompaniju i da će promet biti nekoliko puta veći, pa odlučujemo da privremeno pauziramo nepotrebne stvari. I zaboravi da se vratiš.
Nekoliko mjeseci kasnije sjetili su se. I taj programer je dao otkaz ili je zauzet nečim drugim, dao instrukcije drugom da to vrati.
Provjerio je dev, staging - sve je OK. Naravno, još uvijek morate očistiti ono što se nakupilo. Provjerio je da sve radi.
Šta se dalje događa? Tada nam se sve raspada. Pada tako da u nekom trenutku sve padne. Svi su u šoku, niko ne razume šta se dešava. I onda se ispostavi da je stvar bila u ovom DELETE.
Nešto je pošlo po zlu? Evo liste onoga što je moglo poći po zlu. Šta je od ovoga najvažnije?
-
Na primjer, nije bilo pregleda, tj. DBA stručnjak ga nije pogledao. Iskusnim okom bi odmah pronašao problem, a osim toga, ima pristup prod, gdje se nakupilo nekoliko miliona redova.
-
Možda su nešto pogrešno provjerili.
-
Možda je hardver zastario i morate nadograditi ovu bazu.
-
Ili nešto nije u redu sa samom bazom podataka i moramo da pređemo sa Postgresa na MySQL.
-
Ili možda nešto nije u redu sa operacijom.
-
Možda ima grešaka u organizaciji posla i treba nekoga otpustiti i zaposliti najbolje ljude?
Nije bilo DBA provjere. Da postoji DBA, vidio bi ovih nekoliko miliona redova i čak bez ikakvih eksperimenata rekao bi: "Oni to ne rade." Pretpostavimo da je ovaj kod u GitLab-u, GitHubu i da bi postojao proces pregleda koda i da ne postoji takva stvar da bi se ova operacija bez odobrenja DBA-a odvijala na prod-u, onda bi očigledno DBA rekao: “Ovo se ne može učiniti .”
I on bi rekao da ćete imati problema sa IO diskom i svi procesi će poludeti, može doći do zaključavanja, a takođe ćete blokirati autovacuum na hrpu minuta, tako da ovo nije dobro.
Druga greška - provjerili su na pogrešnom mjestu. Videli smo nakon činjenice da se na prod akumulira mnogo neželjenih podataka, ali programer nije imao akumulirane podatke u ovoj bazi podataka, i niko nije kreirao ovo smeće tokom postavljanja. U skladu s tim, bilo je 1 linija koje su brzo funkcionirale.
Razumijemo da su naši testovi slabi, odnosno da proces koji je izgrađen ne hvata probleme. Adekvatan DB eksperiment nije izveden.
Idealan eksperiment poželjno je izvesti 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 YouTube-u.
Možda nam je oprema loša? Ako pogledate, onda je latencija skočila. Vidjeli smo da je iskorištenost 100%. Naravno, da su ovo moderni NVMe diskovi, onda bi nam vjerovatno bilo mnogo lakše. A možda i ne bismo legli od toga.
Ako imate oblake, onda se nadogradnja lako obavlja tamo. Podignute nove replike na novom hardveru. zamijeniti. I sve je u redu. Prilično lako.
Da li je moguće nekako dodirnuti manje diskove? I ovdje, samo uz pomoć DBA, ulazimo u određenu temu koja se zove podešavanje kontrolne tačke. Ispostavilo se da nismo imali podešavanje kontrolne tačke.
Šta je kontrolni punkt? Ima ga 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 upisuju u dnevnik upisivanja unaprijed. I u nekom trenutku, DBMS odlučuje da je vrijeme da se prave stranice izbace na disk, tako da ako dođe do kvara, možemo učiniti manje REDO. To je kao igračka. Ako poginemo, igru počinjemo sa zadnje kontrolne tačke. I svi DBMS to implementiraju.
Postavke u Postgresu zaostaju. Dizajnirani su za količine podataka i transakcija stare 10-15 godina. I kontrolni punkt nije izuzetak.
Evo informacija iz našeg Postgres izvještaja o kontroli, odnosno automatske provjere zdravlja. A evo i neke baze podataka od nekoliko terabajta. I dobro se vidi da su prisilni punktovi u skoro 90% slučajeva.
Šta to znači? Postoje dvije postavke. Kontrolna tačka može doći nakon isteka, na primjer, za 10 minuta. Ili može doći kada se popuni dosta podataka.
I prema zadanim postavkama max_wal_saze je postavljen na 1 gigabajt. U stvari, ovo se zaista dešava u Postgresu nakon 300-400 megabajta. Promijenili ste toliko podataka i vaša kontrolna tačka se dogodila.
A ako ga niko nije podesio, a usluga je rasla, a kompanija zarađuje mnogo novca, ima mnogo transakcija, onda kontrolni punkt dolazi jednom u minuti, ponekad svakih 30 sekundi, a ponekad se čak i preklapa. Ovo je prilično loše.
I moramo se pobrinuti da dolazi rjeđe. To jest, možemo podići 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 osnovu konkretnih podataka.
Shodno tome, radimo dvije serije eksperimenata na bazama podataka.
Prva serija - mijenjamo max_wal_size. I radimo ogromnu operaciju. Prvo, to radimo na zadanoj postavci od 1 gigabajta. I radimo masivno DELETE od mnogo miliona redova.
Vidite koliko nam je teško. Vidimo da je IO diska veoma loš. Gledamo koliko smo WAL-ova generirali, jer je to vrlo važno. Da vidimo koliko se puta desio kontrolni punkt. I vidimo da to nije dobro.
Zatim povećavamo max_wal_size. Ponavljamo. Povećavamo, ponavljamo. I toliko puta. U principu, 10 bodova je dobro, gdje 1, 2, 4, 8 gigabajta. I posmatramo ponašanje određenog sistema. 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š sistem, a znamo kako će se DBMS ponašati u slučaju lošeg masovnog DELETE-a, kako će provjeriti.
Kontrolni punkt na ruskom su kontrolni punktovi.
Primjer: IZBRIŠI nekoliko miliona redova po indeksu, redovi su "razbacani" po stranicama.
Evo primjera. Ovo je neka baza. A sa podrazumevanom 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 zaista se loše osjećao. I postojala je jedna jedina operacija, bilo je samo DELETE od nekoliko miliona redova.
Ako je takva operacija dozvoljena u prod, onda ćemo samo leći, jer je jasno da nas jedan DELETE ubija u puku.
Dalje, gdje je 16 gigabajta, jasno je da su zubi već otišli. Zubi su već bolji, odnosno kucamo u plafon, ali ne tako loše. Tamo je bilo neke slobode. Na desnoj strani je zapisnik. I broj operacija - drugi grafikon. I jasno je da već malo lakše dišemo kada 16 gigabajta.
I gdje se vidi 64 gigabajta da je postao potpuno bolji. Zubi su već izraženi, ima više mogućnosti da preživite druge operacije i uradite nešto sa diskom.
Zašto je to tako?
Malo ću uroniti u detalje, ali ova tema, kako provesti podešavanje kontrolne tačke, može rezultirati cijelim izvještajem, tako da neću puno učitavati, ali ću malo opisati koje poteškoće postoje.
Ako se kontrolna tačka dešava prečesto, a mi ažuriramo naše redove ne sekvencijalno, već pronalazimo po indeksu, što je dobro, jer ne brišemo celu tabelu, onda se može desiti da smo prvo dodirnuli prvu stranicu, pa hiljaditu, a zatim se vratio na prvu. I ako je između ovih posjeta prvoj stranici kontrolna tačka već snimila na disk, onda će je ponovo sačuvati, jer smo je zaprljali drugi put.
I prisilićemo kontrolni punkt da ga sačuva mnogo puta. Kako bi za njega bilo suvišnih operacija.
Ali to nije sve. Stranice su 8 kilobajta u Postgresu i 4 kilobajta u Linuxu. I postoji postavka full_page_writes. Podrazumevano je omogućeno. I to je tačno, jer ako ga isključimo, postoji opasnost da će samo polovina stranice biti sačuvana ako se sruši.
Ponašanje pisanja u WAL prosljeđenog dnevnika je takvo da kada imamo kontrolnu tačku i promijenimo stranicu po prvi put, cijela stranica, odnosno svih 8 kilobajta, ulazi u prosljeđivanje dnevnika, iako smo promijenili samo liniju, koja teži 100 bajtova. I moramo da zapišemo celu stranicu.
U narednim promjenama, postojat će samo određeni tuple, ali po prvi put zapisujemo sve.
I, shodno tome, ako se kontrolni punkt ponovo dogodi, onda moramo sve početi iznova i gurnuti cijelu stranicu. Uz česte kontrolne tačke, kada prolazimo kroz iste stranice, full_page_writes = on će biti više nego što bi moglo biti, tj. generišemo više WAL-a. Više se šalje u replike, u arhivu, na disk.
I, shodno tome, imamo dva viška.
Ako povećamo max_wal_size, ispada da olakšavamo i kontrolnu tačku i wal pisača. I to je super.
Hajde da stavimo jedan terabajt i živimo s njim. Šta je loše u tome? Ovo je loše, jer ćemo se u slučaju kvara penjati satima, jer je kontrolni punkt bio davno i mnogo se toga već promijenilo. I treba da uradimo sve ovo REDO. I tako radimo drugu seriju eksperimenata.
Izvodimo operaciju i vidimo kada će se kontrolni punkt završiti, namjerno ubijamo -9 Postgres.
I nakon toga ga ponovo pokrećemo, i vidimo koliko dugo će se dizati na ovoj opremi, odnosno koliko će se PONOVITI u ovoj lošoj situaciji.
Dva puta ću napomenuti da je situacija loša. Prvo, srušili smo se neposredno prije nego je kontrolni punkt završio, tako da imamo mnogo toga za izgubiti. I drugo, imali smo veliku operaciju. A da su kontrolne tačke na vremenskom ograničenju, tada bi se, najvjerovatnije, generiralo manje WAL-a od posljednje kontrolne tačke. To jest, to je dvostruki gubitnik.
Mjerimo takvu situaciju za različite max_wal_size veličine i razumijemo da ako je max_wal_size 64 gigabajta, onda ćemo se u dvostruko najgorem slučaju penjati 10 minuta. I razmišljamo da li nam to odgovara ili ne. Ovo je poslovno pitanje. Ovu sliku treba da pokažemo odgovornima za poslovne odluke i zapitamo se: „Koliko dugo možemo najviše ležati u slučaju problema? Možemo li u najgoroj situaciji ležati 3-5 minuta? I ti donosiš odluku.
I evo jedne zanimljive stvari. Imamo nekoliko izvještaja o Patroni na konferenciji. I možda ga koristite. Ovo je autofailover za Postgres. GitLab i Data Egret su razgovarali o tome.
A ako imate autofailover koji dolazi za 30 sekundi, onda možda možemo ležati 10 minuta? Jer ćemo do ovog trenutka preći na repliku i sve će biti u redu. Ovo je sporna stvar. Ne znam jasan odgovor. Samo osjećam da se ova tema ne odnosi samo na oporavak nakon rušenja.
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 da imamo autofailover. Po pravilu, vrijednosti poput 64, 100 gigabajta su dobre vrijednosti. Ponekad čak vrijedi odabrati manje. Generalno, ovo je suptilna nauka.
Da biste izvršili iteracije, na primjer, max_wal_size =1, 8, morate ponoviti masovnu operaciju mnogo puta. Uspeo si. I na istoj bazi želite to ponoviti, ali ste već sve izbrisali. sta da radim?
Kasnije ću govoriti o našem rješenju, šta radimo da bismo ponovili u takvim situacijama. I ovo je najispravniji pristup.
Ali u ovom slučaju, imali smo sreće. Ako, kao što ovde piše "POČNI, IZBRIŠI, ROLLBACK", onda možemo ponoviti DELETE. Odnosno, ako smo ga sami otkazali, onda to možemo ponoviti. I fizički kod vas podaci će ležati na istom mjestu. Čak se i ne nadimaš. Možete iterirati preko takvih DELETE-ova.
Ovo DELETE sa ROLLBACK je idealno za podešavanje kontrolne tačke, čak i ako nemate pravilno raspoređene laboratorije baze podataka.
Napravili smo ploču sa jednim stupcem "i". Postgres ima uslužne kolone. Oni su nevidljivi osim ako se to posebno ne traže. To su: ctid, xmid, xmax.
Ctid je fizička adresa. Nula stranica, prva tuple na stranici.
Može se vidjeti da je nakon ROOLBACK-a tuple ostao na istom mjestu. Odnosno, možemo pokušati ponovo, ponašać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 da li je 0 ili je transakcija vraćena. Ovo sugerira da je moguće ponoviti DELETE i provjeriti grupne operacije ponašanja sistema. Možete napraviti laboratorije 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. Nekada je postojala administracija, a sada će biti razvoja.
Očigledno, nismo se raspali na komade. To je jasno. Nemoguće je ne razbiti takav DELETE za gomilu miliona linija na dijelove. Radiće se 20 minuta i sve će leći. Ali, nažalost, čak i iskusni programeri griješe, čak iu vrlo velikim kompanijama.
Zašto je važno razbiti?
-
Ako vidimo da je disk tvrd, hajde da ga usporimo. A ako smo slomljeni, onda možemo dodati pauze, možemo usporiti prigušivanje.
-
I nećemo dugo blokirati druge. U nekim slučajevima nije važno, ako brišete pravo smeće na kojem niko ne radi, onda najvjerovatnije nećete nikoga blokirati osim rada autovakuma, jer će čekati da se transakcija završi. Ali ako uklonite nešto što neko drugi može zatražiti, onda će biti blokirani, doći će do neke vrste lančane reakcije. Duge transakcije treba izbjegavati na web stranicama i mobilnim aplikacijama.
Ovo je zanimljivo. Često vidim da se programeri pitaju: "Koju veličinu paketa da odaberem?".
Jasno je da što je veća veličina paketa, to su manji troškovi transakcije, odnosno dodatni troškovi iz transakcija. Ali u isto vrijeme, vrijeme za ovu transakciju se povećava.
Imam vrlo jednostavno pravilo: uzmite koliko god možete, ali nemojte prelaziti preko izvršnih datoteka 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, onda će naše oko reagovati. Ako manje, onda teže. Ako nešto odgovori nakon 100 milisekundi, na primjer, kliknuli ste mišem, a ono vam je odgovorilo nakon 100 milisekundi, već osjećate ovo malo kašnjenje. Sekunda se već percipira kao kočnica.
Shodno tome, ako svoje masovne operacije razbijemo na rafale od 10 sekundi, onda imamo rizik da ćemo nekoga blokirati. I to će raditi nekoliko sekundi, i ljudi će to već primijetiti. Stoga radije ne radim više od sekunde. Ali u isto vrijeme, nemojte ga vrlo fino razdvojiti, jer će troškovi transakcije biti primjetni. Baza će biti tvrđa, a mogu se pojaviti i drugi različiti problemi.
Odabiremo veličinu pakovanja. U svakom slučaju, možemo to učiniti drugačije. Može se automatizirati. I uvjereni smo u efikasnost obrade jednog pakovanja. Odnosno, radimo DELETE jednog paketa ili UPDATE.
Uzgred, sve o čemu pričam nije samo o DELETE. Kao što ste pretpostavili, ovo su sve masovne operacije nad podacima.
I vidimo da je plan odličan. Možete vidjeti skeniranje indeksa, skeniranje samo indeksa je još bolje. A mi imamo malu količinu podataka uključenih. I manje od sekunde ispunjava. Super.
I još uvijek moramo biti sigurni da nema degradacije. Dešava se da prvi paketi brzo prođu, a onda postaje sve gore, gore i gore. Proces je takav da morate mnogo testirati. Upravo za to služe laboratorije za baze podataka.
I još moramo nešto pripremiti kako bismo to mogli ispravno pratiti u proizvodnji. Na primjer, možemo upisati vrijeme u dnevnik, možemo napisati gdje smo sada i koga smo sada izbrisali. I to će nam omogućiti da kasnije shvatimo šta se dešava. A u slučaju da nešto krene po zlu, brzo pronađite problem.
Ako trebamo provjeriti efikasnost zahtjeva i trebamo ponoviti mnogo puta, onda postoji takva stvar kao kolega bot. On je već spreman. Koriste ga na desetine programera dnevno. I on zna kako dati ogromnu terabajtnu bazu podataka na zahtjev za 30 sekundi, vašu vlastitu kopiju. I možete obrisati nešto tamo i reći RESET, i ponovo izbrisati. S tim možete eksperimentirati na ovaj način. Vidim budućnost za ovu stvar. I mi to već radimo.
Koje su strategije particioniranja? Vidim 3 različite strategije particioniranja koje koriste programeri na paketu.
Prvi je vrlo jednostavan. Imamo brojčani ID. I hajde da ga razbijemo na različite intervale i poradimo na tome. Loša strana je jasna. U prvom segmentu možemo imati 100 redova pravog smeća, u drugom 5 redova ili uopšte nećemo, ili će svih 1 redova ispasti smeće. Vrlo neravnomjeran rad, ali ga je lako slomiti. Uzeli su maksimalnu legitimaciju i razbili je. Ovo je naivan pristup.
Druga strategija je uravnotežen pristup. Koristi se u Gitlabu. Uzeli su i pregledali sto. Pronašli smo granice ID paketa tako da svaki paket ima tačno 10 zapisa. I stavite ih u red. I onda obrađujemo. To možete učiniti u više niti.
I u prvoj strategiji, inače, to možete učiniti u nekoliko niti. Nije teško.
Ali postoji hladniji i bolji pristup. Ovo je treća strategija. A kada je moguće, bolje je izabrati to. To radimo na osnovu posebnog indeksa. U ovom slučaju, to će najvjerovatnije biti indeks prema našem stanju smeća i ID-u. Uključit ćemo ID tako da je skeniranje samo indeksa kako ne bismo išli na hrpu.
Općenito, skeniranje samo indeksa je brže od skeniranja indeksa.
I brzo pronađemo naše ID-ove koje želimo izbrisati. BATCH_SIZE biramo unaprijed. I ne samo da ih dobijemo, već ih dobijemo na poseban način i odmah ih hakujemo. Ali mi zaključavamo tako da ako su već zaključani, ne zaključavamo ih, nego idemo dalje i uzimamo sljedeće. Ovo je za zaključavanje preskakanja ažuriranja. Ova super karakteristika Postgresa nam omogućava da radimo u nekoliko niti ako želimo. Moguće je u jednom toku. I ovdje postoji CTE - ovo je jedan zahtjev. I imamo pravo brisanje na drugom spratu ovog CTE-a - returning *. Možete vratiti ID, ali je bolje *ako nemate mnogo podataka na svakoj liniji.
Zašto nam treba? To je ono o čemu treba da izvještavamo. Zapravo smo izbrisali toliko redova. I imamo granice po ID-u ili po created_at ovako. Možete raditi min, max. Nešto drugo se može uraditi. Ovdje možete puno stvari. I vrlo je zgodan za praćenje.
Postoji još jedna napomena o indeksu. Ako odlučimo da nam je potreban poseban indeks za ovaj zadatak, onda moramo biti sigurni da ne pokvari hrpu samo ažuriranja tuple. Odnosno, Postgres ima takvu statistiku. Ovo se može vidjeti u pg_stat_user_tables za vašu tabelu. Možete vidjeti da li se vruća ažuriranja koriste ili ne.
Postoje situacije kada ih vaš novi indeks može jednostavno prekinuti. I imate sva druga ažuriranja koja već rade, usporite. Ne samo zato što se indeks pojavio (svaki indeks malo usporava ažuriranje, ali malo), ali ovdje ga i dalje uništava. I nemoguće je napraviti posebnu optimizaciju za ovu tablicu. Ovo se ponekad dešava. Ovo je takva suptilnost koje se malo ljudi sjeća. A na ove grablje je lako zgaziti. Ponekad se desi da treba da nađete pristup sa druge strane i da ipak prođete bez ovog novog indeksa, ili napravite drugi indeks, ili na neki drugi način, na primer, možete koristiti drugu metodu.
Ali ovo je najoptimalnija strategija, kako se podijeliti u grupe i pucati u serije sa jednim zahtjevom, obrisati malo itd.
Duge transakcije
Blokiran autovakuum -
problem blokiranja -
Greška broj 5 je velika. Nikolaj iz Okmetra je govorio o Postgres monitoringu. Idealan Postgres monitoring, nažalost, ne postoji. Neki su bliže, neki dalje. Okmetar je dovoljno blizu savršenstva, ali dosta toga nedostaje i treba ga dodati. Morate biti spremni za ovo.
Na primjer, mrtve torke se najbolje prate. Ako imate puno mrtvih stvari u tabeli, onda nešto nije u redu. Bolje je odmah reagovati, inače može doći do degradacije i možemo ležati. Dešava se.
Ako postoji veliki IO, onda je jasno da to nije dobro.
I duge transakcije. Duge transakcije ne bi trebale biti dozvoljene na OLTP-u. A evo i linka na isječak koji vam omogućava da uzmete ovaj isječak i već obavite praćenje dugih transakcija.
Zašto su duge transakcije loše? Jer će sve brave biti otpuštene tek na kraju. I zajebamo sve. Osim toga, blokiramo autovacuum za sve stolove. Uopšte nije dobro. Čak i ako imate omogućen hot standby na replici, i dalje je loše. Općenito, nigdje nije bolje izbjegavati duge transakcije.
Ako imamo mnogo stolova koji nisu usisavani, onda moramo imati upozorenje. Ovdje je moguća takva situacija. Na rad autovakuma možemo indirektno uticati. Ovo je isječak iz Avita, koji sam malo poboljšao. I pokazalo se da je to zanimljiv alat da vidimo šta imamo sa autovakuumom. Na primjer, neki stolovi tamo čekaju i neće čekati svoj red. Također ga morate staviti u nadzor i imati upozorenje.
I izdaje blokove. Šuma drveća blokiranja. Volim uzeti nešto od nekoga i poboljšati to. Ovdje sam uzeo cool rekurzivni CTE iz Data Egret koji prikazuje šumu stabala brave. Ovo je dobar dijagnostički alat. A na osnovu toga možete izgraditi i monitoring. Ali to se mora raditi pažljivo. Morate napraviti mali statement_timeout za sebe. I lock_timeout je poželjno.
Ponekad se sve ove greške javljaju u zbroju.
Po mom mišljenju, glavna greška je organizaciona. Organizacijski je, jer tehnika ne vuče. Ovo je broj 2 - provjerili su na pogrešnom mjestu.
Provjerili smo na pogrešnom mjestu, jer nismo imali proizvodni klon koji je lako provjeriti. Programer možda uopće nema pristup proizvodnji.
A nismo tamo provjerili. Da smo tamo provjerili, i sami bismo vidjeli. Programer je sve to vidio i bez DBA ako je to provjerio u dobrom okruženju, gdje postoji ista količina podataka i identična lokacija. Video bi svu ovu degradaciju i bilo bi ga sramota.
Više o autovakumu. Nakon što smo obavili masivno pretraživanje od nekoliko miliona redova, još uvijek treba da uradimo REPACK. Ovo je posebno važno za indekse. Osjećat će se loše nakon što tamo sve očistimo.
A ako želite da vratite svakodnevni posao čišćenja, onda bih predložio da ga radite češće, ali manje. Može biti jednom u minuti ili čak i češće malo. I trebate pratiti dvije stvari: da ova stvar nema grešaka i da ne zaostaje. Trik koji sam pokazao samo će ovo riješiti.
Ono što radimo je open source. Objavljeno je na GitLabu. I mi to radimo tako da ljudi mogu provjeriti čak i bez DBA. Radimo laboratoriju baze podataka, odnosno pozivamo osnovnu komponentu na kojoj Joe trenutno radi. I možete uzeti kopiju proizvodnje. Sada postoji implementacija Joe za slack, tamo možete reći: „objasnite takav i takav zahtjev“ i odmah dobiti rezultat za svoju kopiju baze podataka. Možete čak i IZBRISATI tamo i niko to neće primijetiti.
Recimo da imate 10 terabajta, mi napravimo laboratoriju baze podataka takođe 10 terabajta. A sa istovremenim bazama podataka od 10 terabajta, 10 programera može raditi istovremeno. Svako može da radi šta hoće. Može obrisati, ispustiti, itd. To je takva fantazija. O tome ćemo razgovarati sutra.
Ovo se zove tanko obezbjeđivanje. Ovo je suptilno obezbjeđivanje. Ovo je neka vrsta fantazije koja uvelike otklanja kašnjenja u razvoju, testiranju i čini svijet boljim mjestom u tom pogledu. Odnosno, samo vam omogućava da izbjegnete probleme s masovnim operacijama.
Primjer: baza podataka od 5 terabajta, dobijanje kopije za manje od 30 sekundi. I to čak ne zavisi od veličine, odnosno nije važno koliko terabajta.
Danas možete otići i kopati po našim alatima. Možete se registrovati da vidite šta ima. Možete instalirati ovog bota. Slobodno je. Pisati.
Vaša pitanja
Vrlo često se u stvarnim situacijama ispostavi da je podataka koji treba da ostanu u tabeli mnogo manje od onoga što treba obrisati. Odnosno, u takvoj situaciji često je lakše implementirati takav pristup, kada je lakše kreirati novi objekat, kopirati tamo samo potrebne podatke i trunk staru tablicu. Jasno je da je za ovaj trenutak potreban programski pristup, dok ćete se prebacivati. Kakav je ovaj pristup?
Ovo je veoma dobar pristup i veoma dobar zadatak. Vrlo je slično onome što pg_repack radi, vrlo je slično onome što morate učiniti kada napravite ID-ove od 4 bajta. Mnogi okviri su to učinili prije nekoliko godina, a samo su ploče porasle i potrebno ih je konvertirati u 8 bajtova.
Ovaj zadatak je prilično težak. Uspjeli smo. I morate biti veoma oprezni. Ima brava itd. Ali to se radi. Odnosno, standardni pristup je ići sa pg_repackom. Vi deklarirate takvu oznaku. I prije nego što počnete učitavati podatke snimka u njega, također deklarirate jednu ploču koja prati sve promjene. Postoji trik da neke promjene možda nećete ni pratiti. Postoje suptilnosti. A onda se mijenjate pomicanjem izmjena. Biće kratka pauza kada sve ugasimo, ali generalno to se radi.
Ako pogledate pg_repack na GitHubu, onda, kada je postojao zadatak da se pretvori ID iz int 4 u int 8, postojala je ideja da se koristi sam pg_repack. Ovo je takođe moguće, ali je malo hak, ali će raditi i za ovo. Možete intervenirati u okidaču koji pg_repack koristi i tamo reći: "Ne trebaju nam ovi podaci", tj. prenosimo samo ono što nam je potrebno. A onda se samo prebaci i to je to.
Ovim pristupom i dalje dobijamo drugu kopiju tabele, u kojoj su podaci već indeksirani i veoma ravnomerno složeni sa prelepim indeksima.
Nadutost nije prisutna, to je dobar pristup. Ali znam da postoje pokušaji da se za to razvije automatizacija, odnosno da se napravi univerzalno rješenje. Mogu vas upoznati sa ovom automatizacijom. Napisano je na Pythonu, što je dobra stvar.
Ja sam samo malo iz svijeta MySQL-a, pa sam došao da slušam. I mi koristimo ovaj pristup.
Ali to je samo ako imamo 90%. Ako imamo 5%, onda to nije baš dobro koristiti.
Hvala na izvještaju! Ako nema resursa za izradu kompletne kopije prod-a, postoji li neki algoritam ili formula za izračunavanje opterećenja ili veličine?
Dobro pitanje. Do sada smo u mogućnosti da pronađemo baze podataka od više terabajta. Čak i ako hardver tamo nije isti, na primjer, manje memorije, manje procesora i diskovi nisu potpuno isti, ali ipak to radimo. Ako nema apsolutno nigde, onda treba razmisliti. Da razmislim do sutra, došli ste, razgovaraćemo, ovo je dobro pitanje.
Hvala na izvještaju! Prvo ste započeli sa činjenicom da postoji cool Postgres, koji ima takva i takva ograničenja, ali se razvija. A ovo je sve uglavnom štaka. Nije li to sve u suprotnosti sa razvojem samog Postgresa, u kojem će se pojaviti neki DELETE deferent ili nešto drugo što bi trebalo da drži na niskom nivou ono što pokušavamo da zaprljamo nekim našim čudnim sredstvima ovdje?
Ako smo u SQL-u rekli da obrišemo ili ažuriramo mnogo zapisa u jednoj transakciji, kako to onda Postgres može distribuirati tamo? Fizički smo ograničeni u operacijama. Još dugo ćemo to raditi. A mi ćemo zaključati u ovom trenutku, itd.
Gotovo sa indeksima.
Mogu pretpostaviti da bi isto podešavanje kontrolne tačke moglo biti automatizirano. Jednog dana bi moglo biti. Ali onda stvarno ne razumijem pitanje.
Pitanje je da li postoji takav vektor razvoja koji ide tu i tamo, a tu vaš ide paralelno? One. Zar još nisu razmišljali o tome?
Govorio sam o principima koji se sada mogu koristiti. Postoji još jedan bot , sa ovim možete izvršiti automatsko podešavanje kontrolne tačke. Hoće li to jednog dana biti u Postgresu? Ne znam, o tome se još nije ni razgovaralo. Još smo daleko od toga. Ali postoje naučnici koji prave nove sisteme. I gurnuli su nas u automatske indekse. Ima pomaka. Na primjer, možete pogledati automatsko podešavanje. Automatski bira parametre. Ali on još neće raditi podešavanje kontrolne tačke umjesto vas. Odnosno, pokupiće se za performanse, bafer ljuske, itd.
A za podešavanje kontrolne tačke, možete uraditi ovo: ako imate hiljadu klastera i različit hardver, različite virtuelne mašine u oblaku, možete koristiti našeg bota raditi automatizaciju. I max_wal_size će se automatski odabrati prema vašim ciljnim postavkama. Ali za sada to, nažalost, nije ni blizu u srži.
Dobar dan Govorili ste o opasnostima dugih transakcija. Rekli ste da je autovakuum blokiran u slučaju brisanja. Kako nam drugačije šteti? Jer mi više govorimo o oslobađanju prostora i mogućnosti da ga koristite. Šta nam još nedostaje?
Autovakuum ovdje možda nije najveći problem. A činjenica da duga transakcija može zaključati druge transakcije, ova mogućnost je opasnija. Ona se može sresti, a ne mora. Ako se upoznala, onda može biti jako loše. A kod autovakuma - i to je problem. Postoje dva problema s dugim transakcijama u OLTP-u: zaključavanje i autovacuum. A ako imate omogućenu povratnu informaciju o vrućem stanju pripravnosti na replici, tada ćete i dalje dobiti autovakuumsku bravu na masteru, ona će stići iz replike. Ali barem neće biti brava. I biće lokova. Govorimo o promjenama podataka, tako da su brave ovdje važna tačka. A ako je sve ovo dugo, dugo, onda je sve više transakcija zaključano. Oni mogu ukrasti druge. I pojavljuju se lok stabla. Dao sam link do isječka. I ovaj problem postaje uočljiviji brže od problema sa autovakuumom, koji se može samo akumulirati.
Hvala na izvještaju! Započeli ste svoj izvještaj rekavši da ste testirali pogrešno. Nastavili smo našu ideju da trebamo uzeti istu opremu, sa bazom na isti način. Recimo da smo programeru dali bazu. I on je udovoljio zahtjevu. I izgleda da je dobro. Ali on ne provjerava uživo, nego uživo, na primjer, imamo opterećenje od 60-70%. Čak i ako koristimo ovo podešavanje, 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 opterećenjem u pozadini. Kada smo upravo odvezli naše čiste promjene, vidimo sliku. Ali napredniji pristup, kada smo ponovo uradili istu stvar, ali sa opterećenjem simuliranim u proizvodnji. Prilično je kul. Do tada morate odrasti. To je kao odrasla osoba. Samo smo pogledali šta imamo i takođe smo pogledali da li imamo dovoljno resursa. To je dobro pitanje.
Kada već radimo odabir smeća i imamo, na primjer, izbrisanu zastavicu
To je ono što autovacuum radi automatski u Postgresu.
Oh, da li on to radi?
Autovacuum je sakupljač smeća.
Hvala vam!
Hvala na izvještaju! Postoji li opcija da se odmah dizajnira baza podataka sa particioniranjem na način da se svo smeće zaprlja iz glavne tablice negdje sa strane?
Naravno.
Da li je onda moguće da se zaštitimo ako smo zaključali sto koji ne treba koristiti?
Naravno. Ali to je kao pitanje kokoške i jaja. Ako svi znamo šta će se dogoditi u budućnosti, onda ćemo, naravno, učiniti sve kul. Ali posao se mijenja, postoje nove rubrike, novi zahtjevi. A onda – ups, želimo da ga uklonimo. Ali ova idealna situacija, u životu se dešava, ali ne uvek. Ali generalno, to je dobra ideja. Samo skratite i to je to.
izvor: www.habr.com