Hello.
Nire izena Vanya da eta Java garatzailea naiz. Gertatzen da PostgreSQL-rekin asko lan egiten dudala: datu-basea konfiguratzen, egitura, errendimendua optimizatzen eta asteburuetan DBA pixka bat jolasten.
Duela gutxi gure mikrozerbitzuetan hainbat datu-base txukundu eta java liburutegi bat idatzi dut , eta horrek lan hau errazten du, denbora aurrezten dit eta garatzaileek egindako ohiko akats batzuk saihesten laguntzen dit. Liburutegi honi buruz hitz egingo dugu gaur.
Lege-oharra
Lan egiten dudan PostgreSQL-ren bertsio nagusia 10 da. Erabiltzen ditudan SQL kontsulta guztiak 11 bertsioan ere probatzen dira. Onartutako gutxieneko bertsioa 9.6 da.
historiaurrea
Duela ia urtebete hasi zen dena arraroa egin zitzaidan egoera batekin: indize baten sorrera lehiakorra akats batekin amaitu zen. Indizea bera, ohi bezala, datu-basean geratu da egoera baliogabean. Erregistroen azterketak eskasia bat erakutsi zuen . Eta goaz... Sakonago sakonduz, datu-basearen konfigurazioan arazo mordoa aurkitu nituen eta, mahukak bilduz, begietan distira batekin hasi nintzen konpontzen.
Arazo bat - lehenetsitako konfigurazioa
Seguruenik denak nahiko nekatuta daude Postgres-i buruzko metaforaz, kafe-makina batean exekutatu daitekeena, baina... konfigurazio lehenetsiak galdera ugari sortzen ditu benetan. Gutxienez, merezi du arreta jartzea mantentze_lanak_mem, temp_fitxategi_muga, adierazpena_denbora-muga ΠΈ lock_timeout.
Gure kasuan mantentze_lanak_mem lehenetsia zen 64 MB, eta temp_fitxategi_muga 2 GB inguruko zerbait; besterik gabe, ez genuen nahikoa memoria mahai handi batean indize bat sortzeko.
Horregatik, urtean pg-index-osasuna Serie bat bildu nuen , nire ustez, datu-base bakoitzerako konfiguratu behar diren parametroak.
Bigarren arazoa - indize bikoiztuak
Gure datu-baseak SSD unitateetan bizi dira, eta erabiltzen ditugu HA-konfigurazioa hainbat datu-zentrorekin, ostalari nagusiarekin eta n-erreplika kopurua. Disko espazioa oso baliabide baliotsua da guretzat; ez da errendimendua eta CPU kontsumoa baino garrantzitsuagoa. Horregatik, alde batetik, irakurketa azkarra egiteko indizeak behar ditugu, eta, bestetik, ez dugu datu basean beharrezkoak ez diren indizerik ikusi nahi, lekua jaten baitute eta datuen eguneratzea moteltzen baitute.
Eta orain, dena berreskuratuta eta nahikoa ikusita , garbiketa βhandiβ bat antolatzea erabaki nuen. Garatzaileei ez zaiela gustatzen datu-baseen dokumentazioa irakurtzea. Ez zaie asko gustatzen. Hori dela eta, bi errore tipiko sortzen dira: eskuz sortutako indizea gako nagusi batean eta antzeko "eskuzko" indize bat zutabe bakarrean. Kontua da ez direla beharrezkoak - Postgresek berak egingo du dena. Horrelako indizeak segurtasunez ezabatu daitezke, eta horretarako diagnostikoak agertu dira .
Hiru arazoa - gurutzatutako indizeak
Garatzaile hasiberri gehienek zutabe bakarrean sortzen dituzte indizeak. Pixkanaka-pixkanaka, negozio hau ondo bizi izan ondoren, jendea bere kontsultak optimizatzen hasten da eta hainbat zutabe biltzen dituzten indize konplexuagoak gehitzen hasten dira. Horrela agertzen dira zutabeetako indizeak A, + B A, A + B + C eta abar. Indize horietako lehenengo biak segurtasunez bota daitezke, hirugarrenaren aurrizkiak baitira. Honek ere diskoko leku asko aurrezten du eta horretarako diagnostikoak daude .
Lau arazoa - atzerriko gakoak indizerik gabe
Postgres-ek atzerriko gakoen mugak sortzeko aukera ematen dizu, babes-indizerik zehaztu gabe. Egoera askotan hori ez da arazoa, eta agian ez da agertzea... Momentuz...
Berdin gertatu zen gurekin: momenturen batean lan bat, egutegi baten arabera exekutatzen eta proba-aginduen datu-basea garbituz, ostalari nagusiak "gehitzen" hasi zitzaigula. CPU eta IO alferrik galdu ziren, eskaerak moteldu ziren eta denbora-muga amaitu zuten, zerbitzua bostehun zen. Azterketa azkarra honelako kontsultak erakutsi zituen:
delete from <table> where id in (β¦)Kasu honetan, noski, helburu-taulan idaren araberako indize bat zegoen, eta oso erregistro gutxi ezabatu ziren baldintzaren arabera. Bazirudien denak funtzionatu behar zuela, baina, tamalez, ez zen horrela izan.
Zoragarria erreskatera etorri zen azaldu aztertu eta esan zuen xede-taulan erregistroak ezabatzeaz gain, erreferentziazko osotasunaren egiaztapena ere badagoela, eta erlazionatutako tauletako batean egiaztapen horrek huts egiten duela. eskaneatze sekuentziala indize egokirik ez dagoelako. Horrela jaio zen diagnostikoa .
Bost problema - balio nulua indizeetan
Lehenespenez, Postgres-ek balio nuluak barne hartzen ditu btree indizeetan, baina normalean ez dira bertan behar. Hori dela eta, arreta handiz saiatzen naiz nulu horiek (diagnostikoak ), motaren araberako zutabe nulagarrietan indize partzialak sortuz where <A> is not null. Horrela, gure indizeetako baten tamaina 1877 MBtik 16 KBra murriztu ahal izan nuen. Eta zerbitzuetako batean, datu-basearen tamaina % 16 gutxitu zen guztira (4.3 GB kopuru absolutuetan) indizeetatik balio nuluak baztertu direlako. Ikaragarrizko aurreztea diskoko espazioan aldaketa oso sinpleekin. π
Sei arazoa - gako nagusien falta
Mekanismoaren izaera dela eta horrelako egoera bat posible da zure mahaiaren tamaina azkar hazten ari denean erregistro hildako kopuru handi baten ondorioz. Inozoki uste nuen horrek ez gintuzkeela mehatxatuko, eta gure baseari ez zitzaiola gertatuko, gu, ba!!!, garatzaile normalak garelako... Zein ergel eta inozoa nintzen...
Egun batean, migrazio zoragarri batek taula handi eta aktibo batean erabilitako erregistro guztiak hartu eta eguneratu zituen. +100 GB lortu ditugu mahaiaren tamainara. Pena madarikatua izan zen, baina gure ezbeharrak ez ziren hor amaitu. Mahai honen auto-husketa amaitu eta 15 ordu geroago, argi geratu zen kokapen fisikoa ez zela itzuliko. Ezin izan dugu zerbitzua gelditu eta HUTSAK BETETA egin, horregatik erabiltzea erabaki dugu . Eta gero hori atera zen pg_repack ez daki taulak nola prozesatu gako nagusirik edo berezitasun-mugarik gabe, eta gure taulak ez zuen gako nagusirik. Horrela jaio zen diagnostikoa .
Liburutegiko bertsioan 0.1.5 Taulen eta indizeen puzketetatik datuak biltzeko eta haiei garaiz erantzuteko gaitasuna gehitu da.
Zazpi eta zortzi problemak - indize nahikoak eta erabili gabeko indizeak
Bi diagnostiko hauek dira: ΠΈ β duela gutxi agertu zen azken forman. Kontua da ezin zirela hartu eta gehitu besterik ez.
Dagoeneko idatzi dudan bezala, hainbat erreplika dituen konfigurazio bat erabiltzen dugu, eta ostalari ezberdinetan irakurtzeko karga funtsean ezberdina da. Ondorioz, egoera bihurtzen da ostalari batzuen taula eta indize batzuk ia ez direla erabiltzen, eta analisirako klusterreko ostalari guztien estatistikak bildu behar dituzu. Hau ere beharrezkoa da klusterreko ostalari guztietan; ezin duzu hau maisuan bakarrik egin.
Ikuspegi honi esker, zenbait hamarnaka gigabyte aurreztu ahal izan ditugu inoiz erabili ez ziren indizeak kenduz, baita gutxi erabiltzen diren tauletan falta diren indizeak gehituz ere.
Ondorio gisa
Jakina, ia diagnostiko guztietarako konfigura dezakezu . Horrela, zure aplikazioan egiaztapenak azkar ezar ditzakezu, akats berriak ager ez daitezen, eta, gero, zaharrak pixkanaka konpondu.
Diagnostiko batzuk proba funtzionaletan egin daitezke datu-baseen migrazioak zabaldu eta berehala. Eta hau da agian nire liburutegiaren ezaugarririk indartsuenetako bat. Erabilera adibide bat aurki daiteke .
Zentzuzkoa da erabiltzen ez diren edo falta diren indizeen egiaztapenak egitea, baita puztuta ere, benetako datu-base batean soilik. Bildutako balioak bertan erregistratu daitezke edo jarraipen-sistemara bidali.
Benetan espero dut hori pg-index-osasuna erabilgarria eta eskaria izango da. Liburutegiaren garapenean ere lagundu dezakezu aurkitzen dituzun arazoen berri emanez eta diagnostiko berriak iradokiz.
Iturria: www.habr.com