Përshëndetje.
MĂ« quajnĂ« Vania dhe unĂ« jam njĂ« zhvillues Java. RastĂ«sisht, punoj shumĂ« me PostgreSQL â merrem me konfigurimin e BDs, optimizimin e strukturĂ«s, performancĂ«s dhe pak edhe me DBA nĂ« fundjavĂ«.
Kohët e fundit kam rregulluar disa baza të dhënash në shërbimet tona mikro dhe kam shkruar një bibliotekë java , e cila lehtëson këtë punë, kursen kohën time dhe ndihmon të shmang disa gabime tipike që zhvilluesit bëjnë. Pikërisht për këtë bibliotekë do të flasim sot.
Kufizimi
Versioni kryesor i PostgreSQL që po përdor është 10. Të gjitha SQL pyetjet që përdor janë gjithashtu verifikuar në versionin 11. Versioni minimal i mbështetur është 9.6.
Historia e mëparshme
Të gjitha filloi gati një vit më parë me një situatë të çuditshme për mua: krijimi konkurrues i indekseve nga asgjë përfundoi me një gabim. Indeksi vetë, si zakonisht, mbeti në një gjendje jo valide në bazë të të dhënave. Analiza e logeve tregoi mungesën e . Dhe filluan problemet... Duke shkuar më thellë, zbulova një mori problemesh në konfigurimin e BDs dhe, duke rrokur duarët, fillova t'i rregulloj me entuziazëm.
Problemi i parĂ« â konfigurimi i paracaktuar
Një metaforë për Postgres, që mund të funksionojë në një kafematikë, tashmë ka filluar të bezdisë shumë, por⊠konfigurimi i paracaktuar të vërtetë ngre disa pyetje. Të paktën, duhet të kushtojmë vëmendje për maintenance_work_mem, temp_file_limit, statement_timeout dhe lock_timeout.
NĂ« rastin tonĂ« maintenance_work_mem ishte si parazgjedhje 64 MByte, por temp_file_limit nĂ« fakt, rreth 2 GByte â na mungonin memorie e mjaftueshme pĂ«r krijimin e indekseve nĂ« njĂ« tabelĂ« tĂ« madhe.
Prandaj, në pg-index-health kam mbledhur disa , sipas mendimit tim, që duhet të konfigurohen për secilën BD.
Problemi i dytĂ« â indekse tĂ« dyfishta
Baza e tĂ« dhĂ«nave tona jetojnĂ« nĂ« disqe SSD, dhe ne pĂ«rdorim HA-konfigurimin me disa qendra tĂ« dhĂ«nash, host-master dhe n-numri i replikave. Hapsira nĂ« disk â njĂ« burim shumĂ« i çmuar pĂ«r ne; ai Ă«shtĂ« po aq i rĂ«ndĂ«sishĂ«m sa performanca dhe pĂ«rdorimi i CPU. Prandaj, nga njĂ«ra anĂ« na duhen indekse pĂ«r lexime tĂ« shpejta, ndĂ«rsa nga ana tjetĂ«r, nuk duam tĂ« shohim indekse tĂ« pa nevojshme nĂ« BD, pasi ato hanĂ« hapsirĂ« dhe ngadalĂ«sojnĂ« pĂ«rditĂ«simin e tĂ« dhĂ«nave.
Dhe kĂ«shtu, pasi rikuperuam tĂ« gjitha dhe shiqova , unĂ« vendosa tĂ« bĂ«j njĂ« "pastrim tĂ« madh". Doli se zhvilluesit nuk ua pĂ«lqejnĂ« tĂ« lexojnĂ« dokumentacionin e DB. Aspak. PĂ«r kĂ«tĂ« arsye, lindin dy gabime tipike â njĂ« indeks i krijuar manualisht mbi çelĂ«sin primar dhe njĂ« indeks i ngjashĂ«m "me dorĂ«" mbi njĂ« kolonĂ« unike. Problemi Ă«shtĂ« se kĂ«ta nuk janĂ« tĂ« nevojshĂ«m â Postgres e bĂ«n vetĂ«. TĂ« tillĂ« indekse mund tĂ« fshihen pa asnjĂ« shqetĂ«sim dhe pĂ«r kĂ«tĂ« ka njĂ« diagnostikim .
Problemi i tretĂ« â indekse qĂ« ndĂ«rthuren
Shumica e zhvilluesve fillestarë krijojnë indekse mbi një kolonë. Me kalimin e kohës, pasi e shijojnë këtë proces, njerëzit fillojnë të optimizojnë kërkesat e tyre dhe shtojnë indekse më të ndërlikuara që përfshijnë disa kolona. Kështu lindin indekset mbi kolonat A, A+B, A+B+C etj. Dy të parët e këtyre indekseve mund të fshihen pa asnjë shqetësim, sepse janë prefikse të të tretit. Kjo gjithashtu kursen shumë hapësirë në disk dhe për këtë ka një diagnostikim .
Problemi i katĂ«rt â çelĂ«sa tĂ« jashtĂ«m pa indekse
Postgres lejon krijimin e kufizimeve të çelësit të jashtëm pa specifikuar një indeks mbështetës. Në shumë situata, kjo nuk është një problem, dhe madje nuk mund të shfaqet... Deri në një moment...
Kështu ndodhi edhe me ne: thjesht në një moment, një punë që ekzekutohej sipas një programi dhe pastronte bazën nga porositë testuese, filloi të "shkonte" në master host-in. CPU dhe IO u rritën në maksimum, kërkesat u ngadalësuan dhe u ndërprenë për shkak të skadimit të kohës, shërbimi u uzurpua. Një analizë e shpejtë tregoi se kërkesat e typit:
fshij nga <table> ku ku është në (…)NĂ« tĂ« njĂ«jtĂ«n kohĂ«, indeksi mbi id nĂ« tabelĂ«n e synuar, natyrisht, ishte aty, dhe rekordet fshiheshin sipas kushteve fare pak. Dukej se gjithçka duhet tĂ« funksiononte, por, pĂ«r fat tĂ« keq, nuk funksiononte.
Më ndihmoi e mrekullueshme shpjego analizë dhe tregoi se përveç fshirjes së rekordëve në tabelën e synuar, gjithashtu zhvillohet një kontroll mbi integritetin referencial, dhe në një nga tabelat e lidhura ky kontroll dështonte në skanimin sekondar për shkak të mungesës së një indeksi të përshtatshëm. Kështu lindi diagnostikimi .
Problemi i pestĂ« â vlera null nĂ« indekse
Sipas parazgjedhjes, Postgres pĂ«rfshin vlerat null nĂ« indekset btree, por ato zakonisht nuk janĂ« tĂ« nevojshme. Prandaj, unĂ« mundohesha me zjarr t'i heq kĂ«to null (diagnostikimi ), duke krijuar indekse tĂ« pjesshme mbi kolonat nullable si ku nuk Ă«shtĂ« null. NĂ« kĂ«tĂ« mĂ«nyrĂ«, mĂ« Ă«shtĂ« arritur tĂ« reduktoj madhĂ«sinĂ« e njĂ«rit prej indekseve tanĂ« nga 1877 MB nĂ« 16 KB. NĂ« njĂ« nga shĂ«rbimet, madhĂ«sia totale e DB u ul me 16% (me 4.3 GB nĂ« numra absolutĂ«) pĂ«r shkak tĂ« pĂ«rjashtimit tĂ« vlerave null nga indext. NjĂ« kursim kolosal i hapĂ«sirĂ«s sĂ« diskut pĂ«rmes disa modifikimeve relativisht tĂ« thjeshta. đ
Problemi i gjashtĂ« â mungesa e çelĂ«save primarĂ«
PĂ«r shkak tĂ« veçorive tĂ« mekanizmit mund tĂ« ndodhĂ« njĂ« situatĂ« si , kur madhĂ«sia e tabelĂ«s tuaj rritet shpejt pĂ«r shkak tĂ« njĂ« numri tĂ« madh tĂ« regjistrimeve tĂ« vdekura. UnĂ« naivisht mendoja se kjo nuk do tĂ« na ndodhte, sepse ne ishim, oh wow!!!, zhvillues tĂ« normalizuar⊠Sa budalla dhe naiv ishaâŠ
Një ditë të bukur, një migrim i mrekullueshëm azhurnoi të gjitha regjistrimet në një tabelë të madhe dhe aktivisht të përdorur. Ne morëm +100 GB në madhësinë e tabelës pa ndonjë arsye. Ishte jashtëzakonisht e mërzitshme, por ndodhitë tona nuk përfunduan këtu. Pas 15 orësh përfundoi avakuumi automatik në këtë tabelë dhe u bë e qartë se vendi fizik nuk do të rikthehej. Nuk mundëm ta ndalonim shërbimin dhe të bënim VACUUM FULL, prandaj u mor vendimi për të përdorur . Dhe këtu rezultoi se pg_repack nuk arrin të përpunojë tabelat pa çelës primar ose ndonjë kufizim unik, dhe në tabelën tonë nuk kishte një çelës primar. Kështu lindi diagnostika .
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ë reaguar në kohë ndaj tij.
Problemet shtatĂ« dhe tetĂ« â mungesa e indekseve dhe indekse tĂ« pabĂ«rĂ«
Dy diagnostika tĂ« ardhshme â dhe â nĂ« formĂ«n e tyre pĂ«rfundimtare u shfaqĂ«n relativisht sĂ« fundmi. ĂĂ«shtja Ă«shtĂ« se ato nuk mund tĂ« shtohen lehtĂ«.
Siç kam thënë më parë, ne përdorim një konfigurim me disa replika, dhe ngarkesa lexuese në hoste të ndryshme është esencialisht e ndryshme. Si rezultat, krijohet një situatë në të cilën disa tabela dhe indekse në disa hoste praktikisht nuk përdoren, dhe për analizë është e nevojshme të mblidhen statistika nga të gjithë hostet në kluster. nuk është gjithashtu i nevojshëm në çdo host në kluster, nuk mund të bëhet vetëm në master.
Kjo qasje na lejoi të kursejmë disa dhjetëra gigabajt duke hequr indeksë që kurrë nuk janë përdorur, si dhe të shtojmë indekse të munguar në tabela me përdorim të rrallë.
Në përfundim
Sigurisht, për shumicën e diagnostikimeve është e mundur të konfigurohet . Në këtë mënyrë, mund të implementoni shpejt kontrollin në aplikacionin tuaj, duke parandaluar shfaqjen e gabimeve të reja dhe më pas duke korrigjuar gradualisht ato të vjetra.
Disa diagnostikime mund të kryhen tashmë në testet funksionale menjëherë pas aplikimit të migrimeve të DB. Dhe kjo, ndoshta, është një nga mundësitë më të fuqishme të bibliotekës sime. Një shembull përdorimi mund të shihet në .
Kontrollet për indeksë të papërdorur ose të munguar, si dhe për bloat, ka kuptim të kryhen vetëm në një DB real. Vlerat e grumbulluara mund të regjistrohen në ose të dërgohen në sistemin e monitorimit.
Shpresoj shumë që pg-index-health do të jetë e dobishme dhe e kërkuar. Ju gjithashtu mund të kontribuoni në zhvillimin e bibliotekës duke raportuar për problemet e zbuluara dhe duke propozuar diagnostika të reja.
Burimi: habr.com
