Tafsiri ya makala hiyo ilitayarishwa mahsusi kwa ajili ya wanafunzi wa kozi hiyo . Je, ungependa kuendeleza katika mwelekeo huu? Tunakualika , ambapo tunazungumza kwa undani kuhusu programu, vipengele vya muundo wa mtandaoni, uwezo na matarajio ya kazi ambayo yanasubiri wahitimu baada ya mafunzo.
PostgreSQL na mipangilio ya uthabiti wa uandishi wa muunganisho mahususi
Katika Compose, tunashughulika na hifadhidata nyingi, ambazo hutupa fursa ya kufahamiana zaidi na utendaji na mapungufu yao. Tunapojifunza kupenda vipengele vya hifadhidata mpya, wakati mwingine tunaanza kufikiria jinsi ingekuwa vyema ikiwa vipengele sawa vingekuwepo katika zana za watu wazima zaidi ambazo tumekuwa tukifanya nazo kazi kwa muda mrefu. Mojawapo ya huduma mpya ambayo nilitaka kuona katika PostgreSQL ilikuwa uthabiti wa uandishi unaoweza kusanidiwa kwa kila unganisho kwenye nguzo nzima. Na kama inavyogeuka, tayari tunayo, na leo tunataka kushiriki nawe habari juu ya jinsi unavyoweza kuitumia.
Kwa nini ninahitaji?
Jinsi nguzo inapaswa kuishi inategemea programu yako. Chukua, kwa mfano, programu ya malipo ya bili. Utahitaji uthabiti wa XNUMX% kwenye nguzo yote, kwa hivyo itabidi uwashe shughuli za kusawazisha ili hifadhidata yako isubiri mabadiliko yote kufanywa. Hata hivyo, ikiwa programu yako ni mtandao wa kijamii unaokua kwa kasi, basi pengine utapendelea majibu ya haraka zaidi ya uthabiti wa XNUMX%. Ili kufanikisha hili, unaweza kutumia ahadi za asynchronous kwenye nguzo yako.
Kutana na maelewano
Lazima ufanye biashara kati ya uthabiti wa data na utendaji. PostgreSQL inasogea mbali na uthabiti kwa sababu usanidi chaguo-msingi unaweza kutabirika na bila mshangao usiyotarajiwa. Sasa hebu tuangalie maelewano.
Tradeoff 1: Utendaji
Ikiwa nguzo ya PostgreSQL haihitaji uthabiti, inaweza kufanya kazi kwa usawa. Maandishi yanafanywa kwa kiongozi wa nguzo, na masasisho yatatumwa kwa nakala zake milisekunde chache baadaye. Wakati nguzo ya PostgreSQL inahitaji uthabiti, lazima iendeshe kwa usawazishaji. Maandishi yatafanywa kwa kiongozi wa nguzo, ambayo itatuma sasisho kwa nakala na kusubiri uthibitisho kwamba kila mmoja ameandika kabla ya kutuma uthibitisho kwa mteja aliyeanzisha kuandika kuwa imefanikiwa. Tofauti ya vitendo kati ya mbinu hizi ni kwamba njia ya asynchronous inahitaji hops mbili za mtandao, wakati njia ya synchronous inahitaji nne.
Tradeoff 2: Uthabiti
Matokeo katika tukio la kushindwa kwa kiongozi katika njia hizi mbili pia yatakuwa tofauti. Ikiwa kazi inafanywa kwa usawa, basi ikiwa hitilafu kama hiyo itatokea, sio rekodi zote zitafanywa na nakala. Kiasi gani kitapotea? Inategemea maombi yenyewe na ufanisi wa kurudia. Urudiaji wa utungaji utazuia nakala kutoka kuwa kiongozi ikiwa kiasi cha habari ndani yake ni MB 1 chini ya katika kiongozi, yaani, hadi MB 1 ya rekodi inaweza uwezekano wa kupotea wakati wa operesheni ya asynchronous.
Hii haifanyiki katika hali ya kusawazisha. Ikiwa kiongozi atashindwa, nakala zote zinasasishwa, kwani maandishi yoyote yaliyothibitishwa kwenye kiongozi lazima yathibitishwe kwenye nakala. Huu ni uthabiti.
Tabia ya Usawazishaji inaeleweka katika utumaji bili ambapo uthabiti una faida dhahiri katika ubadilishanaji kati ya uthabiti na utendakazi. Jambo muhimu zaidi kwa programu kama hiyo ni data halali. Sasa fikiria kuhusu mtandao wa kijamii ambao kazi kuu ni kuweka tahadhari ya mtumiaji kwa kujibu maombi haraka iwezekanavyo. Katika kesi hii, utendakazi ulio na mirumko michache ya mtandao na kusubiri kidogo kwa ahadi itakuwa kipaumbele. Walakini, biashara kati ya utendaji na uthabiti sio pekee ambayo unapaswa kufikiria.
Biashara ya 3: Kuacha kufanya kazi
Ni muhimu sana kuelewa jinsi nguzo inavyofanya wakati wa kushindwa. Fikiria hali ambapo nakala moja au zaidi zinashindwa. Wakati ahadi zinachakatwa kwa usawa, kiongozi ataendelea kufanya kazi, ambayo ni, kukubali na kuchakata kuandika, bila kungoja nakala zilizokosekana. Wakati nakala zinarudi kwenye nguzo, zinamshika kiongozi. Na urudufishaji wa kisawazishaji, ikiwa nakala hazijibu, basi kiongozi hatakuwa na chaguo na ataendelea kungoja uthibitisho wa ahadi hadi nakala irudi kwenye nguzo na iweze kukubali na kuandika maandishi.
Muunganisho mmoja kwa kila shughuli?
Kila programu inahitaji aina tofauti ya mchanganyiko wa uthabiti na utendaji. Isipokuwa, bila shaka, ni programu yetu ya kulipa bili, ambayo tunafikiria kuwa thabiti kabisa, au programu yetu ya mitandao ya kijamii inayokaribia muda mfupi tu. Katika visa vingine vyote, kutakuwa na wakati ambapo shughuli zingine lazima zisawazishe na zingine ziwe za asynchronous. Huenda usitake mfumo kusubiri hadi ujumbe uliotumwa kwenye gumzo utekelezwe, lakini ikiwa malipo yatachakatwa katika programu sawa, basi utahitaji kusubiri.
Maamuzi haya yote, bila shaka, yanafanywa na msanidi programu. Kufanya maamuzi sahihi kuhusu wakati wa kutumia kila mbinu kutakusaidia kupata manufaa zaidi kutoka kwa kundi lako. Ni muhimu kwamba msanidi programu anaweza kubadili kati yao katika kiwango cha SQL kwa miunganisho na kwa shughuli.
Kuhakikisha udhibiti katika mazoezi
Kwa chaguo-msingi, PostgreSQL hutoa uthabiti. Hii inadhibitiwa na parameta ya seva synchronous_commit. Kwa chaguo-msingi iko kwenye nafasi on, lakini ina chaguzi zingine tatu: local, remote_write au off.
Wakati wa kuweka parameter off ahadi zote za kusawazisha zimesimamishwa, hata kwenye mfumo wa ndani. Kigezo cha ndani kinabainisha hali ya upatanishi kwa mfumo wa ndani, lakini kuandika kwa nakala hufanywa kwa njia isiyo sawa. Remote_write huenda mbali zaidi: kuandika kwa nakala hufanywa kwa usawa, lakini hurejeshwa wakati nakala imekubali uandishi lakini haijaiandika kwa diski.
Kwa kuzingatia anuwai ya chaguzi zinazopatikana, tunachagua tabia na, kwa kuzingatia hilo on - hizi ni rekodi za synchronous, tutachagua local kwa ahadi za asynchronous kwenye mtandao, huku ukiacha shughuli za kawaida zikiwa sawa.
Sasa, tutakuambia jinsi ya kusanidi hii kwa muda mfupi, lakini fikiria kwamba tumeiweka synchronous_commit Π² local kwa seva. Tulijiuliza ikiwa inawezekana kubadilisha parameta synchronous_commit juu ya kuruka, na ikawa kwamba haiwezekani tu, kuna hata njia mbili za kufanya hivyo. Ya kwanza ni kuweka kikao cha unganisho lako kama ifuatavyo:
SET SESSION synchronous_commit TO ON;
// Your writes go hereMaandishi yote yanayofuata katika kipindi yatakubali maandishi kwa nakala kabla ya kurudisha matokeo chanya kwa mteja aliyeunganishwa. Isipokuwa bila shaka ubadilishe mpangilio synchronous_commit tena. Unaweza kuacha sehemu SESSION katika amri kwa sababu itakuwa katika thamani chaguo-msingi.
Njia ya pili ni nzuri unapotaka tu kuhakikisha unapata urudufishaji wa usawazishaji kwa muamala mmoja. Katika hifadhidata nyingi za kizazi cha NoSQL dhana ya shughuli haipo, lakini haipo katika PostgreSQL. Katika kesi hii, unaweza kuanza shughuli na kisha kuweka synchronous_commit Π² on kabla ya kutekeleza kiingilio cha muamala. COMMIT itafanya muamala kwa kutumia thamani yoyote ya kigezo synchronous_commit, ambayo iliwekwa wakati huo, ingawa ni bora kuweka utaftaji wa mbele ili kuhakikisha kuwa watengenezaji wengine wanaelewa kuwa uandishi sio sawa.
BEGIN;
SET LOCAL synchronous_commit TO ON;
// Your writes go here
COMMIT; Ahadi zote za miamala sasa zitathibitishwa kama zimeandikwa kwa nakala kabla hifadhidata kurudisha jibu chanya kwa mteja aliyeunganishwa.
Kuanzisha PostgreSQL
Kabla ya hii, tulifikiria mfumo wa PostgreSQL na synchronous_commit, imewekwa ndani local. Ili kufanya hili kuwa la kweli kwa upande wa seva, utahitaji kuweka chaguo mbili za usanidi wa seva. Kigezo kimoja zaidi synchronous_standby_names itakuja yenyewe lini synchronous_commit itakuwa ndani on. Huamua ni nakala zipi zinazostahiki majukumu ya kusawazisha, na tutaiweka *, ambayo itamaanisha kuwa nakala zote zinahusika. Thamani hizi kawaida husanidiwa ndani kwa kuongeza:
synchronous_commit = local
synchronous_standby_names='*'Kwa kuweka parameter synchronous_commit kwenye maana local, tunaunda mfumo ambapo diski za ndani zinasalia kuwa sawa, lakini ahadi za nakala za mtandao hazifanani na chaguo-msingi. Isipokuwa, kwa kweli, tunaamua kufanya shughuli hizi zisawazishe, kama inavyoonyeshwa hapo juu.
Ikiwa umekuwa ukifuatilia maendeleo , huenda umeona mabadiliko fulani ya hivi majuzi (, ), ambayo iliruhusu watumiaji wa Gavana kujaribu vigezo hivi na kufuatilia uthabiti wao.
Maneno machache zaidi...
Wiki moja tu iliyopita, ningekuambia kuwa haiwezekani kusawazisha PostgreSQL vizuri sana. Hapo ndipo Kurt, mwanachama wa timu ya jukwaa la Compose, alisisitiza kuwa fursa kama hiyo ipo. Alituliza pingamizi langu na akapata katika hati za PostgreSQL :
Mpangilio huu unaweza kubadilishwa wakati wowote. Tabia ya muamala wowote inaamuliwa na mpangilio unaotumika wakati wa ahadi. Kwa hivyo, inawezekana na muhimu kwa shughuli zingine kufanya kwa usawazishaji na kwa zingine kwa usawa. Kwa mfano, kulazimisha moja multistatement muamala wa kufanya hutenda kwa usawa wakati thamani chaguo-msingi ya parameta iko kinyume, weka SET LOCAL synchronous_commit TO OFF katika shughuli.
Kwa urekebishaji huu mdogo kwenye faili ya usanidi, tuliwapa watumiaji udhibiti wa uthabiti na utendakazi wao.
Chanzo: mapenzi.com