Paratowyd y cyfieithiad o'r erthygl yn benodol ar gyfer myfyrwyr y cwrs . Diddordeb mewn datblygu i'r cyfeiriad hwn? Rydym yn eich gwahodd i , lle rydym yn siarad yn fanwl am y rhaglen, nodweddion y fformat ar-lein, cymwyseddau a rhagolygon gyrfa sy'n aros am raddedigion ar ôl hyfforddiant.
PostgreSQL a gosodiadau cysondeb ysgrifennu cysylltiad-benodol
Yn Compose, rydym yn delio â llawer o gronfeydd data, sy'n rhoi cyfle i ni ddod yn fwy cyfarwydd â'u swyddogaethau a'u diffygion. Wrth i ni ddysgu caru nodweddion cronfeydd data newydd, rydyn ni weithiau'n dechrau meddwl pa mor braf fyddai hi pe bai nodweddion tebyg yn bresennol yn yr offer mwy aeddfed rydyn ni wedi bod yn gweithio gyda nhw ers amser maith. Un o'r nodweddion newydd yr oeddwn am ei weld yn PostgreSQL oedd cysondeb ysgrifennu ffurfweddadwy fesul cysylltiad ar draws y clwstwr cyfan. Ac fel mae'n digwydd, mae gennym ni eisoes, a heddiw rydyn ni am rannu gwybodaeth â chi ar sut y gallwch chi ei ddefnyddio.
Pam fod ei angen arnaf?
Mae sut y dylai'r clwstwr ymddwyn yn dibynnu ar eich cais. Cymerwch, er enghraifft, ap talu biliau. Bydd angen XNUMX% o gysondeb ar draws y clwstwr, felly bydd yn rhaid i chi alluogi ymrwymiadau cydamserol fel bod eich cronfa ddata yn aros i bob newid gael ei wneud. Fodd bynnag, os yw'ch cais yn rhwydwaith cymdeithasol sy'n tyfu'n gyflym, yna mae'n debyg y bydd yn well gennych ymateb cyflym dros gysondeb XNUMX%. I gyflawni hyn, gallwch ddefnyddio ymrwymiadau asyncronaidd yn eich clwstwr.
Cyfarfod cyfaddawd
Mae'n rhaid i chi wneud cyfaddawdau rhwng cysondeb data a pherfformiad. Mae PostgreSQL yn symud i ffwrdd o gysondeb oherwydd bod y cyfluniad diofyn wedyn yn rhagweladwy a heb bethau annisgwyl annisgwyl. Nawr gadewch i ni edrych ar y cyfaddawdau.
Tradeoff 1: Perfformiad
Os nad oes angen cysondeb ar y clwstwr PostgreSQL, gall redeg yn asyncronig. Anfonir yr ysgrifen at arweinydd y clwstwr, a bydd diweddariadau'n cael eu hanfon at ei atgynyrchiadau ychydig filieiliadau yn ddiweddarach. Pan fydd angen cysondeb ar glwstwr PostgreSQL, rhaid iddo redeg yn gydamserol. Bydd yr ysgrifen yn cael ei wneud i arweinydd y clwstwr, a fydd yn anfon diweddariad i'r atgynyrchiadau ac yn aros am gadarnhad bod pob un wedi ysgrifennu cyn anfon cadarnhad at y cleient a gychwynnodd yr ysgrifennu ei fod yn llwyddiannus. Y gwahaniaeth ymarferol rhwng y dulliau hyn yw bod angen dwy hopys rhwydwaith ar y dull asyncronig, tra bod angen pedwar hopys ar y dull cydamserol.
Tradeoff 2: Cysondeb
Bydd y canlyniad os bydd arweinydd yn methu yn y ddau ddull hyn hefyd yn wahanol. Os yw'r gwaith yn cael ei wneud yn anghydamserol, yna os bydd gwall o'r fath, ni fydd pob cofnod yn cael ei gyflawni gan y copïau. Faint fydd yn cael ei golli? Yn dibynnu ar y cais ei hun ac effeithlonrwydd y dyblygu. Bydd cyfansoddi atgynhyrchu yn atal replica rhag dod yn arweinydd os yw faint o wybodaeth sydd ynddo 1 MB yn llai nag yn yr arweinydd, hynny yw, gallai hyd at 1 MB o gofnodion gael eu colli yn ystod gweithrediad asyncronig.
Nid yw hyn yn digwydd yn y modd cydamserol. Os bydd yr arweinydd yn methu, caiff pob copi ei ddiweddaru, gan fod yn rhaid cadarnhau unrhyw ysgrifen a gadarnheir ar yr arweinydd ar y copïau. Mae hyn yn gysondeb.
Mae ymddygiad cydamserol yn gwneud synnwyr mewn cais am daliad bil lle mae gan gysondeb fantais amlwg yn y cyfaddawd rhwng cysondeb a pherfformiad. Y peth pwysicaf ar gyfer cais o'r fath yw data dilys. Nawr meddyliwch am rwydwaith cymdeithasol lle mai'r brif dasg yw cadw sylw'r defnyddiwr trwy ymateb i geisiadau cyn gynted â phosibl. Yn yr achos hwn, bydd perfformiad gyda llai o hopys rhwydwaith a llai o aros am ymrwymiadau yn flaenoriaeth. Fodd bynnag, nid y cyfaddawd rhwng perfformiad a chysondeb yw'r unig un y mae'n rhaid i chi feddwl amdano.
Cyfaddawd 3: Damweiniau
Mae'n bwysig iawn deall sut mae clwstwr yn ymddwyn yn ystod methiant. Ystyriwch sefyllfa lle mae un neu fwy o gopïau yn methu. Pan fydd ymrwymiadau'n cael eu prosesu'n anghydamserol, bydd yr arweinydd yn parhau i weithredu, hynny yw, derbyn a phrosesu yn ysgrifennu, heb aros am gopïau coll. Pan fydd y copïau yn dychwelyd i'r clwstwr, maent yn dal i fyny gyda'r arweinydd. Gyda dyblygu cydamserol, os nad yw'r atgynyrchiadau'n ymateb, yna ni fydd gan yr arweinydd unrhyw ddewis a bydd yn parhau i aros am gadarnhad ymrwymo nes bod y replica yn dychwelyd i'r clwstwr ac yn gallu derbyn ac ymrwymo'r ysgrifen.
Un cysylltiad fesul trafodiad?
Mae angen math gwahanol o gyfuniad o gysondeb a pherfformiad ar bob cais. Oni bai, wrth gwrs, mai hwn yw ein ap talu biliau, yr ydym yn dychmygu ei fod yn gwbl gyson, neu ein app rhwydweithio cymdeithasol bron yn fyrhoedlog. Ym mhob achos arall, bydd adegau pan fydd yn rhaid i rai llawdriniaethau fod yn gydamserol a rhai yn anghydamserol. Efallai na fyddwch am i'r system aros nes bod neges a anfonwyd at y sgwrs wedi'i hymrwymo, ond os caiff taliad ei brosesu yn yr un cais, yna bydd yn rhaid i chi aros.
Mae'r holl benderfyniadau hyn, wrth gwrs, yn cael eu gwneud gan ddatblygwr y cais. Bydd gwneud y penderfyniadau cywir ynghylch pryd i ddefnyddio pob dull yn eich helpu i gael y gorau o'ch clwstwr. Mae'n bwysig bod y datblygwr yn gallu newid rhyngddynt ar lefel SQL ar gyfer cysylltiadau ac ar gyfer trafodion.
Sicrhau rheolaeth ymarferol
Yn ddiofyn, mae PostgreSQL yn darparu cysondeb. Mae hyn yn cael ei reoli gan baramedr y gweinydd synchronous_commit. Yn ddiofyn mae yn ei le on, ond mae ganddo dri opsiwn arall: local, remote_write neu off.
Wrth osod y paramedr i off mae pob ymrwymiad cydamserol yn cael ei atal, hyd yn oed ar y system leol. Mae'r paramedr lleol yn pennu modd cydamserol ar gyfer y system leol, ond yn ysgrifennu at replicas yn cael eu perfformio'n asyncronig. Remote_write yn mynd hyd yn oed ymhellach: yn ysgrifennu at atgynyrchiadau yn cael eu gwneud yn asyncronig, ond yn cael eu dychwelyd pan fydd y replica wedi derbyn yr ysgrifen ond heb ei ysgrifennu i ddisg.
Drwy ystyried yr ystod o opsiynau sydd ar gael, rydym yn dewis ymddygiad a chan gadw hynny mewn cof on – mae'r rhain yn recordiadau cydamserol, byddwn yn dewis local ar gyfer ymrwymiadau asyncronaidd dros y rhwydwaith, tra'n gadael ymrwymiadau lleol yn gydamserol.
Nawr, byddwn yn dweud wrthych sut i sefydlu hyn mewn eiliad, ond dychmygwch ein bod yn sefydlu synchronous_commit в local ar gyfer y gweinydd. Roeddem yn meddwl tybed a oedd yn bosibl newid y paramedr synchronous_commit ar y hedfan, ac mae'n troi allan ei fod nid yn unig yn bosibl, mae hyd yn oed dwy ffordd i wneud hyn. Y cyntaf yw gosod sesiwn eich cysylltiad fel a ganlyn:
SET SESSION synchronous_commit TO ON;
// Your writes go hereBydd pob ysgrifen ddilynol yn y sesiwn yn cydnabod ysgrifennu at y copïau cyn dychwelyd canlyniad cadarnhaol i'r cleient cysylltiedig. Oni bai wrth gwrs eich bod yn newid y gosodiad synchronous_commit eto. Gallwch hepgor rhan SESSION yn y gorchymyn oherwydd bydd yn y gwerth rhagosodedig.
Mae'r ail ddull yn dda pan fyddwch chi eisiau sicrhau eich bod chi'n cael atgynhyrchu cydamserol ar gyfer un trafodiad. Mewn llawer o gronfeydd data cenhedlaeth NoSQL nid yw'r cysyniad o drafodion yn bodoli, ond mae'n bodoli yn PostgreSQL. Yn yr achos hwn byddwch yn dechrau trafodiad ac yna gosod synchronous_commit в on cyn gweithredu cofnod ar gyfer trafodiad. COMMIT yn ymrwymo'r trafodiad gan ddefnyddio unrhyw werth paramedr synchronous_commit, a osodwyd ar y pryd, er ei bod yn well gosod y newidyn ymlaen llaw i sicrhau bod datblygwyr eraill yn deall nad yw ysgrifenniadau yn anghydamserol.
BEGIN;
SET LOCAL synchronous_commit TO ON;
// Your writes go here
COMMIT; Bydd yr holl ymrwymiadau trafodion yn awr yn cael eu cadarnhau fel rhai a ysgrifennwyd i atgynyrchiadau cyn i'r gronfa ddata ddychwelyd ymateb cadarnhaol i'r cleient cysylltiedig.
Sefydlu PostgreSQL
Cyn hyn, fe wnaethon ni ddychmygu system PostgreSQL gyda synchronous_commit, gosod yn local. I wneud hyn yn realistig ar ochr y gweinydd, bydd angen i chi osod dau opsiwn cyfluniad gweinydd. Un paramedr arall synchronous_standby_names bydd yn dod i mewn i'w hun pan synchronous_commit Bydd on. Mae'n pennu pa atgynyrchiadau sy'n gymwys ar gyfer ymrwymiadau cydamserol, a byddwn yn ei osod i *, a fydd yn golygu bod pob atgynhyrchiad yn gysylltiedig. Mae'r gwerthoedd hyn fel arfer wedi'u ffurfweddu i mewn trwy ychwanegu:
synchronous_commit = local
synchronous_standby_names='*'Trwy osod y paramedr synchronous_commit i mewn i ystyr local, rydym yn creu system lle mae disgiau lleol yn parhau i fod yn gydamserol, ond mae replica rhwydwaith ymrwymo yn asyncronaidd yn ddiofyn. Oni bai, wrth gwrs, ein bod yn penderfynu gwneud yr ymrwymiadau hyn yn gydamserol, fel y dangosir uchod.
Os ydych wedi bod yn dilyn y datblygiad , efallai eich bod wedi sylwi ar rai newidiadau diweddar (, ), a oedd yn caniatáu i ddefnyddwyr Llywodraethwyr brofi'r paramedrau hyn a monitro eu cysondeb.
Ychydig mwy o eiriau...
Dim ond wythnos yn ôl, byddwn wedi dweud wrthych ei bod yn amhosibl mireinio PostgreSQL mor fân. Dyna pryd y mynnodd Kurt, aelod o dîm platfform Compose, fod cyfle o'r fath yn bodoli. Tawelodd fy ngwrthwynebiadau a chanfod yn nogfennaeth PostgreSQL :
Gellir newid y gosodiad hwn unrhyw bryd. Mae'r ymddygiad ar gyfer unrhyw drafodiad yn cael ei bennu gan y gosodiad a oedd mewn grym ar adeg ymrwymo. Felly, mae'n bosibl ac yn ddefnyddiol i rai trafodion ymrwymo'n gydamserol ac i eraill yn anghydamserol. Er enghraifft, i orfodi un multistatement trafodiad i wneud yn ymrwymo asynchronously pan fydd gwerth diofyn y paramedr gyferbyn, gosod SET LOCAL synchronous_commit TO OFF mewn trafodiad.
Gyda'r addasiad bach hwn i'r ffeil ffurfweddu, rhoesom reolaeth i ddefnyddwyr dros eu cysondeb a'u perfformiad.
Ffynhonnell: hab.com