Ninapendekeza usome nakala ya ripoti ya mapema ya Vladimir Sitnikov ya 2016 "PostgreSQL na JDBC wanapunguza juisi yote"
Habari za mchana Jina langu ni Vladimir Sitnikov. Nimekuwa nikifanya kazi kwa NetCracker kwa miaka 10. Na mimi nina zaidi katika uzalishaji. Kila kitu kinachohusiana na Java, kila kitu kinachohusiana na SQL ndicho ninachopenda.
Na leo nitazungumza juu ya kile tulichokutana nacho katika kampuni tulipoanza kutumia PostgreSQL kama seva ya hifadhidata. Na sisi hufanya kazi zaidi na Java. Lakini kile nitakachokuambia leo sio tu kuhusu Java. Kama mazoezi yameonyesha, hii pia hutokea katika lugha nyingine.
Tutazungumza:
- kuhusu sampuli za data.
- Kuhusu kuhifadhi data.
- Na pia kuhusu utendaji.
- Na kuhusu reki za chini ya maji ambazo zimezikwa huko.
Hebu tuanze na swali rahisi. Tunachagua safu moja kutoka kwa meza kulingana na ufunguo wa msingi.
Hifadhidata iko kwenye mwenyeji sawa. Na ukulima huu wote huchukua 20 milliseconds.
Hizi milliseconds 20 ni nyingi. Ikiwa una maombi kama haya 100, basi unatumia muda kwa sekunde kuvinjari maombi haya, yaani, tunapoteza muda.
Hatupendi kufanya hivi na kuangalia ni nini msingi unatupa kwa hili. Hifadhidata inatupa chaguzi mbili za kutekeleza maswali.
Chaguo la kwanza ni ombi rahisi. Je, ni nini kizuri kuhusu hilo? ukweli kwamba sisi kuchukua na kutuma, na hakuna zaidi.
Hifadhidata pia ina swala la hali ya juu, ambalo ni gumu zaidi, lakini linafanya kazi zaidi. Unaweza kutuma ombi la kuchanganua, kutekeleza, kutofautisha kwa kutofautisha, nk.
Hoja iliyopanuliwa sana ni jambo ambalo hatutashughulikia katika ripoti ya sasa. Sisi, labda, tunataka kitu kutoka kwa hifadhidata na kuna orodha ya matakwa ambayo imeundwa kwa namna fulani, yaani, hii ndiyo tunayotaka, lakini haiwezekani sasa na mwaka ujao. Kwa hivyo tumeirekodi tu na tutazunguka kuwatikisa watu wakuu.
Na tunachoweza kufanya ni swala rahisi na hoja iliyopanuliwa.
Ni nini maalum kwa kila mbinu?
Swali rahisi ni nzuri kwa utekelezaji wa mara moja. Mara baada ya kufanyika na kusahaulika. Na shida ni kwamba haitumii muundo wa data ya binary, i.e. haifai kwa mifumo fulani ya utendaji wa juu.
Hoja iliyopanuliwa - hukuruhusu kuokoa muda kwenye uchanganuzi. Hii ndio tulifanya na kuanza kutumia. Hii kweli, ilitusaidia sana. Hakuna akiba tu kwenye uchanganuzi. Kuna akiba kwenye uhamishaji wa data. Kuhamisha data katika umbizo la binary ni bora zaidi.
Tuendelee na mazoezi. Hivi ndivyo programu ya kawaida inavyoonekana. Inaweza kuwa Java, nk.
Tumeunda kauli. Imetekeleza amri. Imeundwa karibu. Kosa liko wapi hapa? Shida ni nini? Hakuna shida. Hivi ndivyo inavyosema katika vitabu vyote. Hivi ndivyo inavyopaswa kuandikwa. Ikiwa unataka utendaji wa juu, andika kama hii.
Lakini mazoezi yameonyesha kuwa hii haifanyi kazi. Kwa nini? Kwa sababu tunayo njia ya "karibu". Na tunapofanya hivi, kutoka kwa mtazamo wa hifadhidata inageuka kuwa ni kama mvutaji sigara anayefanya kazi na hifadhidata. Tulisema "PARSE EXECUTE DEALLOCATE".
Kwa nini uundaji huu wote wa ziada na upakuaji wa taarifa? Hakuna anayezihitaji. Lakini kawaida hutokea katika PreparedStatements ni kwamba tunapozifunga, hufunga kila kitu kwenye hifadhidata. Hii sio tunayotaka.
Tunataka, kama watu wenye afya, kufanya kazi na msingi. Tulichukua na kuandaa taarifa yetu mara moja, kisha tunaitekeleza mara nyingi. Kwa kweli, mara nyingi - hii ni mara moja katika maisha yote ya maombi - yamechanganuliwa. Na tunatumia kitambulisho sawa cha taarifa kwenye REST tofauti. Hili ndilo lengo letu.
Tunawezaje kufikia hili?
Ni rahisi sana - hakuna haja ya kufunga taarifa. Tunaandika kama hii: "tayarisha" "tekeleza".
Ikiwa tunazindua kitu kama hiki, ni wazi kwamba kitu kitafurika mahali fulani. Ikiwa haijulikani, unaweza kujaribu. Wacha tuandike alama inayotumia njia hii rahisi. Tengeneza taarifa. Tunaizindua kwenye toleo fulani la kiendeshi na tunagundua kuwa inaanguka haraka na kupoteza kumbukumbu yote iliyokuwa nayo.
Ni wazi kwamba makosa hayo yanarekebishwa kwa urahisi. Sitazungumza juu yao. Lakini nitasema kwamba toleo jipya linafanya kazi kwa kasi zaidi. Njia hiyo ni ya kijinga, lakini bado.
Jinsi ya kufanya kazi kwa usahihi? Tunahitaji kufanya nini kwa hili?
Kwa kweli, maombi hufunga taarifa kila wakati. Katika vitabu vyote wanasema kuifunga, vinginevyo kumbukumbu itavuja.
Na PostgreSQL haijui jinsi ya kuweka maswali. Inahitajika kwamba kila kikao kitengeneze kache hii yenyewe.
Na hatutaki kupoteza muda katika kuchanganua pia.
Na kama kawaida tuna chaguzi mbili.
Chaguo la kwanza ni kwamba tunaichukua na kusema kwamba wacha tufunge kila kitu kwenye PgSQL. Kuna kache hapo. Inashika kila kitu. Itageuka kuwa nzuri. Tuliona hili. Tuna maombi 100500. Haifanyi kazi. Hatukubali kugeuza maombi kuwa taratibu kwa mikono. Hapana hapana.
Tuna chaguo la pili - chukua na uikate sisi wenyewe. Tunafungua vyanzo na kuanza kukata. Tuliona na kuona. Ilibadilika kuwa sio ngumu sana kufanya.
Hii ilionekana mnamo Agosti 2015. Sasa kuna toleo la kisasa zaidi. Na kila kitu ni kubwa. Inafanya kazi vizuri sana hivi kwamba hatubadilishi chochote kwenye programu. Na hata tuliacha kufikiria katika mwelekeo wa PgSQL, i.e. hii ilikuwa ya kutosha kwetu kupunguza gharama zote za juu hadi karibu sifuri.
Ipasavyo, taarifa zilizotayarishwa na Seva huwashwa kwenye utekelezaji wa 5 ili kuzuia kupoteza kumbukumbu katika hifadhidata kwa kila ombi la wakati mmoja.
Unaweza kuuliza - nambari ziko wapi? Unapata nini? Na hapa sitatoa nambari, kwa sababu kila ombi lina yake mwenyewe.
Hoja zetu zilikuwa hivi kwamba tulitumia takriban milisekunde 20 kuchanganua hoja za OLTP. Kulikuwa na milisekunde 0,5 za utekelezaji, milisekunde 20 za kuchanganua. Ombi - 10 KB ya maandishi, mistari 170 ya mpango. Hili ni ombi la OLTP. Inaomba mistari 1, 5, 10, wakati mwingine zaidi.
Lakini hatukutaka kupoteza milliseconds 20 hata kidogo. Tuliipunguza hadi 0. Kila kitu ni nzuri.
Unaweza kuchukua nini kutoka hapa? Ikiwa una Java, basi unachukua toleo la kisasa la dereva na ufurahi.
Ikiwa unazungumza lugha tofauti, basi fikiria - labda unahitaji hii pia? Kwa sababu kutoka kwa mtazamo wa lugha ya mwisho, kwa mfano, ikiwa PL 8 au unayo LibPQ, basi sio wazi kwako kuwa unatumia wakati sio kutekeleza, kwa kugawa, na hii inafaa kuangalia. Vipi? Kila kitu ni bure.
Isipokuwa kwamba kuna makosa na upekee fulani. Na tutazungumza juu yao hivi sasa. Zaidi ya hayo itakuwa juu ya akiolojia ya viwanda, juu ya kile tulichopata, kile tulichopata.
Ikiwa ombi limetolewa kwa nguvu. Inatokea. Mtu huunganisha kamba pamoja, na kusababisha swali la SQL.
Kwa nini yeye ni mbaya? Ni mbaya kwa sababu kila wakati tunaishia na kamba tofauti.
Na hashCode ya mfuatano huu tofauti inahitaji kusomwa tena. Kwa kweli hii ni kazi ya CPU - kupata maandishi ya ombi refu hata kwenye heshi iliyopo sio rahisi sana. Kwa hiyo, hitimisho ni rahisi - usizalishe maombi. Zihifadhi katika kigezo kimoja. Na ufurahi.
Tatizo linalofuata. Aina za data ni muhimu. Kuna ORM ambazo zinasema kuwa haijalishi ni aina gani ya NULL kuna, basi kuwe na aina fulani. Ikiwa Int, basi tunasema setInt. Na kama NULL, basi iwe daima VARCHAR. Na nini tofauti gani katika mwisho nini NULL ni huko? Database yenyewe itaelewa kila kitu. Na picha hii haifanyi kazi.
Kwa mazoezi, hifadhidata haijali hata kidogo. Ikiwa ulisema mara ya kwanza kuwa hii ni nambari, na mara ya pili ulisema kuwa ni VARCHAR, basi haiwezekani kutumia tena taarifa zilizotayarishwa na Seva. Na katika kesi hii, tunapaswa kuunda tena taarifa yetu.
Ikiwa unatekeleza hoja sawa, hakikisha kuwa aina za data kwenye safu yako hazichanganyiki. Unahitaji kuangalia NULL. Hili ni hitilafu ya kawaida tuliyokuwa nayo baada ya kuanza kutumia PreparedStatements
Sawa, imewashwa. Labda walimchukua dereva. Na tija ikashuka. Mambo yakawa mabaya.
Je, hii hutokeaje? Je, hii ni mdudu au kipengele? Kwa bahati mbaya, haikuwezekana kuelewa ikiwa hii ni mdudu au kipengele. Lakini kuna hali rahisi sana ya kuzaliana tena shida hii. Alituvizia bila kutarajia. Na inajumuisha sampuli halisi kutoka kwa jedwali moja. Sisi, bila shaka, tulikuwa na maombi zaidi kama hayo. Kama sheria, walijumuisha meza mbili au tatu, lakini kuna hali kama hiyo ya uchezaji. Chukua toleo lolote kutoka kwa hifadhidata yako na uicheze.
Jambo ni kwamba tuna safu mbili, ambayo kila moja imeorodheshwa. Kuna safu mlalo milioni moja kwenye safu NULL. Na safu ya pili ina mistari 20 tu. Tunapofanya bila vigezo vilivyofungwa, kila kitu hufanya kazi vizuri.
Ikiwa tutaanza kutekeleza na vijiti vilivyofungwa, i.e. tutafanya "?" au "$1" kwa ombi letu, tunaishia kupata nini?
Utekelezaji wa kwanza ni kama inavyotarajiwa. Ya pili ni kasi kidogo. Kitu kilihifadhiwa. Tatu, nne, tano. Kisha bang - na kitu kama hicho. Na jambo baya zaidi ni kwamba hii hutokea kwenye utekelezaji wa sita. Nani alijua kwamba ilikuwa muhimu kutekeleza mauaji sita hasa ili kuelewa mpango halisi wa utekelezaji ulikuwa nini?
Nani ana hatia? Nini kimetokea? Hifadhidata ina uboreshaji. Na inaonekana kuwa bora zaidi kwa kesi ya kawaida. Na, ipasavyo, kuanzia wakati fulani, anabadilisha mpango wa generic, ambayo, kwa bahati mbaya, inaweza kuwa tofauti. Inaweza kugeuka kuwa sawa, au inaweza kuwa tofauti. Na kuna aina fulani ya thamani ya kizingiti ambayo inaongoza kwa tabia hii.
Unaweza kufanya nini kuhusu hilo? Hapa, bila shaka, ni vigumu zaidi kudhani chochote. Kuna suluhisho rahisi ambalo tunatumia. Hii ni +0, OFFSET 0. Hakika unajua masuluhisho kama haya. Tunachukua tu na kuongeza "+0" kwa ombi na kila kitu ni sawa. Nitakuonyesha baadaye.
Na kuna chaguo jingine - angalia mipango kwa uangalifu zaidi. Msanidi programu lazima si tu kuandika ombi, lakini pia kusema "eleza kuchambua" mara 6. Ikiwa ni 5, haitafanya kazi.
Na kuna chaguo la tatu - kuandika barua kwa pgsql-hackers. Niliandika, hata hivyo, bado haijulikani wazi ikiwa hii ni mdudu au kipengele.
Tunapofikiria kama hii ni hitilafu au kipengele, turekebishe. Hebu tuchukue ombi letu na kuongeza "+0". Kila kitu kiko sawa. Alama mbili na sio lazima hata ufikirie juu ya jinsi ilivyo au ni nini. Rahisi sana. Tulikataza hifadhidata kutumia faharasa kwenye safu wima hii. Hatuna index kwenye safu ya "+0" na ndivyo, database haitumii index, kila kitu ni sawa.
Hii ndio kanuni ya 6 kueleza. Sasa katika matoleo ya sasa lazima uifanye mara 6 ikiwa una vigezo vilivyofungwa. Kama huna vigezo amefungwa, hii ni nini sisi kufanya. Na mwishowe ni ombi hili haswa ambalo linashindwa. Si jambo gumu.
Inaonekana, ni kiasi gani kinawezekana? Mdudu hapa, mdudu huko. Kwa kweli, mdudu yuko kila mahali.
Hebu tuangalie kwa karibu. Kwa mfano, tuna schemas mbili. Mpango A wenye jedwali S na mchoro B wenye jedwali S. Hoja - chagua data kutoka kwa jedwali. Tutakuwa na nini katika kesi hii? Tutakuwa na hitilafu. Tutakuwa na yote hapo juu. Sheria ni - mdudu ni kila mahali, tutakuwa na yote hapo juu.
Sasa swali ni: "Kwa nini?" Inaweza kuonekana kuwa kuna hati kwamba ikiwa tuna schema, basi kuna "search_path" tofauti ambayo inatuambia wapi kutafuta jedwali. Inaweza kuonekana kuwa kuna tofauti.
Shida ni nini? Shida ni kwamba taarifa zilizotayarishwa na seva hazishuku kuwa search_path inaweza kubadilishwa na mtu. Thamani hii inabaki thabiti kwa hifadhidata. Na sehemu zingine haziwezi kuchukua maana mpya.
Bila shaka, hii inategemea toleo ambalo unajaribu. Inategemea jinsi meza zako zinavyotofautiana sana. Na toleo la 9.1 litatekeleza tu maswali ya zamani. Matoleo mapya yanaweza kupata hitilafu na kukuambia kuwa una mdudu.
Jinsi ya kutibu? Kuna mapishi rahisi - usifanye. Hakuna haja ya kubadilisha search_path wakati programu inaendeshwa. Ukibadilisha, ni bora kuunda muunganisho mpya.
Unaweza kujadili, i.e. kufungua, kujadili, kuongeza. Labda tunaweza kuwashawishi watengenezaji wa hifadhidata kwamba mtu anapobadilisha thamani, hifadhidata inapaswa kumwambia mteja kuhusu hili: βAngalia, thamani yako imesasishwa hapa. Labda unahitaji kuweka upya taarifa na kuziunda upya?" Sasa hifadhidata inatenda kwa siri na hairipoti kwa njia yoyote kwamba taarifa zimebadilika mahali fulani ndani.
Na nitasisitiza tena - hii ni kitu ambacho sio kawaida kwa Java. Tutaona kitu kimoja katika PL/pgSQL moja hadi moja. Lakini itatolewa tena huko.
Hebu tujaribu uteuzi zaidi wa data. Tunachagua na kuchagua. Tuna meza yenye safu milioni. Kila mstari ni kilobyte. Takriban gigabyte ya data. Na tunayo kumbukumbu ya kufanya kazi katika mashine ya Java ya megabytes 128.
Sisi, kama inavyopendekezwa katika vitabu vyote, tunatumia usindikaji wa mtiririko. Hiyo ni, tunafungua resultSet na kusoma data kutoka hapo kidogo kidogo. Je, itafanya kazi? Itaanguka kutoka kwa kumbukumbu? Utasoma kidogo? Wacha tuamini hifadhidata, tuamini Postgres. hatuamini. Je, tutaanguka OutOFMemory? Nani alipitia OutOfMemory? Nani aliweza kurekebisha baada ya hapo? Mtu aliweza kuirekebisha.
Ikiwa una safu milioni moja, huwezi kuchagua na kuchagua. OFFSET/LIMIT inahitajika. Ni nani kwa chaguo hili? Na ni nani anayependelea kucheza na AutoCommit?
Hapa, kama kawaida, chaguo lisilotarajiwa linageuka kuwa sahihi. Na ikiwa utazima ghafla AutoCommit, itasaidia. Kwanini hivyo? Sayansi haijui kuhusu hili.
Lakini kwa chaguo-msingi, wateja wote wanaounganisha kwenye hifadhidata ya Postgres huchota data nzima. PgJDBC sio ubaguzi katika suala hili; huchagua safu mlalo zote.
Kuna tofauti kwenye mandhari ya FetchSize, i.e. unaweza kusema katika kiwango cha taarifa tofauti kwamba hapa, tafadhali chagua data kwa 10, 50. Lakini hii haifanyi kazi hadi uzime AutoCommit. Imezimwa AutoCommit - inaanza kufanya kazi.
Lakini kupitia nambari na kuweka setFetchSize kila mahali sio rahisi. Kwa hiyo, tulifanya mpangilio ambao utasema thamani ya chaguo-msingi ya muunganisho mzima.
Ndivyo tulivyosema. Kigezo kimesanidiwa. Na tulipata nini? Ikiwa tunachagua kiasi kidogo, ikiwa, kwa mfano, tunachagua safu 10 kwa wakati mmoja, basi tuna gharama kubwa sana za juu. Kwa hiyo, thamani hii inapaswa kuweka karibu mia moja.
Kwa hakika, bila shaka, bado unapaswa kujifunza jinsi ya kuipunguza kwa ka, lakini kichocheo ni hiki: weka defaultRowFetchSize kwa zaidi ya mia moja na uwe na furaha.
Wacha tuendelee kwenye kuingiza data. Kuingiza ni rahisi zaidi, kuna chaguzi tofauti. Kwa mfano, INGIZA, MAADILI. Hii ni chaguo nzuri. Unaweza kusema "INGIZA CHAGUA". Katika mazoezi ni kitu kimoja. Hakuna tofauti katika utendaji.
Vitabu vinasema kwamba unahitaji kutekeleza taarifa ya Kundi, vitabu vinasema kwamba unaweza kutekeleza amri ngumu zaidi na mabano kadhaa. Na Postgres ina sifa nzuri - unaweza kufanya COPY, i.e. ifanye haraka.
Ukiipima, unaweza tena kufanya uvumbuzi wa kuvutia. Tunataka hili lifanye kazi vipi? Hatutaki kuchanganua na sio kutekeleza amri zisizo za lazima.
Kwa mazoezi, TCP haituruhusu kufanya hivi. Ikiwa mteja yuko busy kutuma ombi, basi hifadhidata haisomi maombi katika majaribio ya kututumia majibu. Matokeo ya mwisho ni kwamba mteja anasubiri hifadhidata ili kusoma ombi, na hifadhidata inangojea mteja kusoma majibu.
Na kwa hiyo mteja analazimika kutuma mara kwa mara pakiti ya maingiliano. Mwingiliano wa ziada wa mtandao, upotezaji wa muda zaidi.
Na tunapowaongeza zaidi, ndivyo inavyozidi kuwa mbaya. Dereva hana tamaa kabisa na huwaongeza mara nyingi, karibu mara moja kila mistari 200, kulingana na saizi ya mistari, nk.
Inatokea kwamba unasahihisha mstari mmoja tu na kila kitu kitaharakisha mara 10. Inatokea. Kwa nini? Kama kawaida, mara kwa mara kama hii tayari imetumika mahali fulani. Na thamani "128" ilimaanisha kutotumia batching.
Ni vizuri kwamba hii haikujumuishwa katika toleo rasmi. Iligunduliwa kabla ya kutolewa kuanza. Maana zote ninazotoa zinatokana na matoleo ya kisasa.
Hebu tujaribu. Tunapima InsertBatch rahisi. Tunapima InsertBatch mara nyingi, yaani kitu kimoja, lakini kuna maadili mengi. Hoja gumu. Sio kila mtu anayeweza kufanya hivi, lakini ni hatua rahisi, rahisi zaidi kuliko COPY.
Unaweza kufanya COPY.
Na unaweza kufanya hivyo kwenye miundo. Tangaza aina chaguo-msingi ya Mtumiaji, pitisha safu na WEKA moja kwa moja kwenye jedwali.
Ukifungua kiungo: pgjdbc/ubenchmsrk/InsertBatch.java, basi msimbo huu uko kwenye GitHub. Unaweza kuona haswa ni maombi gani yanayotolewa hapo. Haijalishi.
Tulizindua. Na jambo la kwanza tulilogundua ni kwamba kutotumia kundi haiwezekani. Chaguo zote za batching ni sifuri, yaani, muda wa utekelezaji ni sifuri ikilinganishwa na utekelezaji wa mara moja.
Tunaingiza data. Ni meza rahisi sana. Safu tatu. Na tunaona nini hapa? Tunaona kwamba chaguzi hizi zote tatu ni takriban kulinganishwa. Na COPY ni, bila shaka, bora.
Hii ndio tunapoingiza vipande. Tuliposema kwamba thamani moja ya VALUES, thamani mbili za VALUES, thamani tatu za THAMANI, au tulionyesha 10 kati yao zikitenganishwa na koma. Hii ni mlalo tu sasa. 1, 2, 4, 128. Inaweza kuonekana kuwa Ingizo la Batch, ambalo limechorwa kwa bluu, linamfanya ahisi vizuri zaidi. Hiyo ni, unapoingiza moja kwa wakati mmoja au hata unapoingiza nne kwa wakati mmoja, inakuwa nzuri mara mbili, kwa sababu tu tulibandika zaidi kwenye THAMANI. Shughuli chache za EXECUTE.
Kutumia COPY kwenye juzuu ndogo ni jambo lisilo na matumaini sana. Sikuchora hata kwenye mbili za kwanza. Wanaenda mbinguni, yaani, nambari hizi za kijani kwa COPY.
NAKALA inapaswa kutumika wakati una angalau safu mia za data. Sehemu ya juu ya kufungua muunganisho huu ni kubwa. Na, kuwa waaminifu, sikuchimba katika mwelekeo huu. Niliboresha Kundi, lakini sio COPY.
Tufanye nini baadaye? Tulijaribu. Tunaelewa kwamba tunahitaji kutumia miundo au bacth ya werevu ambayo inachanganya maana kadhaa.
Je, unapaswa kuchukua nini kutoka kwa ripoti ya leo?
- PreparedStatement ndio kila kitu chetu. Hii inatoa mengi kwa tija. Inazalisha flop kubwa katika marashi.
- Na unahitaji kufanya EXPLAIN ANALYSE mara 6.
- Na tunahitaji kuongeza OFFSET 0, na mbinu kama +0 ili kusahihisha asilimia iliyobaki ya hoja zetu zenye matatizo.
Chanzo: mapenzi.com