Përshëndetje.
MĂ« quajnĂ« Vanja, dhe jam zhvillues Java. MĂ« ka ndodhur tĂ« punoj shumĂ« me PostgreSQL â merrem me konfigurimin e databazĂ«s, optimizimin e strukturĂ«s, performancĂ«s dhe pak luaj si DBA gjatĂ« fundjavĂ«s.
Kohet e fundit kam organizuar disa baza të dhënash në shërbimet tona mikrosherbimesh dhe kam shkruar një libër java , i cili e lehtëson këtë punë, kursen kohën time dhe ndihmon në shmangien e disa gabimeve tipike nga zhvilluesit. Pikërisht për këtë libër do të flasim sot.
Shënim ligjor
Versioni kryesor i PostgreSQL me të cilin punoj është 10-ë. Të gjitha kërkesat SQL që përdor gjithashtu janë testuar në versionin 11. Versioni minimal i mbështetur është 9.6.
Pas historia
E gjitha filloi gati një vit më parë me një situatë të çuditshme për mua: krijimi kompetitiv i një indeksi në vend të papritur përfundoi me një gabim. Indeksi vetë, siç ndodh zakonisht, mbeti në një gjendje të pavlefshme në databazë. Analiza e logëve tregoi mungesë . Dhe pastaj filloi⊠Pasi hinqa thellë, zbulova një mori problemesh në konfigurimin e databazës dhe, duke rrotulluar mëngët, fillova t'i rregulloj me kujdes.
Problemi i parĂ« â konfigurimi default
Ndoshta metafora për Postgres, që mund të startohet në një kafetier, është mjaft e lodhshme për të gjithë, por... konfigurimi për default vërtet e ngre një sërë pyetjesh. Së paku, është e rëndësishme të theksohet maintenance_work_mem, temp_file_limit, statement_timeout dhe lock_timeout.
NĂ« rastin tonĂ« maintenance_work_mem ishte pĂ«r standard 64 MB, kurse temp_file_limit rreth 2 GB â na mungonte thjesht memoria pĂ«r tĂ« krijuar njĂ« indeks nĂ« njĂ« tabelĂ« tĂ« madhe.
Prandaj, në pg-index-health kam mbledhur një sërë , sipas mendimit tim, që duhet të konfigurohen për çdo DB.
Problemi i dytĂ« â indekset e pĂ«rsĂ«ritura
Baza jonë jeton në disqe SSD, dhe ne përdorim HA-konfigurimin me disa qendra të të dhënave, një host master dhe n-në numër të replikave. Hapësira në disk është një burim shumë i çmuar për ne; ajo është po aq e rëndësishme sa performanca dhe konsumimi i CPU. Prandaj, nga njëra anë, na duhen indekse për lexim të shpejtë, ndërsa nga ana tjetër, ne nuk duam të shohim indekse të tepërta në DB, pasi ato konsumojnë hapësirë dhe ngadalësojnë përditësimin e të dhënave.
Dhe kĂ«shtu, pasi fshimĂ« tĂ« gjitha dhe duke parĂ« , unĂ« vendosa tĂ« bĂ«j njĂ« "pastrim tĂ« madh". Doli se zhvilluesit nuk e pĂ«lqejnĂ« tĂ« lexojnĂ« dokumentacionin e bazĂ«s sĂ« tĂ« dhĂ«nave. ShumĂ« nuk e pĂ«lqejnĂ«. Si rezultat, lindin dy gabime tipike â njĂ« indeks i krijuar manualisht mbi çelĂ«sin primar dhe njĂ« indeks i ngjashĂ«m "manual" mbi njĂ« kolonĂ« unike. Problemi Ă«shtĂ« se nuk janĂ« tĂ« nevojshme â Postgres do t'i bĂ«jĂ« vetĂ«. TĂ« tilla indekse mund tĂ« hiqen me besim, dhe pĂ«r kĂ«tĂ« ka njĂ« diagnostikim. .
Problemi i tretĂ« â indekset e mbivendosura
Shumica e zhvilluesve të rinj krijojnë indekse mbi një kolonë. Me kalimin e kohës, pasi e provojnë këtë gjë, fillojnë të optimizojnë kërkesat e tyre dhe të shtojnë indekse më të ndërlikuara që përfshijnë disa kolona. Kështu fillojnë të shfaqen indekset mbi kolonat A, A+B, A+B+C etj. Të parat dy nga këto indekse mund të hidhen pa pasoja, pasi janë prefikse të të tretit. Kjo gjithashtu kursen ndjeshëm hapësirën në disk dhe për këtë ka një diagnostikim. .
Problemi i katĂ«rt â çelĂ«sat e jashtĂ«m pa indekse
Postgres lejon tĂ« krijojĂ« kufizime tĂ« çelĂ«sit tĂ« jashtĂ«m pa shĂ«nimin e indeksit mbĂ«shtetĂ«s. NĂ« shumĂ« situata, kjo nuk Ă«shtĂ« njĂ« problem dhe madje mund tĂ« mos shfaqet fare⊠Deri nĂ« njĂ« momentâŠ
KĂ«shtu ndodhi edhe me ne: thjesht nĂ« njĂ« moment, njĂ« punĂ« qĂ« ekzekutohej sipas orarit dhe pastronte bazĂ«n nga porositĂ« testuese, filloi tĂ« na ângrejĂ«â master hostin. CPU dhe IO shkonin nĂ« plafon, kĂ«rkesat ndalonin dhe prisnin pĂ«r fund. NjĂ« analizĂ« e shpejtĂ« tregon se ishin tĂ« bllokuara kĂ«rkesat e llojit:
fshi nga <table> ku ku id në (…)KĂ«tu, ndoshta, indeksi i id nĂ« tabelĂ«n pĂ«rkatĂ«se ishte aty, dhe tĂ« dhĂ«nat fshiheshin nĂ« kushtet qĂ« ishin shumĂ« tĂ« pakta. Dukej se gjithçka duhej tĂ« funksiononte, por, fatkeqĂ«sisht, nuk funksiononte.
Në ndihmë erdhi një mrekulli explain analyze dhe tregoi se, përveç fshirjes së të dhënave në tabelën përkatëse, po bëhet edhe një kontroll i integritetit referencial, dhe në një nga tabelat e lidhura, ky kontroll kalon në skanimin sekondar për shkak të mungesës së një indeksi të përshtatshëm. Kështu filloi diagnoza .
Problemi i pestĂ« â vlera null nĂ« indekse
SĂ« norma, Postgres pĂ«rfshin vlerat null nĂ« indeksat btree, por ato zakonisht nuk kanĂ« nevojĂ« atje. Prandaj unĂ« punoj shumĂ« pĂ«r t'i hequr kĂ«to nullĂ« (diagnostikĂ« ), duke krijuar indekse tĂ« pjesshme mbi kolonat e nullable, tĂ« tipit ku <A> nuk Ă«shtĂ« null. KĂ«shtu kam arritur tĂ« zvogĂ«loj pĂ«rmasat e njĂ« prej indekseve tona nga 1877 Mbyte nĂ« 16 Kbyte. NĂ« njĂ« nga shĂ«rbimet tona, pĂ«rmasa totale e DB-sĂ« u ul me 16% (me 4.3 Gbyte nĂ« numra absolutĂ«) pĂ«r shkak tĂ« pĂ«rjashtimit tĂ« vlerave null nga indeksat. NjĂ« kursim colossal hapĂ«sire diskus, me disa pĂ«rmirĂ«sime tĂ« thjeshta. đ
Problemi i gjashtĂ« â mungesa e çelqeve primarĂ«
PĂ«r shkak tĂ« veçorive tĂ« mekanizmit mund tĂ« ndodhĂ« njĂ« situatĂ« si , kur pĂ«rmasat e tabelĂ«s tuaj rriten shpejt pĂ«r shkak tĂ« numrit tĂ« madh tĂ« regjistrimeve tĂ« vdekura. E mendova naiv se kjo nuk do tĂ« na ndodhte dhe se baza jonĂ« nuk do e kishte kĂ«tĂ« fat, sepse ne, oh wow!!!, jemi zhvillues normalë⊠Sa naiv dhe budalla ishaâŠ
Një ditë të bukur, një migrim i mrekullueshëm azhurnoi të gjitha rekordet në një tabelë të madhe dhe të përdorur në mënyrë aktive. Ne morëm +100 GB shtesë në madhësinë e tabelës nga asgjë. Ishte mjaft e padëshirueshme, por aventurat tona nuk përfunduan këtu. Pas 15 orësh që avakuumi automatik për këtë tabelë u përfundua, u kuptua se vendi fizik nuk do të kthehej. Nuk mundëm të ndalonim shërbimin dhe të bënim një VACUUM FULL, prandaj u mor vendimi për të përdorur . Dhe këtu doli se pg_repack nuk di të përpunojë tabelat pa çelës primar ose ndonjë kufizim unikal, ndërsa për tabelën tonë nuk kishte çelës primar. Kjo e solli diagnostikimin .
Në versionin e bibliotekës 0.1.5 u shtua mundësia për të mbledhur të dhëna mbi bloat-in e tabelave dhe indekseve dhe për t'u përgjigjur në mënyrë të duhur.
Problemet shtatĂ« dhe tetĂ« â mungesa e indekseve dhe indekset e papĂ«rdorura
Dy diagnostikat e ardhshme â dhe â nĂ« formĂ«n e tyre pĂ«rfundimtare u shfaqĂ«n relativisht kohĂ«t e fundit. Problemi Ă«shtĂ« se ato nuk mund tĂ« shtoheshin lehtĂ«sisht.
Si e thashë më parë, ne përdorim një konfigurim me disa replika, dhe ngarkesa e lexim për hoste të ndryshëm është principialisht e ndryshme. Si rezultat, arrihet një situatë ku disa tabela dhe indekse në disa hoste praktikisht nuk përdoren, dhe për analizë është e nevojshme të mblidhet statistika nga të gjithë hostet në kluster. po ashtu duhet të bëhet në çdo host në kluster, nuk mund të bëhet vetëm në master.
Ky qasje na lehoi të kursejmë disa dhjetëra gigabajt duke fshirë indekse që kurrë nuk ishin përdorur, si dhe të shtojmë indekse të munguar për tabela që përdoren rrallë.
Si përfundim
Sigurisht, për praktisht të gjitha diagnostikimet mund të konfigurohet . Kështu mund të implementoni shpejt kontrolle në aplikacionin tuaj, duke parandaluar shfaqjen e gabimeve të reja, dhe më pas gradualisht të korrigjoni ato të vjetra.
Disa diagnostika mund të ekzekutohen tashmë në testet funksionale menjëherë pas aplikimit të migrimeve të DB. Dhe kjo, ndoshta, është një nga funksionalitetet më të fuqishme të bibliotekës sime. Një shembull përdorimi mund të shikohet në .
Kontrollat për indekse të papërdorura ose të mungesës, si dhe për bloat, ka kuptim të kryhen vetëm në një DB reale. Vlerat e mbledhura mund të shkruhen në ose dërgohen në sistemin e monitorimit.
Shpresoj shumë se pg-index-health do të jetë e dobishme dhe e kërkuar. Ju gjithashtu mund të kontribuoni në zhvillimin e bibliotekës duke raportuar çështjet e zbuluara dhe duke sugjeruar diagnostika të reja.
Burimi: habr.com
