Prevod članka je bil pripravljen posebej za študente tečaja "Baza podatkov". Vas zanima razvoj v tej smeri? Vabimo vas, da Odprt dan, kjer podrobno govorimo o programu, značilnostih spletnega formata, kompetencah in kariernih možnostih, ki čakajo diplomante po usposabljanju.

PostgreSQL in nastavitve doslednosti pisanja, specifične za povezavo
Pri Compose se ukvarjamo s številnimi zbirkami podatkov, kar nam daje možnost, da se pobliže seznanimo z njihovimi funkcionalnostmi in pomanjkljivostmi. Ko se naučimo vzljubiti funkcije novih baz podatkov, včasih začnemo razmišljati, kako lepo bi bilo, če bi bile podobne funkcije prisotne v bolj zrelih orodjih, s katerimi delamo že dolgo. Ena od novih funkcij, ki sem jih želel videti v PostgreSQL, je bila nastavljiva doslednost pisanja na povezavo v celotni gruči. In kot kaže, ga že imamo, danes pa želimo z vami deliti informacije o tem, kako ga lahko uporabite.

Zakaj ga potrebujem?

Kako naj se gruča obnaša, je odvisno od vaše aplikacije. Vzemimo za primer aplikacijo za plačevanje računov. Potrebovali boste XNUMX-odstotno doslednost v gruči, zato boste morali omogočiti sinhrone potrditve, da bo vaša baza podatkov čakala na izvedbo vseh sprememb. Če pa je vaša aplikacija hitro rastoče socialno omrežje, boste verjetno raje imeli hiter odziv kot XNUMX-odstotno doslednost. Če želite to doseči, lahko v svoji gruči uporabite asinhrone potrditve.

Spoznajte kompromis

Morate narediti kompromise med doslednostjo podatkov in zmogljivostjo. PostgreSQL se odmika od doslednosti, ker je privzeta konfiguracija potem predvidljiva in brez nepričakovanih presenečenj. Zdaj pa poglejmo kompromise.

Kompromis 1: Zmogljivost

Če gruča PostgreSQL ne zahteva konsistentnosti, lahko deluje asinhrono. Zapis se izvede v vodjo gruče, posodobitve pa bodo poslane njegovim replikam nekaj milisekund kasneje. Ko gruča PostgreSQL zahteva doslednost, mora delovati sinhrono. Zapis bo opravljen vodji gruče, ki bo poslal posodobitev replikam in počakal na potrditev, da je vsaka zapisala, preden pošlje potrditev odjemalcu, ki je sprožil pisanje, da je bilo pisanje uspešno. Praktična razlika med temi pristopi je, da asinhrona metoda zahteva dva omrežna skoka, medtem ko sinhrona metoda zahteva štiri.

Kompromis 2: doslednost

Tudi rezultat v primeru neuspeha vodje pri teh dveh pristopih bo različen. Če se delo izvaja asinhrono, potem, če pride do takšne napake, replike ne bodo potrdile vseh zapisov. Koliko bo izgubljenega? Odvisno od same aplikacije in učinkovitosti replikacije. Replikacija sestavljanja bo preprečila, da bi replika postala vodilna, če je količina informacij v njej 1 MB manjša kot v vodilni, kar pomeni, da bi se lahko med asinhronim delovanjem izgubilo do 1 MB zapisov.

To se ne zgodi v sinhronem načinu. Če vodja ne uspe, se posodobijo vse replike, saj mora biti vsako pisanje, potrjeno na vodilnem, potrjeno na replikah. To je doslednost.

Sinhrono vedenje je smiselno v aplikaciji za obračunavanje, kjer ima doslednost očitno prednost pri kompromisu med doslednostjo in zmogljivostjo. Za takšno aplikacijo so najpomembnejši veljavni podatki. Zdaj pa pomislite na socialno omrežje, v katerem je glavna naloga ohraniti pozornost uporabnika s čim hitrejšim odzivom na zahteve. V tem primeru bo prednostna naloga zmogljivost z manj omrežnimi skoki in manj čakanja na potrditev. Vendar pa kompromis med zmogljivostjo in doslednostjo ni edini, o katerem morate razmišljati.

Kompromis 3: Zrušitve

Zelo pomembno je razumeti, kako se grozd obnaša ob okvari. Razmislite o situaciji, ko ena ali več replik ne uspe. Ko se potrditve obdelujejo asinhrono, bo vodja še naprej deloval, to je sprejemal in obdeloval zapise, ne da bi čakal na manjkajoče replike. Ko se replike vrnejo v gručo, dohitijo vodjo. Pri sinhroni replikaciji, če se replike ne odzovejo, vodja ne bo imel izbire in bo še naprej čakal na potrditev potrditve, dokler se replika ne vrne v gručo in lahko sprejme in potrdi pisanje.

Ena povezava na transakcijo?

Vsaka aplikacija potrebuje drugačno kombinacijo doslednosti in zmogljivosti. Razen seveda, če je to naša aplikacija za plačevanje računov, za katero si predstavljamo, da je popolnoma dosledna, ali naša skoraj minljiva aplikacija za družabna omrežja. V vseh drugih primerih bodo včasih nekatere operacije morale biti sinhrone, nekatere pa asinhrone. Morda ne želite, da sistem počaka, dokler se sporočilo, poslano v klepet, ne odobri, a če je plačilo obdelano v isti aplikaciji, boste morali počakati.

Vse te odločitve seveda sprejema razvijalec aplikacije. Pravilne odločitve o tem, kdaj uporabiti posamezen pristop, vam bodo pomagale kar najbolje izkoristiti vaš grozd. Pomembno je, da lahko razvijalec preklaplja med njimi na ravni SQL za povezave in transakcije.

Zagotavljanje nadzora v praksi

PostgreSQL privzeto zagotavlja doslednost. To nadzira parameter strežnika synchronous_commit. Privzeto je na položaju on, vendar ima še tri druge možnosti: local, remote_write ali off.

Pri nastavitvi parametra na off vse sinhrone objave so ustavljene, tudi v lokalnem sistemu. Lokalni parameter določa sinhroni način za lokalni sistem, vendar se pisanje v replike izvaja asinhrono. Remote_write gre še dlje: zapisi v replike se izvajajo asinhrono, vendar se vrnejo, ko je replika sprejela pisanje, vendar ga ni zapisala na disk.

Ob upoštevanju razpoložljivega nabora možnosti izberemo vedenje in ob upoštevanju tega on – to so sinhroni posnetki, bomo izbrali local za asinhrone objave prek omrežja, medtem ko lokalne objave pustijo sinhrone.

Čez trenutek vam bomo povedali, kako to nastavite, vendar si predstavljajte, da smo nastavili synchronous_commit в local za strežnik. Zanimalo nas je, ali je možno spremeniti parameter synchronous_commit sproti, in izkazalo se je, da to ni le mogoče, ampak obstajata celo dva načina. Prvi je, da nastavite sejo svoje povezave na naslednji način:

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

Vsa naslednja pisanja v seji bodo potrdila pisanja v replike, preden bodo povezanemu odjemalcu vrnili pozitiven rezultat. Razen seveda, če spremenite nastavitev synchronous_commit ponovno. Del lahko izpustite SESSION v ukazu, ker bo v privzeti vrednosti.

Druga metoda je dobra, ko želite samo zagotoviti, da dobite sinhrono podvajanje za eno transakcijo. V mnogih bazah podatkov generacije NoSQL koncept transakcij ne obstaja, v PostgreSQL pa obstaja. V tem primeru začnete transakcijo in nato nastavite synchronous_commit в on pred izvedbo vnosa za transakcijo. COMMIT bo izvršil transakcijo z uporabo katere koli vrednosti parametra synchronous_commit, ki je bil takrat nastavljen, čeprav je najbolje, da spremenljivko nastavite vnaprej, da se prepričate, da drugi razvijalci razumejo, da pisanje ni asinhrono.

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

Vse potrditve transakcij bodo zdaj potrjene kot zapisane v replike, preden baza podatkov vrne pozitiven odgovor povezanemu odjemalcu.

Konfiguriranje PostgreSQL

Pred tem smo si zamislili sistem PostgreSQL z synchronous_commit, nameščen v local. Da bo to realistično na strani strežnika, boste morali nastaviti dve možnosti konfiguracije strežnika. Še en parameter synchronous_standby_names bo prišel na svoj račun, ko synchronous_commit bo v on. Določa, katere replike so primerne za sinhrone objave, in nastavili ga bomo na *, kar bo pomenilo, da so vključene vse replike. Te vrednosti so običajno konfigurirane v konfiguracijsko datoteko z dodajanjem:

synchronous_commit = local  
synchronous_standby_names='*'

Z nastavitvijo parametra synchronous_commit v pomen local, izdelamo sistem, v katerem lokalni diski ostanejo sinhroni, vendar so potrditve omrežnih replik privzeto asinhrone. Razen seveda, če se odločimo, da bodo te objave sinhrone, kot je prikazano zgoraj.

Če ste spremljali razvoj Projekt guvernerja, morda ste opazili nekaj nedavnih sprememb (1, 2), kar je uporabnikom Governorja omogočilo testiranje teh parametrov in spremljanje njihove skladnosti.

Še nekaj besed...

Še pred tednom dni bi vam rekel, da je nemogoče tako natančno prilagoditi PostgreSQL. Takrat je Kurt, član skupine platforme Compose, vztrajal, da taka priložnost obstaja. Pomiril je moje ugovore in našel v dokumentaciji PostgreSQL naslednje:

To nastavitev lahko kadar koli spremenite. Obnašanje katere koli transakcije je določeno z nastavitvijo, ki velja v času potrditve. Zato je mogoče in koristno, da se nekatere transakcije potrdijo sinhrono, za druge pa asinhrono. Na primer, na silo multistatement transakcija za asinhrono potrditev, ko je privzeta vrednost parametra nasprotna, nastavite SET LOCAL synchronous_commit TO OFF v transakciji.

S to majhno spremembo konfiguracijske datoteke smo uporabnikom dali nadzor nad njihovo doslednostjo in zmogljivostjo.

Vir: www.habr.com