, toleo jipya zaidi la "hifadhidata bora zaidi ya uhusiano wa chanzo huria duniani," itatoka baada ya wiki kadhaa (ikiwa yote yataenda kulingana na mpango). Hii inafuata ratiba ya kawaida ya kutoa toleo jipya lenye tani nyingi za vipengele vipya mara moja kwa mwaka, na kusema ukweli, hiyo inavutia. Ndio maana nikawa mwanachama hai wa jumuiya ya PostgreSQL.
Kwa maoni yangu, tofauti na matoleo ya awali, PostgreSQL 12 haina kipengele kimoja au viwili vya mapinduzi (kama kugawanya au usawa wa hoja). Niliwahi kutania kwamba kipengele kikuu cha PostgreSQL 12 ni utulivu mkubwa. Je, si ndivyo unavyohitaji unapodhibiti data muhimu ya biashara yako?
Lakini PostgreSQL 12 haiishii hapo: na huduma mpya na maboresho, programu zitafanya vizuri zaidi, na unachohitaji kufanya ni kuboresha!
(Sawa, labda ujenge upya faharasa, lakini katika toleo hili sio la kutisha kama tulivyozoea.)
Itakuwa vyema kuboresha PostgreSQL na kufurahia mara moja maboresho makubwa bila mizozo isiyo ya lazima. Miaka michache iliyopita, nilipitia uboreshaji kutoka PostgreSQL 9.4 hadi PostgreSQL 10 na nikaona jinsi maombi yalivyoharakisha shukrani kwa usawa wa swala ulioboreshwa katika PostgreSQL 10. Na, muhimu zaidi, karibu hakuna chochote kilichohitajika kutoka kwangu (weka tu parameta ya usanidi. max_parallel_workers).
Kubali, ni rahisi wakati programu zinafanya kazi vyema mara tu baada ya kusasisha. Na tunajaribu sana kuwafurahisha watumiaji, kwa sababu PostgreSQL ina zaidi na zaidi yao.
Kwa hivyo uboreshaji rahisi hadi PostgreSQL 12 unawezaje kukufurahisha? Nitakuambia sasa.
Maboresho makubwa ya faharasa
Bila kuorodhesha, hifadhidata haitaenda mbali. Unawezaje kupata habari haraka? Mfumo wa msingi wa kuorodhesha wa PostgreSQL unaitwa . Aina hii ya faharasa imeboreshwa kwa mifumo ya uhifadhi.
Tunatumia opereta tu CREATE INDEX ON some_table (some_column), na PostgreSQL hufanya kazi nyingi kusasisha faharasa huku tukiingiza, kusasisha na kufuta thamani kila mara. Kila kitu hufanya kazi peke yake, kana kwamba kwa uchawi.
Lakini faharisi za PostgreSQL zina shida moja - wao na kuchukua nafasi ya ziada ya diski na kupunguza utendakazi wa kurejesha na kusasisha data. Kwa "bloat" ninamaanisha kutodumisha muundo wa faharisi. Hii inaweza - au haiwezi - kuhusishwa na nakala za takataka ambazo huondoa (asante kwa Peter Gaghan kwa taarifa))). Upungufu wa index unaonekana hasa katika mizigo ya kazi ambapo faharisi inabadilika kikamilifu.
PostgreSQL 12 inaboresha sana utendakazi wa faharasa za miti B, na majaribio yaliyo na alama kama TPC-C yameonyesha kuwa kwa wastani nafasi ya chini ya 40% inatumika sasa. Sasa tunatumia muda mdogo sio tu kudumisha indexes za B-tree (yaani, kwenye shughuli za kuandika), lakini pia katika kurejesha data, kwa sababu indexes ni ndogo zaidi.
Programu zinazosasisha jedwali zao kikamilifu - kwa kawaida programu za OLTP () - itatumia diski na kusindika maombi kwa ufanisi zaidi. Kadiri nafasi ya diski inavyoongezeka, ndivyo hifadhidata inavyozidi kukua bila kuboresha miundombinu.
Baadhi ya mikakati ya kuboresha inahitaji kuunda upya faharasa za miti ya B ili kufaidika na manufaa haya (k.m. haitaunda tena faharisi kiotomatiki). Katika matoleo ya awali ya PostgreSQL, kuunda upya faharasa kubwa kwenye jedwali kulisababisha muda wa chini kwa sababu mabadiliko hayakuweza kufanywa wakati huo huo. Lakini PostgreSQL 12 ina huduma nyingine nzuri: sasa unaweza kuunda tena faharisi sambamba na amri. ili kuepuka kabisa wakati wa kupungua.
Kuna maboresho mengine ya miundombinu ya kuorodhesha katika PostgreSQL 12. Jambo lingine ambapo kulikuwa na uchawi - , aka WAL (logi ya kuandika-mbele). Rekodi ya kuandika-mbele hurekodi kila shughuli katika PostgreSQL iwapo itafeli na kurudiwa. Maombi huitumia kwa kuhifadhi na . Bila shaka, logi ya kuandika-mbele imeandikwa kwenye diski, ambayo inaweza kuathiri utendaji.
PostgreSQL 12 imepunguza upeo wa rekodi za WAL ambazo zinaundwa na faharasa za GiST, GIN, na SP-GiST wakati wa ujenzi wa faharasa. Hii hutoa manufaa kadhaa yanayoonekana: Rekodi za WAL huchukua nafasi ndogo ya diski, na data inachezwa tena kwa kasi zaidi, kama vile wakati wa kurejesha maafa au uokoaji wa moja kwa moja. Ikiwa unatumia faharasa kama hizi katika programu zako (kwa mfano, programu-tumizi za kijiografia zenye msingi wa PostGIS hutumia faharasa ya GiST sana), hiki ni kipengele kingine ambacho kitaboresha sana matumizi bila juhudi zozote kwa upande wako.
Kugawanya - kubwa, bora, haraka
PostgreSQL 10 ilianzishwa . Katika PostgreSQL 11 imekuwa rahisi zaidi kutumia. Katika PostgreSQL 12 unaweza kubadilisha kiwango cha sehemu.
Katika PostgreSQL 12, utendaji wa mfumo wa kugawa umekuwa bora zaidi, haswa ikiwa kuna maelfu ya sehemu kwenye jedwali. Kwa mfano, ikiwa swali linaathiri sehemu chache tu kwenye jedwali na maelfu yao, itatekelezwa haraka zaidi. Utendaji haujaboreshwa kwa aina hizi za maswali pekee. Pia utagundua jinsi shughuli za INSERT zilivyo haraka kwenye jedwali zilizo na sehemu nyingi.
Kurekodi data kwa kutumia - kwa njia, hii ni njia nzuri na hapa kuna mfano - Jedwali zilizogawanywa katika PostgreSQL 12 pia zimekuwa bora zaidi. Na COPY kila kitu kilikuwa tayari haraka, lakini katika PostgreSQL 12 inaruka kabisa.
Shukrani kwa faida hizi, PostgreSQL hukuruhusu kuhifadhi seti kubwa zaidi za data na kuzifanya rahisi kuzipata. Na hakuna juhudi kwa upande wako. Ikiwa programu ina sehemu nyingi, kama vile kurekodi data ya mfululizo wa saa, uboreshaji rahisi utaboresha utendaji wake kwa kiasi kikubwa.
Ingawa hii sio uboreshaji wa "sasisha na ufurahie", PostgreSQL 12 hukuruhusu kuunda funguo za kigeni ambazo hurejelea jedwali zilizogawanywa, na kufanya kugawanya kuwa raha kufanya kazi nao.
NA maswali imekuwa bora zaidi
Wakati (aka CTE, aka NA maswali), sikuweza kungoja kuandika nakala kuhusu . Hii ni moja ya vipengele ambavyo vitaharakisha programu. Isipokuwa, bila shaka, unatumia CTE.
Mara nyingi mimi huona kuwa wanaoanza kwa SQL wanapenda kutumia CTE; ukiziandika kwa njia fulani, inahisi kama unaandika programu muhimu. Binafsi, nilipenda kuandika tena maswali haya ili kuzunguka bila CTE na kuongeza tija. Sasa kila kitu ni tofauti.
PostgreSQL 12 hukuruhusu kuingiza aina maalum ya CTE bila athari mbaya (SELECT), ambayo hutumiwa mara moja tu karibu na mwisho wa ombi. Ikiwa ningefuatilia hoja za CTE nilizoandika upya, nyingi zingeangukia katika kitengo hiki. Hii husaidia wasanidi programu kuandika msimbo wazi ambao sasa pia unafanya kazi haraka.
Kwa kuongezea, PostgreSQL 12 inaboresha utekelezaji wa SQL yenyewe, bila wewe kufanya chochote. Na ingawa labda sitahitaji kuongeza maswali kama haya sasa, ni vizuri kwamba PostgreSQL inaendelea kufanya kazi katika uboreshaji wa hoja.
Tu-in-Time (JIT) - sasa chaguomsingi
Kwenye mifumo ya PostgreSQL 12 na usaidizi Mkusanyiko wa JIT umewezeshwa kwa chaguo-msingi. Kwanza kabisa, unapata msaada kwa baadhi ya shughuli za ndani, na pili, hoja zilizo na misemo (mfano rahisi zaidi ni x + y) katika orodha zilizochaguliwa (ambazo unazo baada ya SELECT), mkusanyiko, misemo yenye vifungu vya WHERE na zingine zinaweza kutumia JIT kuboresha utendakazi.
Kwa kuwa JIT imewezeshwa kwa chaguo-msingi katika PostgreSQL 12, utendaji utaboresha peke yake, lakini ninapendekeza kujaribu programu katika PostgreSQL 11, ambayo ilianzisha JIT, ili kupima utendaji wa hoja na kuona ikiwa unahitaji kurekebisha chochote.
Vipi kuhusu vipengee vingine vipya katika PostgreSQL 12?
PostgreSQL 12 ina tani ya vipengee vipya baridi, kutoka kwa uwezo wa kukagua data ya JSON kwa kutumia misemo ya kawaida ya njia ya SQL/JSON hadi uthibitishaji wa sababu nyingi na parameta. clientcert=verify-full, safu wima zilizoundwa na mengi zaidi. Inatosha kwa chapisho tofauti.
Kama PostgreSQL 10, PostgreSQL 12 itaboresha utendaji wa jumla mara tu baada ya kusasisha. Wewe, bila shaka, unaweza kuwa na njia yako mwenyewe - jaribu programu chini ya hali sawa kwenye mfumo wa uzalishaji kabla ya kuwezesha uboreshaji, kama nilivyofanya na PostgreSQL 10. Hata kama PostgreSQL 12 tayari ni thabiti zaidi kuliko nilivyotarajia, usiwe mvivu katika majaribio. maombi kikamilifu, kabla ya kuwatoa katika uzalishaji.
Chanzo: mapenzi.com