A traduzzione di l'articulu hè stata preparata apposta per i studienti di u corsu "Base di dati". Interessatu à sviluppà in questa direzzione? Vi invitemu à Open Day, induve parlemu in dettagliu di u prugramma, caratteristiche di u furmatu in linea, cumpetenze è prospettive di carriera chì aspettanu i graduati dopu a furmazione.

PostgreSQL è paràmetri di coerenza di scrittura specifica per a cunnessione
À Compose, avemu trattatu cù parechje basa di dati, chì ci dà l'uppurtunità di diventà più familiarizatu cù e so funziunalità è e so mancanze. Cume avemu amparatu à amassi e caratteristiche di e novi basa di dati, qualchì volta cuminciamu à pensà à quantu saria bella se e caratteristiche simili eranu prisenti in l'arnesi più maturi chì avemu travagliatu dapoi un bellu pezzu. Una di e funzioni novi chì vulia vede in PostgreSQL era a cunfigurazione di scrittura cunfigurabile per cunnessione in tuttu u cluster. E cum'è si trova, avemu digià, è oghje vulemu sparte cun voi infurmazioni nantu à cumu pudete aduprà.

Perchè l'aghju bisognu?

Cumu si deve cumportà u cluster dipende da a vostra applicazione. Pigliate, per esempiu, una app di pagamentu di fattura. Averete bisognu di XNUMX% di coerenza in u cluster, cusì vi tuccherà à attivà cummits sincroni in modu chì a vostra basa di dati aspetta chì tutti i cambiamenti sò fatti. Tuttavia, se a vostra applicazione hè una reta suciale in rapida crescita, allora probabilmente preferite una risposta rapida più di XNUMX% di coerenza. Per ottene questu, pudete aduprà commits asincroni in u vostru cluster.

Scontru cumprumissu

Avete da fà scambii trà a cunsistenza di e dati è u rendiment. PostgreSQL si alluntanassi da a coherenza perchè a cunfigurazione predeterminata hè allora prevedibile è senza sorprese inespettate. Avà guardemu i cumprumessi.

Tradeoff 1: Prestazione

Se u cluster PostgreSQL ùn hà micca bisognu di coerenza, pò eseguisce in modu asincronu. A scrittura hè fatta à u capu di u cluster, è l'aghjurnamenti seranu mandati à e so ripliche uni pochi millisecondi dopu. Quandu un cluster PostgreSQL richiede coerenza, deve esse eseguitu in modu sincronu. A scrittura serà fatta à u capu di u cluster, chì mandarà una aghjurnazione à e rèpliche è aspittà a cunferma chì ognunu hà scrittu prima di mandà cunferma à u cliente chì hà iniziatu a scrittura chì era successu. A diferenza pratica trà questi approcci hè chì u metudu asincronu richiede dui salti di rete, mentre chì u metudu sincronu richiede quattru.

Tradeoff 2: Cuerenza

U risultatu in l'eventu di un fallimentu di capu in questi dui approcci serà ancu diversu. Se u travagliu hè realizatu in modu asincronu, allora se un tali errore si trova, micca tutti i registri seranu impegnati da e rèpliche. Quantu serà persu ? Dipende da l'applicazione stessa è l'efficienza di a replicazione. A replicazione di cumpusizioni impedisce chì una replica diventerà un capu se a quantità di informazioni in questu hè 1 MB menu cà in u capu, vale à dì, finu à 1 MB di registri puderia esse persu durante l'operazione asincrona.

Questu ùn succede micca in modu sincronu. Se u capu falla, tutte e rèpliche sò aghjurnati, postu chì ogni scrittura cunfirmata nantu à u capu deve esse cunfirmata nantu à e rèpliche. Questu hè a coherenza.

U cumpurtamentu sincronu hè sensu in una applicazione di fattura induve a coerenza hà un vantaghju chjaru in u scambiu trà a coerenza è u rendiment. A cosa più impurtante per una tale applicazione hè dati validi. Avà pensate à una reta suciale in quale u compitu principalu hè di mantene l'attenzione di l'utilizatori rispondendu à e dumande u più prestu pussibule. In questu casu, u rendiment cù menu salti di rete è menu aspittà per i cummissioni seranu una priorità. Tuttavia, u scambiu trà u rendiment è a coherenza ùn hè micca l'unicu chì avete da pensà.

Trade-off 3: Crashes

Hè assai impurtante per capiscenu cumu si cumporta un cluster durante un fallimentu. Cunsiderate una situazione induve una o più repliche fallenu. Quandu i commits sò processati in modu asincronu, u capu continuarà à funziunà, vale à dì, accettà è processà e scritture, senza aspittà di ripliche mancanti. Quandu e rèpliche tornanu à u cluster, si ghjunghjenu à u capu. Cù a replicazione sincrona, se e rèpliche ùn rispundenu micca, allora u capu ùn averà micca scelta è cuntinuerà à aspittà per a cunferma di cummissione finu à chì a replica torna à u cluster è pò accettà è cummettà a scrittura.

Una cunnessione per transazzione?

Ogni applicazione hà bisognu di un tipu diversu di cumminazione di coerenza è prestazione. A menu chì, sicuru, hè a nostra app di pagamentu di fattura, chì imaginemu esse cumplettamente coherente, o a nostra app di rete suciale quasi effimera. In tutti l'altri casi, ci saranu volte quandu alcune operazioni devenu esse sincrone è alcune deve esse asincrone. Ùn pudete micca vulete chì u sistema aspittà finu à chì un missaghju mandatu à u chat hè impegnatu, ma se un pagamentu hè processatu in a listessa applicazione, allora vi tuccherà à aspittà.

Tutte queste decisioni, sicuru, sò fatte da u sviluppatore di l'applicazione. Piglià e decisioni ghjuste nantu à quandu aduprà ogni approcciu vi aiuterà à ottene u massimu di u vostru cluster. Hè impurtante chì u sviluppatore pò cambià trà elli à u livellu SQL per cunnessione è per transazzione.

Assicurendu u cuntrollu in pratica

Per automaticamente, PostgreSQL furnisce coerenza. Questu hè cuntrullatu da u paràmetru di u servitore synchronous_commit. Per automaticamente hè in pusizioni on, ma hà trè altre opzioni: local, remote_write o off.

Quandu si mette u paràmetru à off tutti i commits sincroni sò fermati, ancu in u sistema lucale. U paràmetru lucale specifica u modu sincronu per u sistema lucale, ma scrive à e repliche sò realizati in modu asincronu. Remote_write va ancu più luntanu: i scritti à e rèpliche sò fatti in modu asincronu, ma sò tornati quandu a replica hà accettatu a scrittura ma ùn l'hà micca scrittu à u discu.

Cunsiderendu a gamma di opzioni dispunibuli, scegliemu un cumpurtamentu è, tenendu in mente chì on - Quessi sò registrazioni sincrone, scegliemu local per commits asincroni nantu à a reta, mentre chì lascendu i cummissioni lucali sincroni.

Avà, vi diceremu cumu fà stallà questu in un mumentu, ma imaginate chì avemu stallatu synchronous_commit в local per u servitore. Avemu dumandatu s'ellu era pussibule cambià u paràmetru synchronous_commit nantu à a mosca, è si girò fora chì ùn hè micca solu pussibule, ci sò ancu duie manere di fà questu. U primu hè di stabilisce a sessione di a vostra cunnessione cusì:

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

Tutte e scritte successive in a sessione ricunnosceranu e scritte à e rèpliche prima di rinvià un risultatu pusitivu à u cliente cunnessu. A menu chì, sicuru, cambiate u paràmetru synchronous_commit di novu. Pudete omette una parte SESSION in u cumandimu perchè serà in u valore predeterminatu.

U sicondu metudu hè bonu quandu vulete solu assicurà chì avete a replicazione sincrona per una sola transazzione. In parechje basa di dati di generazione NoSQL u cuncettu di transazzione ùn esiste micca, ma in PostgreSQL. In questu casu, avete principiatu una transazzione è poi stabilisce synchronous_commit в on prima di eseguisce l'entrata per a transazzione. COMMIT cummetterà a transazzione utilizendu qualsiasi valore di parametru synchronous_commit, chì hè stata stabilita à l'epica, ancu s'ellu hè megliu stabilisce a variabile in anticipu per assicurà chì l'altri sviluppatori capiscenu chì i scritti ùn sò micca asincroni.

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

Tutti l'impegni di transazzione seranu avà cunfirmati cum'è scritti à repliche prima chì a basa di dati torna una risposta positiva à u cliente cunnessu.

Configurazione di PostgreSQL

Prima di questu, avemu imaginatu un sistema PostgreSQL cun synchronous_commit, installatu in local. Per fà questu realisticu da u latu di u servitore, avete bisognu di stabilisce duie opzioni di cunfigurazione di u servitore. Un altru paràmetru synchronous_standby_names entrerà in u so propiu quandu synchronous_commit serà in on. Determina quali rèpliche sò eligibili per commits sincroni, è l'avemu stabilitu *, chì significarà chì tutte e rèpliche sò implicati. Questi valori sò generalmente cunfigurati in schedariu di cunfigurazione aghjustendu:

synchronous_commit = local  
synchronous_standby_names='*'

Fixendu u paràmetru synchronous_commit in significatu local, Creemu un sistema induve i dischi lucali restanu sincroni, ma i cummissioni di rèplica di a rete sò asincroni per difettu. A menu chì, di sicuru, decidemu di fà questi impegni sincroni, cum'è mostratu sopra.

Sè avete seguitu u sviluppu Prughjettu di u guvernatore, pudete avè nutatu alcuni cambiamenti recenti (1, 2), chì hà permessu à l'utilizatori di u Guvernatore di pruvà sti paràmetri è monitorizà a so coherenza.

Qualche parolle in più...

Solu una settimana fà, vi averia dettu chì hè impussibile di fine-tune PostgreSQL cusì finamente. Hè quandu Kurt, un membru di a squadra di a piattaforma Compose, insistia chì una tale opportunità esiste. Calmò e mo obiezioni è truvò in a documentazione PostgreSQL seguente:

Stu paràmetru pò esse cambiatu in ogni mumentu. U cumpurtamentu per ogni transazzione hè determinata da u paràmetru in vigore à u mumentu di l'impegnu. Dunque, hè pussibile è utile per alcune transazzione per impegnà in modu sincronu è per altri in modu asincronu. Per esempiu, per furzà unu multistatement transazzione per fà commits asynchronously quandu u valore predeterminatu di u paràmetru hè oppostu, stabilitu SET LOCAL synchronous_commit TO OFF in una transazzione.

Cù sta piccula mudificazione à u schedariu di cunfigurazione, avemu datu à l'utilizatori u cuntrollu di a so cunsistenza è u so rendiment.

Source: www.habr.com