Artikli tõlge on ette valmistatud spetsiaalselt kursuse üliõpilastele . Kas olete huvitatud selles suunas arenemisest? Kutsume teid üles , kus me räägime põhjalikult programmist, veebivormingu omadustest, kompetentsidest ja karjäärivõimalustest, mis ootavad lõpetajaid pärast õpinguid.
PostgreSQL ja kirje kooskõlastamise seadistused iga konkreetse ühenduse jaoks
Meil Compose'is tuleb tegeleda paljude andmebaasidega, just see annab meile võimaluse paremini tutvuda nende funktsionaalsuse ja puudustega. Kui me õpime armastama uute andmebaaside funktsionaalseid omadusi, hakkame mõnikord mõtlema, kui hea oleks, kui sarnased funktsioonid oleksid olemas ka küpsetes tööriistades, millega me juba ammu töötame. Üks uus funktsioon, mida oleks tahtnud näha PostgreSQL-is, oli seadistatav kirjutamise kooskõla kogu klastris. Ja nagu selgus, on see meil juba olemas, ja täna tahame jagada teavet selle kohta, kuidas saate seda kasutada.
Miks mul seda vaja on?
Kuidas klaster käitub, sõltub teie rakendusest. Võtame näiteks arve maksmise rakenduse. 100% kokkulepe klastris on vajalik, seega peate lubama sünkroonsed commit'id, et teie andmebaas ootaks, kuni kõik muudatused on tehtud. Kui aga teie rakendus on kiiresti arenev sotsiaalne võrgustik, siis eelistaksite kindlasti kiiret vastust üle 100% kokkuleppe. Selleks võite oma klastris kasutada asünkroonseid commit'e.
Tutvuge kompromissiga
Te peate leppima andmete konsistentsi ja jõudluse vahel. PostgreSQL liikuda konsistentsi suunas, kuna vaikeseadistus on sel juhul ettearvatav ja ilma ootamatute üllatusteta. Nüüd uurime lähemalt compromisse.
Kompromiss 1: Jõudlus
Kui PostgreSQL kluster ei nõua järjepidevust, võib see töötada asünkroonselt. Kirje tehakse klusteri liidrile ja tema koopiad saavad uuendused mõne millisekundi pärast. Kui PostgreSQL kluster vajab järjepidevust, peab see töötama sünkroonselt. Kirje tehakse klusteri liidrile, kes saadab koopiatele uuenduse ning ootab kinnitust, et igaüks on kirje teinud, enne kui saadab kliendile, kes algatas kirje, kinnituse, et see õnnestus. Praktikas seisneb erinevus nende lähenemiste vahel selles, et asünkroonne meetod nõuab kahte võrku hüpet, samas kui sünkroonne nõuab nelja.
Kompromiss 2: Järjepidevus
Juhul, kui juht töötab nende kahe lähenemise korral vale, on tulemus samuti erinev. Kui töö toimub asünkroonselt, siis sellise vea korral ei pruugi kõik kirjed replikates olla salvestatud. Kui palju kaob? See sõltub rakendusest ja replikatsiooni efektiivsusest. Compose'i replikatsioon takistab replikal juhtkonna rolli saamist, kui selle sisu on 1 MB võrra väiksem juhtkonnast, mis tähendab, et asünkroonse töö korral võib potentsiaalselt kaduda kuni 1 MB kirjeid.
Sünkroonses režiimis seda ei juhtu. Kui juht ebaõnnestub, uuendatakse kõiki replikasid, kuna iga kirje, mis on juhil kinnitatud, peab olema ka replikates kinnitatud. See on see – järjepidevus.
Sünkroonset käitumist tasub kasutada arveldamise rakenduses, kus kooskõla annab selge eelise tasakaalu leidmisel kooskõla ja jõudluse vahel. Sellise rakenduse jaoks on kõige olulisemad kehtivad andmed. Ja nüüd tulge meelde sotsiaalne võrgustik, kus peamine ülesanne on kasutaja tähelepanu hoidmine, vastates päringutele võimalikult kiiresti. Sellisel juhul on prioriteediks jõudlus väiksema võrgu hüppe ja lühema ooteajaga. Siiski pole jõudluse ja kooskõla tasakaal üks ainus, millele mõtlema peab.
Tasakaal 3: Vead
On oluline mõista, kuidas klaster rikete korral käitub. Vaadakem olukorda, kus üks või enam replikast ebaõnnestuvad. Kui komiteid töödeldakse asünkroonselt, jätkab juht töötamist, s.t. aktsepteerib ja töötleb salvestusi, ilma et ootaks puuduvaid replikaid. Kui replikad naasevad klastri, jõuavad nad juhile järgi. Sünkroonse replikatsiooni korral, kui replikad ei vasta, ei jää juhile muud valikut, kui oodata komiteeringu kinnitust, kuni replikad naasevad klastri ja suudavad salvestust vastu võtta ja kinnitada.
Kas üks ühendus iga tehingu kohta?
Iga rakendus vajab erilist tasakaalu järjepidevuse ja jõudluse vahel. Kui see ei ole meie arve tasumise rakendus, mille me kujutame täielikult järjepidevana, või meie peaaegu eeterlik sotsiaalmeedia rakendus. Kõigil muudel juhtudel on olukordi, kus mõned toimingud peavad olema sügavalt sünkroonsed, samas kui teised võivad olla asünkroonsed. Te ei soovi, et süsteem ootaks, kuni sõnum, mis saadetakse vestluses, on kinnitatud, kuid kui selles samas rakenduses toimub makse, siis tuleb oodata.
Kõiki neid otsuseid teeb muidugi rakenduse arendaja. Õigeid otsuseid selle kohta, millal rakendada üht või teist lähenemist, aitab maksimeerida kloori efektiivsust. Oluline on, et arendaja suudaks SQL tasemel ühenduste ja tehingute vahel vahetada.
Praktilise kontrolli tagamine
Vaikimisi tagab PostgreSQL järjepidevuse. Seda kontrollib serveri parameeter synchronous_commit. Vaikimisi on see seadistatud on, kuid tal on kolm muud varianti: local, remote_write või off.
Parameetri seadistamine off peatatakse kõik sünkroonsed salvestused, isegi kohalikus süsteemis. Parameeter local määrab sünkroonsed režiimid kohalikes süsteemides, kuid replikatsioonid toimuvad asünkroonselt. Remote_write läheb veel kaugemale: replikatsioonid toimuvad asünkroonselt, kuid tagastatakse, kui replikatsioon on salvestuse vastu võtnud, kuid ei ole seda kettale salvestanud.
Arvestades olemasolevaid võimalusi, valime käitumise ja pidades silmas, et on – need on sünkroonsed salvestused, valime local asünkroonsed salvestused võrgus, jättes samas kohalikud salvestused sünkroonsed.
Nüüd räägime teile, kuidas seda minutiga seadistada, kuid kujutage ette, et oleme seadnud synchronous_commit ühes local serverile. Küsimus tekkis, kas parameetrit synchronous_commit võib muuta jooksvalt, ja selgus, et mitte ainult, et see on võimalik, vaid selleks on isegi kaks viisi. Esimene on seada teie ühenduse seanss järgmiselt:
SET SESSION synchronous_commit TO ON;
// Teie salvestused lähevad siiaKõik järgmised salvestused seansis kinnitavad replikatsioonitegevuse enne, kui tagastavad positiivse tulemuse ühendatud kliendile. Kui muidugi te ei muuda muudatust synchronous_commit taas. Seda osa võib vahele jätta SESSION meeskonnas, kuna see on vaikimisi väärtus.
Teine meetod on hea, kui soovite lihtsalt veenduda, et saate ühe tehingu jaoks sünkroonset replikatsiooni. Paljudes "NoSQL" andmebaasides ei eksisteeri tehingute kontseptsiooni, kuid PostgreSQLis see on olemas. Sellisel juhul käivitate tehingu ja seejärel määrate synchronous_commit ühes on enne tehingu kirjutamise täitmist. COMMIT fikseerib tehingu, kasutades mis tahes parameetri väärtust synchronous_commit, mis oli tol hetkel määratud, kuigi parima tulemuse saavutamiseks on parem eelnevalt määrata muutujad, et teised arendajad mõistaksid, et kirjed ei ole asünkronoossed.
BEGIN;
SET LOCAL synchronous_commit TO ON;
// Teie kirjed lähevad siia
COMMIT; Kõik tehingute kinnitused kinnitatakse nüüd, nagu oleks need kirjutatud replikatsioonidele juba enne, kui andmebaas tagastab ühendatud kliendile positiivse vastuse.
PostgreSQL seadistamine
Varem olime ette kujutanud PostgreSQL süsteemi, mille synchronous_commitoli seatud local. Selle toimimiseks serveripoolsel küljel peate seadistama kaks serveri konfiguratsiooni parameetrit. Veel üks parameeter synchronous_standby_names hakkab kehtima, kui synchronous_commit on on. Ta määrab, millised replikad saavad teha sünkroonsed kinnitused, ning me seadistame selle tuhandeks *, mis tähendab, et kõik replikad on kaasatud. Need väärtused seadistatakse tavaliselt järgmise lisamise teel:
synchronous_commit = local
synchronous_standby_names='*'Seades synchronous_commit väärtuse local, loome süsteemi, kus kohalikke kettaid hoitakse sünkroonselt, kuid võrgu replikate kinnitused on vaikimisi asünkroonsed. Kui muidugi ei otsusta me, et need kinnitused oleksid sünkroonsed, nagu ülalpool näidatud.
Kui olete jälginud , olete võinud märgata mõningaid hiljutisi muudatusi (, ), mis võimaldasid Governor kasutajatel neid seadeid katsetada ja nende ühtsust kontrollida.
Veel paar sõna…
Tegelikult oleks ma veel nädal tagasi öelnud, et PostgreSQL-i ei saa nii peensusteni seadistada. Just siis, kui Kurt, Compose'i platvormi meeskonna liige, väitis, et see on võimalik. Ta vaatas mu vastuväited maha ja leidis PostgreSQL-i dokumentatsioonist :
Seda seadistust saab igal ajal muuta. Iga tehingu käitumine määratakse seadistuse põhjal, mis kehtib commit'i hetkel. Seetõttu on võimalik ja kasulik, et mõned tehingud sooritavad commit'id sünkroonselt, samas kui teised - asünkroonselt. Näiteks, kui soovite sundida ühte multistatement tehingut tegema commit'e asünkroonselt, kui vaikeväärtus on vastupidine, seadistage SET LOCAL synchronous_commit TO OFF tehingus.
Sellise väikese muudatuse kaudu konfiguratsioonifailis oleme andnud kasutajatele võimaluse kontrollida nende kooskõla ja jõudlust.
Allikas: habr.com
