Привет.
My naam is Vanya en ek is 'n Java-ontwikkelaar. Dit gebeur so dat ek baie met PostgreSQL werk - die opstel van die databasis, die optimering van die struktuur, prestasie, en speel 'n bietjie DBA oor die naweke.
Ek het onlangs verskeie databasisse in ons mikrodienste opgeruim en 'n java-biblioteek geskryf , wat hierdie werk makliker maak, spaar my tyd en help my om 'n paar algemene foute wat deur ontwikkelaars gemaak word, te vermy. Dit is hierdie biblioteek waaroor ons vandag gaan praat.
Vrywaring
Die hoofweergawe van PostgreSQL waarmee ek werk is 10. Al die SQL-navrae wat ek gebruik, word ook op weergawe 11 getoets. Die minimum ondersteunde weergawe is 9.6.
voorgeskiedenis
Dit het alles byna 'n jaar gelede begin met 'n situasie wat vir my vreemd was: die mededingende skepping van 'n indeks het uit die bloute met 'n fout geëindig. Die indeks self, soos gewoonlik, het in 'n ongeldige toestand in die databasis gebly. Loganalise het 'n tekort getoon . En ons gaan ... Deur dieper te grawe, het ek 'n hele klomp probleme in die databasiskonfigurasie ontdek en, terwyl ek my moue opgerol het, dit met 'n vonkel in my oë begin regmaak.
Probleem een - verstek konfigurasie
Waarskynlik, almal is reeds redelik moeg vir die metafoor oor Postgres, wat op 'n koffiemaker uitgevoer kan word, maar ... die verstekkonfigurasie laat werklik 'n aantal vrae ontstaan. Op 'n minimum is dit die moeite werd om aandag te gee onderhoud_werk_mem, temp_lêer_limiet, statement_timeout и lock_timeout.
In ons geval onderhoud_werk_mem was die verstek 64 MB, en temp_lêer_limiet iets rondom 2 GB - ons het eenvoudig nie genoeg geheue gehad om 'n indeks op 'n groot tafel te skep nie.
Daarom, in pg-indeks-gesondheid Ek het 'n reeks versamel , na my mening, die parameters wat vir elke databasis gekonfigureer moet word.
Probleem twee - duplikaat-indekse
Ons databasisse leef op SSD-aandrywers, en ons gebruik HA-konfigurasie met verskeie datasentrums, meestergasheer en n-aantal replikas. Skyfspasie is 'n baie waardevolle hulpbron vir ons; dit is nie minder belangrik as werkverrigting en SVE-verbruik nie. Daarom het ons aan die een kant indekse nodig vir vinnige lees, en aan die ander kant wil ons nie onnodige indekse in die databasis sien nie, aangesien dit spasie opvreet en data-opdatering vertraag.
En nou, nadat ek alles herstel het en genoeg gesien het , het ek besluit om 'n "groot" suiwering te reël. Dit het geblyk dat ontwikkelaars nie daarvan hou om databasisdokumentasie te lees nie. Hulle hou nie baie daarvan nie. As gevolg hiervan ontstaan twee tipiese foute - 'n handgemaakte indeks op 'n primêre sleutel en 'n soortgelyke "handmatige" indeks op 'n unieke kolom. Die feit is dat hulle nie nodig is nie - Postgres sal alles self doen. Sulke indekse kan veilig uitgevee word, en diagnose het vir hierdie doel verskyn .
Probleem drie - kruisende indekse
Die meeste beginner ontwikkelaars skep indekse op 'n enkele kolom. Geleidelik, nadat hulle hierdie besigheid deeglik ervaar het, begin mense om hul navrae te optimaliseer en meer komplekse indekse by te voeg wat verskeie kolomme insluit. Dit is hoe indekse op kolomme verskyn A, A + B, A + B + C en so aan. Die eerste twee van hierdie indekse kan veilig weggegooi word, aangesien dit voorvoegsels van die derde is. Dit spaar ook baie skyfspasie en daar is diagnose hiervoor .
Probleem vier - vreemde sleutels sonder indekse
Postgres laat jou toe om buitelandse sleutelbeperkings te skep sonder om 'n steunindeks te spesifiseer. In baie situasies is dit nie 'n probleem nie, en manifesteer dalk nie eers nie... Vir eers...
Dit was dieselfde met ons: dit is net dat 'n taak, wat volgens 'n skedule loop en die databasis van toetsbestellings skoongemaak het, op 'n sekere tydstip by ons begin "toegevoeg" word deur die meestergasheer. SVE en IO het tot niet gegaan, versoeke het verlangsaam en is uitgetel, die diens was vyfhonderd. Vinnige ontleding het gewys dat navrae soos:
delete from <table> where id in (…)In hierdie geval was daar natuurlik 'n indeks volgens id in die teikentabel, en baie min rekords is geskrap volgens die toestand. Dit het gelyk of alles moes werk, maar helaas, dit het nie.
Die wonderlike een het tot die redding gekom verduidelik ontleed en gesê dat benewens die verwydering van rekords in die teikentabel, daar ook 'n verwysingsintegriteitkontrole is, en op een van die verwante tabelle misluk hierdie kontrole opeenvolgende skandering weens die gebrek aan 'n geskikte indeks. So is diagnostiek gebore .
Probleem vyf – nulwaarde in indekse
Postgres sluit standaard nulwaardes in btree-indekse in, maar dit is gewoonlik nie daar nodig nie. Daarom probeer ek ywerig om hierdie nulle (diagnostiek ), skep gedeeltelike indekse op nulbare kolomme volgens tipe where <A> is not null. Op hierdie manier kon ek die grootte van een van ons indekse van 1877 MB tot 16 KB verminder. En in een van die dienste het die databasisgrootte in totaal met 16% afgeneem (met 4.3 GB in absolute getalle) as gevolg van die uitsluiting van nulwaardes van die indekse. Enorme besparings in skyfspasie met baie eenvoudige wysigings. 🙂
Probleem ses – gebrek aan primêre sleutels
As gevolg van die aard van die meganisme 'n situasie soos hierdie is moontlik wanneer die grootte van jou tafel vinnig groei as gevolg van 'n groot aantal dooie rekords. Ek het naïef geglo dat dit ons nie sou bedreig nie, en dat dit nie met ons basis sou gebeur nie, want ons, sjoe!!!, is normale ontwikkelaars... Hoe dom en naïef was ek nie...
Eendag het een wonderlike migrasie al die rekords in 'n groot en aktief gebruikte tabel geneem en opgedateer. Ons het +100 GB vir die tafelgrootte uit die bloute gekry. Dit was ’n verdomde skande, maar ons rampe het nie daar geëindig nie. Nadat die outovakuum op hierdie tafel 15 uur later geëindig het, het dit duidelik geword dat die fisiese ligging nie sou terugkeer nie. Ons kon nie die diens stop en VAKUUM VOL maak nie, so ons het besluit om te gebruik . En toe blyk dit dat pg_herpak weet nie hoe om tabelle te verwerk sonder 'n primêre sleutel of ander uniekheidsbeperking nie, en ons tabel het nie 'n primêre sleutel gehad nie. So is diagnostiek gebore .
In die biblioteek weergawe 0.1.5 Die vermoë om data in te samel van opblaas van tabelle en indekse en betyds daarop te reageer is bygevoeg.
Probleme sewe en agt - onvoldoende indekse en ongebruikte indekse
Die volgende twee diagnostiek is: и – het relatief onlangs in hul finale vorm verskyn. Die punt is dat hulle nie net geneem en bygevoeg kon word nie.
Soos ek reeds geskryf het, gebruik ons 'n konfigurasie met verskeie replikas, en die leeslading op verskillende gashere is fundamenteel anders. As gevolg hiervan, die situasie blyk dat sommige tabelle en indekse op sommige gashere feitlik nie gebruik word nie, en vir ontleding moet jy statistieke van alle gashere in die groep insamel. Dit is ook nodig op elke gasheer in die groep; jy kan dit nie net op die meester doen nie.
Hierdie benadering het ons in staat gestel om etlike tientalle gigagrepe te bespaar deur indekse te verwyder wat nooit gebruik is nie, asook ontbrekende indekse by selde gebruikte tabelle by te voeg.
As 'n gevolgtrekking
Natuurlik, vir byna alle diagnostiek kan jy konfigureer . Op hierdie manier kan jy vinnig kontroles in jou toepassing implementeer, verhoed dat nuwe foute verskyn, en dan geleidelik oues regmaak.
Sommige diagnostiek kan in funksionele toetse uitgevoer word onmiddellik nadat databasismigrasies uitgerol is. En dit is miskien een van die kragtigste kenmerke van my biblioteek. 'n Voorbeeld van gebruik kan gevind word in .
Dit maak sin om kontroles uit te voer vir ongebruikte of ontbrekende indekse, sowel as vir opblaas, slegs op 'n regte databasis. Die versamelde waardes kan aangeteken word in of na die moniteringstelsel gestuur word.
Ek hoop dit regtig pg-indeks-gesondheid sal nuttig en in aanvraag wees. Jy kan ook bydra tot die biblioteek se ontwikkeling deur probleme wat jy vind aan te meld en nuwe diagnostiek voor te stel.
Bron: will.com