D'Iwwersetzung vum Artikel gouf speziell fir d'Schüler vum Cours virbereet "Datebank". Interesséiert an dëser Richtung ze entwéckelen? Mir invitéieren Iech op Porte Ouverte, wou mir am Detail iwwert de Programm schwätzen, Fonctiounen vun der online Format, Kompetenzen a Carrière Perspektiven datt Graduéierter nom Training waarden.

PostgreSQL a Verbindungsspezifesch Schreifkonsistenz Astellunge
Bei Compose këmmere mir eis mat villen Datenbanken, wat eis d'Méiglechkeet gëtt méi mat hirer Funktionalitéit a Mängel vertraut ze ginn. Wéi mir léieren d'Features vun neien Datenbanken gär ze hunn, fänken mir heiansdo un ze denken wéi flott et wier wann ähnlech Feature präsent wieren an de méi reife Tools mat deenen mir scho laang geschafft hunn. Ee vun den neie Funktiounen, déi ech an PostgreSQL gesinn wollt, war konfiguréierbar Schreifkonsistenz fir eng Verbindung iwwer de ganze Cluster. A wéi et sech erausstellt, hu mir et schonn, an haut wëlle mir Iech Informatioun deelen iwwer wéi Dir se benotze kënnt.

Firwat brauch ech et?

Wéi de Cluster sech soll behuelen hänkt vun Ärer Applikatioun of. Huelt zum Beispill eng Rechnungsbezuelung App. Dir braucht XNUMX% Konsistenz am ganze Stärekoup, also musst Dir synchron Verpflichtungen aktivéieren fir datt Är Datebank op all Ännerunge waart. Wéi och ëmmer, wann Är Uwendung e séier wuessend sozialt Netzwierk ass, da wäert Dir wahrscheinlech séier Äntwert iwwer XNUMX% Konsistenz léiwer maachen. Fir dëst z'erreechen, kënnt Dir asynchrone Verpflichtungen an Ärem Cluster benotzen.

Treffen Kompromiss

Dir musst Austausch tëscht Datenkonsistenz a Leeschtung maachen. PostgreSQL bewegt sech vun der Konsequenz ewech well d'Standardkonfiguratioun dann prévisibel ass an ouni onerwaart Iwwerraschungen. Loosst eis elo d'Kompromitte kucken.

Tradeoff 1: Leeschtung

Wann de PostgreSQL Cluster keng Konsistenz erfuerdert, kann et asynchron lafen. D'Schreiwen gëtt un de Stärekoup Leader gemaach, an d'Aktualiséierunge ginn e puer Millisekonnen méi spéit op seng Repliken geschéckt. Wann e PostgreSQL Cluster Konsistenz erfuerdert, muss et synchron lafen. D'Schreiwen gëtt un de Cluster Leader gemaach, deen en Update un d'Repliken schéckt a waart op d'Bestätegung datt jidderee geschriwwen huet ier Dir d'Bestätegung un de Client schéckt, deen d'Schreiwen initiéiert huet datt et erfollegräich war. De prakteschen Ënnerscheed tëscht dësen Approche ass datt d'asynchron Method zwee Netzhopsen erfuerdert, während déi synchron Method véier erfuerdert.

Tradeoff 2: Konsistenz

D'Resultat am Fall vun engem Leader Echec an dësen zwou Approche wäert och anescht ginn. Wann d'Aarbecht asynchron duerchgefouert gëtt, dann, wann esou e Feeler geschitt ass, ginn net all Opzeechnunge vun de Repliken engagéiert. Wéi vill wäert verluer goen? Hänkt vun der Applikatioun selwer an der Effizienz vun der Replikatioun of. Compose Replikatioun verhënnert datt eng Replika Leader gëtt wann d'Quantitéit vun Informatioun dran 1 MB manner ass wéi am Leader, dat ass, bis zu 1 MB Rekorder kënne potenziell während asynchroner Operatioun verluer ginn.

Dëst geschitt net am Synchronmodus. Wann de Leader feelt, ginn all Repliken aktualiséiert, well all Schreiwen, déi op de Leader bestätegt gëtt, muss op de Repliken bestätegt ginn. Dëst ass Konsequenz.

Synchron Verhalen mécht Sënn an enger Rechnungsapplikatioun wou Konsistenz e klore Virdeel am Austausch tëscht Konsistenz a Leeschtung huet. Déi wichtegst Saach fir sou eng Applikatioun ass valabel Donnéeën. Denkt elo un e sozialen Netzwierk an deem d'Haaptaufgab ass d'Opmierksamkeet vum Benotzer ze halen andeems Dir op Ufroe sou séier wéi méiglech reagéiert. An dësem Fall wäert Leeschtung mat manner Reseau hopsen a manner wait fir engagéiert eng Prioritéit ginn. Wéi och ëmmer, den Ofwiessel tëscht Leeschtung a Konsistenz ass net deen eenzegen iwwer deen Dir musst denken.

Ofwiesselung 3: Crashen

Et ass ganz wichteg ze verstoen wéi e Stärekoup sech während engem Echec behält. Betruecht eng Situatioun wou een oder méi Repliken versoen. Wann d'Verpflichtungen asynchron veraarbecht ginn, wäert de Leader weider funktionnéieren, dat heescht, akzeptéieren a veraarbecht schreift, ouni op fehlend Repliken ze waarden. Wann d'Repliken an de Stärekoup zréckkommen, fänken se de Leader op. Mat synchroner Replikatioun, wann d'Replikaen net äntweren, da wäert de Leader keng Wiel hunn a wäert weiderhin op d'Bestätegung vun der Verpflichtung waarden bis d'Replique zréck an de Cluster kënnt a kann d'Schreiwen akzeptéieren an engagéieren.

Eng Verbindung pro Transaktioun?

All Applikatioun brauch eng aner Zort Kombinatioun vu Konsistenz a Leeschtung. Ausser et ass natierlech eis Rechnungsbezuelung App, déi mir eis virstellen datt se komplett konsequent ass, oder eis bal ephemeral sozial Netzwierker App. An all anere Fäll ginn et Zäite wou e puer Operatiounen synchron musse sinn an e puer asynchron sinn. Dir wëllt vläicht net datt de System waart bis e Message un de Chat geschéckt ass engagéiert ass, awer wann eng Bezuelung an der selwechter Applikatioun veraarbecht gëtt, da musst Dir waarden.

All dës Entscheedunge ginn natierlech vum Applikatiounsentwéckler gemaach. Déi richteg Entscheedungen ze huelen iwwer wéini Dir all Approche benotzt hëlleft Iech dat Bescht aus Ärem Cluster ze kréien. Et ass wichteg datt den Entwéckler tëscht hinnen um SQL Niveau fir Verbindungen a fir Transaktiounen ka wiesselen.

Kontroll an der Praxis garantéieren

Par défaut bitt PostgreSQL Konsistenz. Dëst gëtt vum Serverparameter kontrolléiert synchronous_commit. Par défaut ass et an der Positioun on, awer et huet dräi aner Optiounen: local, remote_write oder off.

Wann Dir de Parameter op off all synchron Verpflichtungen sinn gestoppt, och op der lokal System. D'lokal Parameter spezifizéiert Synchronmodus fir de lokalen System, awer Schreiwen op Repliken ginn asynchron duerchgefouert. Remote_write geet nach méi wäit: Schreift op Repliken ginn asynchron gemaach, awer ginn zréck wann d'Replique d'Schreiwen akzeptéiert huet, awer et net op Scheif geschriwwen huet.

Andeems Dir déi verfügbar Palette vun Optiounen berücksichtegt, wielt mir e Verhalen an, am Kapp behalen on - dës sinn Synchron Opzeechnunge, wäerte mir wielen local fir asynchrone verpflichte iwwer d'Netz, iwwerdeems verloossen lokal verpflichte synchron.

Elo wäerte mir Iech soen wéi Dir dëst an engem Moment opstellt, awer stellt Iech vir datt mir opgeriicht hunn synchronous_commit в local fir de Server. Mir hu gefrot ob et méiglech wier de Parameter z'änneren synchronous_commit op der fléien, an et huet sech erausgestallt, datt et net nëmme méiglech ass, ginn et souguer zwou Méiglechkeeten dëst ze maachen. Déi éischt ass d'Sessioun vun Ärer Verbindung wéi follegt ze setzen:

SET SESSION synchronous_commit TO ON;  
// Your writes go here

All spéider Schreiwen an der Sessioun wäerte Schreiwen un d'Repliken unerkennen ier se e positiv Resultat un de verbonne Client zréckginn. Ausser Dir ännert natierlech d'Astellung synchronous_commit erëm. Dir kënnt Deel ausgoen SESSION am Kommando well et am Standardwäert wäert sinn.

Déi zweet Method ass gutt wann Dir just sécher sidd datt Dir eng synchron Replikatioun fir eng eenzeg Transaktioun kritt. A ville NoSQL Generatioun Datenbanken existéiert d'Konzept vun Transaktiounen net, awer et ass am PostgreSQL. An dësem Fall fänkt Dir eng Transaktioun un a setzt dann synchronous_commit в on ier Dir d'Entrée fir d'Transaktioun ausféiert. COMMIT wäert d'Transaktioun engagéieren mat all Parameterwäert synchronous_commit, déi deemools gesat gouf, obwuel et am beschten ass d'Variabel viraus ze setzen fir sécherzestellen datt aner Entwéckler verstoen datt Schreiwen net asynchron sinn.

BEGIN;  
SET LOCAL synchronous_commit TO ON;  
// Your writes go here
COMMIT;  

All Transaktiounsverpflichtungen ginn elo bestätegt wéi geschriwwe fir Repliken ier d'Datebank eng positiv Äntwert op de verbonne Client zréckkënnt.

PostgreSQL konfiguréieren

Virun dëser hu mir e PostgreSQL System mat virgestallt synchronous_commit, installéiert an local. Fir dëst op der Serversäit realistesch ze maachen, musst Dir zwou Serverkonfiguratiounsoptioune setzen. Ee méi Parameter synchronous_standby_names wäert kommen an seng eege wann synchronous_commit wäert sinn on. Et bestëmmt wéi eng Replikatioune berechtegt sinn fir synchron Verpflichtungen, a mir wäerten et setzen *, wat bedeit datt all Repliken involvéiert sinn. Dës Wäerter sinn normalerweis konfiguréiert an Konfiguratiounsdatei andeems Dir bäidréit:

synchronous_commit = local  
synchronous_standby_names='*'

Duerch d'Astellung vum Parameter synchronous_commit an Bedeitung local, Mir kreéieren e System wou lokal Disken synchron bleiwen, awer Reseau Replica Verpflichtungen sinn asynchron als Standard. Ausser, natierlech, mir décidéieren dës Verpflichtungen synchron ze maachen, wéi uewen gewisen.

Wann Dir d'Entwécklung verfollegt hutt Gouverneur Projet, Dir hutt vläicht e puer rezent Ännerungen gemierkt (1, 2), wat de Gouverneur Benotzer erlaabt dës Parameteren ze testen an hir Konsistenz ze iwwerwaachen.

E puer méi Wierder ...

Virun enger Woch hätt ech Iech gesot datt et onméiglech ass PostgreSQL sou fein ofzestëmmen. Dat ass wann de Kurt, e Member vum Compose Plattform Team, insistéiert datt esou eng Geleeënheet existéiert. Hien huet meng Contestatiounen berouegt an an der PostgreSQL Dokumentatioun fonnt déi folgend:

Dës Astellung kann zu all Moment geännert ginn. D'Behuele fir all Transaktioun gëtt festgeluegt duerch d'Astellung déi am Moment vum Engagement a Kraaft ass. Dofir ass et méiglech an nëtzlech fir e puer Transaktiounen synchron ze engagéieren a fir anerer asynchron. Zum Beispill, fir een ze zwéngen multistatement Transaktioun ze maachen engagéiert asynchronously wann de Standard Wäert vun der Parameter Géigewier ass, gesat SET LOCAL synchronous_commit TO OFF an enger Transaktioun.

Mat dëser klenger Ännerung vun der Konfiguratiounsdatei hu mir d'Benotzer Kontroll iwwer hir Konsistenz a Leeschtung ginn.

Source: will.com