Sawa.
Jina langu ni Vanya na mimi ni msanidi programu wa Java. Inatokea kwamba ninafanya kazi sana na PostgreSQL - kusanidi hifadhidata, kuboresha muundo, utendaji, na kucheza DBA kidogo wikendi.
Hivi majuzi nimekusanya hifadhidata kadhaa kwenye huduma zetu ndogo na kuandika maktaba ya java , ambayo hurahisisha kazi hii, huniokoa wakati na hunisaidia kuepuka makosa ya kawaida yanayofanywa na wasanidi programu. Ni maktaba hii ambayo tutazungumza juu ya leo.
Onyo
Toleo kuu la PostgreSQL ninalofanya kazi nalo ni 10. Maswali yote ya SQL ninayotumia pia yanajaribiwa kwenye toleo la 11. Toleo la chini linalotumika ni 9.6.
kabla ya historia
Yote ilianza karibu mwaka mmoja uliopita na hali ambayo ilikuwa ya kushangaza kwangu: uundaji wa ushindani wa fahirisi nje ya bluu ulimalizika na hitilafu. Faharasa yenyewe, kama kawaida, ilibaki kwenye hifadhidata katika hali batili. Uchambuzi wa kumbukumbu ulionyesha upungufu . Na tunaenda ... Kuchimba zaidi, niligundua rundo zima la shida katika usanidi wa hifadhidata na, nikikunja mikono yangu, nikaanza kuzirekebisha kwa kung'aa machoni pangu.
Tatizo moja - usanidi chaguo-msingi
Pengine kila mtu amechoshwa na sitiari kuhusu Postgres, ambayo inaweza kuendeshwa kwenye mtengenezaji wa kahawa, lakini... usanidi chaguo-msingi huibua maswali kadhaa. Kwa kiwango cha chini, inafaa kulipa kipaumbele matengenezo_kazi_mem, temp_file_limit, statement_timeout ΠΈ lock_timeout.
Kwa upande wetu matengenezo_kazi_mem ilikuwa chaguo-msingi 64 MB, na temp_file_limit kitu karibu 2 GB - hatukuwa na kumbukumbu ya kutosha kuunda faharisi kwenye jedwali kubwa.
Kwa hivyo, ndani pg-index-afya Nilikusanya mfululizo , kwa maoni yangu, vigezo ambavyo vinapaswa kusanidiwa kwa kila hifadhidata.
Tatizo la pili - faharasa rudufu
Hifadhidata zetu zinaishi kwenye viendeshi vya SSD, na tunatumia HA-usanidi na vituo vingi vya data, mwenyeji mkuu na n-idadi ya nakala. Nafasi ya diski ni rasilimali muhimu sana kwetu; sio muhimu kuliko utendaji na matumizi ya CPU. Kwa hivyo, kwa upande mmoja, tunahitaji faharisi za kusoma haraka, na kwa upande mwingine, hatutaki kuona faharisi zisizohitajika kwenye hifadhidata, kwani wanakula nafasi na kupunguza kasi ya uppdatering wa data.
Na sasa, baada ya kurejesha kila kitu na kuona vya kutosha , niliamua kuandaa utakaso "mkubwa". Ilibadilika kuwa watengenezaji hawapendi kusoma nyaraka za hifadhidata. Hawapendi sana. Kwa sababu hii, makosa mawili ya kawaida hutokea - faharisi iliyoundwa kwa mikono kwenye ufunguo wa msingi na faharisi sawa ya "mwongozo" kwenye safu wima ya kipekee. Ukweli ni kwamba hazihitajiki - Postgres itafanya kila kitu yenyewe. Fahirisi kama hizo zinaweza kufutwa kwa usalama, na utambuzi umeonekana kwa kusudi hili .
Tatizo la tatu - intersecting fahirisi
Watengenezaji wengi wa novice huunda faharasa kwenye safu wima moja. Hatua kwa hatua, baada ya kuonja kabisa biashara hii, watu huanza kuboresha maswali yao na kuongeza faharisi ngumu zaidi zinazojumuisha safu wima kadhaa. Hivi ndivyo faharasa kwenye safu wima zinavyoonekana A, A + B, A + B + C Nakadhalika. Mbili za kwanza za fahirisi hizi zinaweza kutupwa nje kwa usalama, kwa kuwa ni viambishi awali vya ya tatu. Hii pia huokoa nafasi nyingi za diski na kuna uchunguzi wa hii .
Tatizo nne - funguo za kigeni bila indexes
Postgres hukuruhusu kuunda vizuizi vya ufunguo vya kigeni bila kubainisha faharasa inayounga mkono. Katika hali nyingi hii sio shida, na inaweza hata isijidhihirishe yenyewe ... Kwa wakati huu ...
Ilikuwa sawa na sisi: ni kwamba kwa wakati fulani kazi, inayoendesha kulingana na ratiba na kusafisha database ya maagizo ya mtihani, ilianza "kuongezwa" kwetu na mwenyeji mkuu. CPU na IO zilipotea, maombi yalipungua na yaliwekwa muda, huduma ilikuwa mia tano. Uchambuzi wa haraka ilionyesha kuwa maswali kama:
delete from <table> where id in (β¦)Katika kesi hii, bila shaka, kulikuwa na index kwa id katika meza ya lengo, na rekodi chache sana zilifutwa kulingana na hali hiyo. Ilionekana kuwa kila kitu kinapaswa kufanya kazi, lakini, ole, haikufanya kazi.
Yule mzuri alikuja kuokoa kueleza uchambuzi na kusema kuwa pamoja na kufuta rekodi kwenye jedwali lengwa, pia kuna ukaguzi wa uadilifu wa marejeleo, na kwenye mojawapo ya jedwali husika hundi hii inashindwa. skana ya mfuatano kutokana na ukosefu wa fahirisi inayofaa. Kwa hivyo utambuzi ulizaliwa .
Tatizo la tano - thamani isiyofaa katika faharisi
Kwa msingi, Postgres inajumuisha maadili yasiyofaa katika faharisi za btree, lakini kawaida hazihitajiki hapo. Kwa hivyo, ninajaribu kwa bidii kutupa nulls hizi (utambuzi ), kuunda faharisi za sehemu kwenye safu wima zisizoweza kubatilishwa kulingana na aina where <A> is not null. Kwa njia hii niliweza kupunguza saizi ya moja ya faharisi zetu kutoka 1877 MB hadi 16 KB. Na katika moja ya huduma, saizi ya hifadhidata ilipungua kwa jumla kwa 16% (kwa 4.3 GB kwa nambari kamili) kwa sababu ya kutengwa kwa maadili yasiyofaa kutoka kwa faharisi. Akiba kubwa katika nafasi ya diski na marekebisho rahisi sana. π
Tatizo la sita - ukosefu wa funguo za msingi
Kutokana na hali ya utaratibu hali kama hii inawezekana wakati ukubwa wa meza yako inakua kwa kasi kutokana na idadi kubwa ya rekodi zilizokufa. Niliamini kwa ujinga kuwa hii haitatutishia, na kwamba hii haitatokea kwa msingi wetu, kwa sababu sisi, wow!!!, ni watengenezaji wa kawaida ... Jinsi nilivyokuwa mjinga na mjinga ...
Siku moja, uhamiaji mmoja wa ajabu ulichukua na kusasisha rekodi zote kwenye jedwali kubwa na lililotumika kikamilifu. Tulipata +100 GB kwa ukubwa wa jedwali nje ya bluu. Ilikuwa aibu sana, lakini misiba yetu haikuishia hapo. Baada ya otomatiki kwenye jedwali hili kumalizika saa 15 baadaye, ikawa wazi kuwa eneo halisi halitarudi. Hatukuweza kusimamisha huduma na kufanya VACUUM FULL, kwa hivyo tuliamua kutumia . Na kisha ikawa hivyo pg_repack hajui jinsi ya kuchakata majedwali bila ufunguo msingi au kizuizi kingine cha kipekee, na jedwali letu halikuwa na ufunguo msingi. Kwa hivyo utambuzi ulizaliwa .
Katika toleo la maktaba 0.1.5 Uwezo wa kukusanya data kutoka kwa bloat ya meza na indexes na kujibu kwa wakati ufaao umeongezwa.
Matatizo saba na nane - indexes haitoshi na indexes outnyttjade
Utambuzi mbili zifuatazo ni: ΠΈ - walionekana katika fomu yao ya mwisho hivi karibuni. Jambo ni kwamba hawakuweza tu kuchukuliwa na kuongezwa.
Kama nilivyoandika tayari, tunatumia usanidi na nakala kadhaa, na mzigo wa kusoma kwenye majeshi tofauti ni tofauti kimsingi. Matokeo yake, hali inageuka kuwa baadhi ya meza na indexes kwenye baadhi ya majeshi hazitumiwi, na kwa uchambuzi unahitaji kukusanya takwimu kutoka kwa majeshi yote kwenye nguzo. Hii pia ni muhimu kwa kila mwenyeji kwenye nguzo; huwezi kufanya hivi kwa bwana pekee.
Njia hii ilituruhusu kuokoa makumi kadhaa ya gigabytes kwa kuondoa faharisi ambazo hazijatumiwa kamwe, na pia kuongeza fahirisi zilizokosekana kwa meza ambazo hazijatumiwa sana.
Kama hitimisho
Bila shaka, kwa karibu uchunguzi wote unaweza kusanidi . Kwa njia hii, unaweza kutekeleza haraka ukaguzi katika programu yako, kuzuia makosa mapya kuonekana, na kisha kurekebisha hatua kwa hatua ya zamani.
Baadhi ya uchunguzi unaweza kufanywa katika majaribio ya utendaji mara baada ya kusambaza uhamishaji wa hifadhidata. Na hii labda ni moja ya vipengele vya nguvu zaidi vya maktaba yangu. Mfano wa matumizi unaweza kupatikana katika .
Inaeleweka kufanya ukaguzi wa faharisi ambazo hazijatumiwa au zinazokosekana, na vile vile kwa bloat, kwenye hifadhidata halisi. Thamani zilizokusanywa zinaweza kurekodiwa ndani au kutumwa kwa mfumo wa ufuatiliaji.
Natumai sana hilo pg-index-afya itakuwa muhimu na kwa mahitaji. Unaweza pia kuchangia maendeleo ya maktaba kwa kuripoti matatizo unayopata na kupendekeza uchunguzi mpya.
Chanzo: mapenzi.com