Die vertaling van die artikel is spesifiek vir die studente van die kursus voorberei . Stel u belang om in hierdie rigting te ontwikkel? Ons nooi jou uit om , waar ons in detail praat oor die program, kenmerke van die aanlyn-formaat, bevoegdhede en loopbaanvooruitsigte wat na opleiding op gegradueerdes wag.
PostgreSQL en verbindingspesifieke skryfkonsekwentheidinstellings
By Compose het ons te doen met baie databasisse, wat ons die geleentheid bied om meer vertroud te raak met hul funksionaliteit en tekortkominge. Soos ons leer om die kenmerke van nuwe databasisse lief te hê, begin ons soms dink hoe lekker dit sou wees as soortgelyke kenmerke teenwoordig was in die meer volwasse nutsgoed waarmee ons al lank gewerk het. Een van die nuwe kenmerke wat ek in PostgreSQL wou sien, was konfigureerbare skryfkonsekwentheid per verbinding oor die hele groep. En soos dit blyk, het ons dit reeds, en vandag wil ons inligting met jou deel oor hoe jy dit kan gebruik.
Hoekom het ek dit nodig?
Hoe die groep moet optree hang af van jou toepassing. Neem byvoorbeeld 'n rekeningbetaling-toepassing. Jy sal XNUMX% konsekwentheid oor die hele groep nodig hê, so jy sal sinchroniese commits moet aktiveer sodat jou databasis wag vir alle veranderinge om gemaak te word. As u toepassing egter 'n vinnig groeiende sosiale netwerk is, sal u waarskynlik vinnige reaksie bo XNUMX% konsekwentheid verkies. Om dit te bereik, kan jy asynchrone commits in jou groepering gebruik.
Ontmoet kompromie
U moet afwegings maak tussen datakonsekwentheid en prestasie. PostgreSQL beweeg weg van konsekwentheid omdat die verstekkonfigurasie dan voorspelbaar is en sonder onverwagte verrassings. Kom ons kyk nou na die kompromieë.
Afweging 1: Prestasie
As die PostgreSQL-kluster nie konsekwentheid benodig nie, kan dit asynchroon loop. Die skrywe word aan die groepleier gemaak, en opdaterings sal 'n paar millisekondes later na sy replikas gestuur word. Wanneer 'n PostgreSQL-kluster konsekwentheid vereis, moet dit sinchronies loop. Die skrywe sal aan die groepleier gemaak word, wat 'n opdatering na die replikas sal stuur en wag vir bevestiging dat elkeen geskryf het voordat bevestiging gestuur word aan die kliënt wat die skrywe geïnisieer het dat dit suksesvol was. Die praktiese verskil tussen hierdie benaderings is dat die asinchroniese metode twee netwerk hops vereis, terwyl die sinchrone metode vier vereis.
Afweging 2: Konsekwentheid
Die resultaat in die geval van 'n leiermislukking in hierdie twee benaderings sal ook anders wees. As die werk asinchroon uitgevoer word, sal nie alle rekords deur die replikas gepleeg word as so 'n fout voorkom nie. Hoeveel sal verlore gaan? Hang af van die toepassing self en die doeltreffendheid van replikasie. Compose-replikasie sal verhoed dat 'n replika 'n leier word as die hoeveelheid inligting daarin 1 MB minder is as in die leier, dit wil sê, tot 1 MB rekords kan moontlik verlore gaan tydens asinchroniese werking.
Dit gebeur nie in sinchroniese modus nie. As die leier misluk, word alle replikas opgedateer, aangesien enige skrywe wat op die leier bevestig word, op die replikas bevestig moet word. Dit is konsekwentheid.
Sinchroniese gedrag maak sin in 'n faktuurtoepassing waar konsekwentheid 'n duidelike voordeel het in die afweging tussen konsekwentheid en prestasie. Die belangrikste ding vir so 'n toepassing is geldige data. Dink nou aan 'n sosiale netwerk waarin die hooftaak is om die gebruiker se aandag te hou deur so vinnig as moontlik op versoeke te reageer. In hierdie geval sal prestasie met minder netwerk hops en minder wag vir commits 'n prioriteit wees. Die kompromis tussen prestasie en konsekwentheid is egter nie die enigste een waaraan jy moet dink nie.
Afruil 3: Ineenstortings
Dit is baie belangrik om te verstaan hoe 'n groep optree tydens 'n mislukking. Oorweeg 'n situasie waar een of meer replikas misluk. Wanneer commits asynchronies verwerk word, sal die leier voortgaan om te funksioneer, dit wil sê, skryfwerk aanvaar en verwerk, sonder om te wag vir ontbrekende replikas. Wanneer die replikas na die groep terugkeer, haal hulle die leier in. Met sinchrone replikasie, as die replikas nie reageer nie, sal die leier geen keuse hê nie en sal voortgaan om te wag vir bevestiging van die bevestiging totdat die replika na die groep terugkeer en die skryf kan aanvaar en uitvoer.
Een verbinding per transaksie?
Elke toepassing benodig 'n ander tipe kombinasie van konsekwentheid en werkverrigting. Tensy dit natuurlik ons rekeningbetalende toepassing is, wat ons ons voorstel dat dit heeltemal konsekwent is, of ons amper kortstondige sosiale netwerktoepassing. In alle ander gevalle sal daar tye wees wanneer sommige bewerkings sinchronies moet wees en sommige asinchronies moet wees. Jy sal dalk nie wil hê dat die stelsel moet wag totdat 'n boodskap wat na die klets gestuur word, gepleeg is nie, maar as 'n betaling in dieselfde toepassing verwerk word, sal jy moet wag.
Al hierdie besluite word natuurlik deur die toepassingsontwikkelaar geneem. Om die regte besluite te neem oor wanneer om elke benadering te gebruik, sal jou help om die meeste uit jou groepering te kry. Dit is belangrik dat die ontwikkelaar tussen hulle kan wissel op die SQL-vlak vir verbindings en vir transaksies.
Verseker beheer in die praktyk
PostgreSQL bied by verstek konsekwentheid. Dit word beheer deur die bedienerparameter synchronous_commit. By verstek is dit in posisie on, maar dit het drie ander opsies: local, remote_write of off.
Wanneer die parameter opgestel word off alle sinchrone commits word gestop, selfs op die plaaslike stelsel. Die plaaslike parameter spesifiseer sinchrone modus vir die plaaslike stelsel, maar skryf na replikas word asinchronies uitgevoer. Remote_write gaan selfs verder: skryfwerk na replikas word asinchroon gemaak, maar word teruggestuur wanneer die replika die skryf aanvaar het maar dit nie op skyf geskryf het nie.
Deur die beskikbare reeks opsies te oorweeg, kies ons 'n gedrag en hou dit in gedagte on – dit is sinchroniese opnames, ons sal kies local vir asynchrone commits oor die netwerk, terwyl plaaslike commits sinchronies gelaat word.
Nou, ons sal jou binne 'n oomblik vertel hoe om dit op te stel, maar stel jou voor dat ons dit opstel synchronous_commit в local vir die bediener. Ons het gewonder of dit moontlik is om die parameter te verander synchronous_commit op die vlieg, en dit het geblyk dat dit nie net moontlik is nie, daar is selfs twee maniere om dit te doen. Die eerste is om die sessie van jou verbinding soos volg in te stel:
SET SESSION synchronous_commit TO ON;
// Your writes go hereAlle daaropvolgende skrywes in die sessie sal skrywes aan die replikas erken voordat 'n positiewe resultaat aan die gekoppelde kliënt teruggestuur word. Tensy jy natuurlik die instelling verander synchronous_commit weer. Jy kan deel weglaat SESSION in die opdrag, want dit sal in die verstekwaarde wees.
Die tweede metode is goed as jy net wil seker maak dat jy sinchrone replikasie vir 'n enkele transaksie kry. In baie NoSQL generasie databasisse bestaan die konsep van transaksies nie, maar wel in PostgreSQL. In hierdie geval begin jy 'n transaksie en stel dan synchronous_commit в on voordat die inskrywing vir die transaksie uitgevoer word. COMMIT sal die transaksie pleeg deur enige parameterwaarde te gebruik synchronous_commit, wat destyds ingestel is, alhoewel dit die beste is om die veranderlike vooraf in te stel om seker te maak dat ander ontwikkelaars verstaan dat skryfwerk nie asynchronies is nie.
BEGIN;
SET LOCAL synchronous_commit TO ON;
// Your writes go here
COMMIT; Alle transaksieverbintenisse sal nou bevestig word as geskryf na replikas voordat die databasis 'n positiewe reaksie aan die gekoppelde kliënt gee.
Konfigureer PostgreSQL
Voor dit het ons 'n PostgreSQL-stelsel voorgestel met synchronous_commit, geïnstalleer in local. Om dit realisties aan die bedienerkant te maak, sal u twee bedienerkonfigurasie-opsies moet stel. Nog 'n parameter synchronous_standby_names sal tot sy reg kom wanneer synchronous_commit sal in wees on. Dit bepaal watter replikas vir sinchrone commits in aanmerking kom, en ons sal dit instel *, wat sal beteken dat alle replikas betrokke is. Hierdie waardes word gewoonlik gekonfigureer in deur by te voeg:
synchronous_commit = local
synchronous_standby_names='*'Deur die parameter te stel synchronous_commit tot betekenis local, skep ons 'n stelsel waar plaaslike skywe sinchronies bly, maar netwerk replika commits is by verstek asinchronies. Tensy ons natuurlik besluit om hierdie commits sinchronies te maak, soos hierbo getoon.
As jy die ontwikkeling gevolg het , jy het dalk 'n paar onlangse veranderinge opgemerk (, ), wat goewerneurgebruikers toegelaat het om hierdie parameters te toets en hul konsekwentheid te monitor.
Nog 'n paar woorde...
Net 'n week gelede sou ek vir jou gesê het dat dit onmoontlik is om PostgreSQL so fyn te verfyn. Dit is toe dat Kurt, 'n lid van die Compose-platformspan, daarop aangedring het dat so 'n geleentheid bestaan. Hy het my besware kalmeer en in die PostgreSQL-dokumentasie gevind :
Hierdie instelling kan enige tyd verander word. Die gedrag vir enige transaksie word bepaal deur die instelling wat in werking was ten tyde van die pleging. Daarom is dit moontlik en nuttig vir sommige transaksies om sinchroon te verbind en vir ander asinchroon. Byvoorbeeld, om een te dwing multistatement transaksie om commits asynchronies te maak wanneer die verstekwaarde van die parameter teenoorgestelde is, stel SET LOCAL synchronous_commit TO OFF in 'n transaksie.
Met hierdie klein wysiging aan die konfigurasielêer het ons gebruikers beheer gegee oor hul konsekwentheid en werkverrigting.
Bron: will.com