Artikli tõlge on ette valmistatud spetsiaalselt kursuse üliõpilastele „Andmebaasid”. Kas on huvi selles valdkonnas areneda? Kutsume teid Avatud Uste Päevale, kus räägime lähemalt programmist, veebivormingu eripäradest, oskustest ja karjäärivõimalustest, mis ootavad lõpetajaid pärast õppimist.

PostgreSQL ja sõlmede salvestamise sobivuse seade iga konkreetse ühenduse jaoks
Compose'is puutume me kokku paljude andmebaasidega, just see annab meile võimaluse tutvuda nende funktsionaalsuse ja puudustega. Aja jooksul, kui õpime armastama uute andmebaaside funktsionaalseid omadusi, hakkame mõnikord mõtlema, kui tore oleks, kui sarnased funktsioonid oleksid olemas ka vanemates tööriistades, millega oleme juba pikka aega töötanud. Üks uus omadus, mida soovisin PostgreSQL-is näha, oli konfigureeritav salvestamise sobivus ühenduse kohta kogu klastris. Ja nagu selgus, on see meil juba olemas, ja täna tahame jagada teavet selle kohta, kuidas te seda kasutada saate.

Milleks mul seda vaja on?

Kuidas klaster käituma peab, sõltub teie rakendusest. Võtame näiteks arveldamise rakenduse. Teile on vajalik absoluutne sobivus klastris, seega peate aktiveerima sünkroonsed committid, et teie andmebaas ootaks, kuni kõik muudatused on tehtud. Kuid kui teie rakendus on kiiresti arenev sotsiaalne võrgustik, eelistaksite kindlasti absoluutse sobivuse asemel kiiret reageerimist. Selle saavutamiseks võite kasutada oma klastris asünkroonseid committe.

Tutvuge kompromissiga

Teil tuleb leppida kokku andmete sobivuse ja jõudluse vahel. PostgreSQL liigub sobivuse suunas, kuna vaikeseade on selles osas ennustatav ja ilma ootamatute üllatusteta. Nüüd alustame kompromisside tundmaõppimist.

Kompromiss 1: Jõudlus

Kui PostgreSQL klastril pole nõudeid järjepidevuse osas, võib see täiesti töötada asünkroonselt. Kirje kantakse klastriliidrisse ja selle koopiateni saadetakse värskendused mõne millisekundi jooksul. Kui PostgreSQL klastrile on vajalik järjepidevus, peab see töötama sünkroonselt. Kirje kantakse klastriliidrisse, mis saadab koopiatesse värskenduse ja ootab kinnitust, et igaüks on kirje teinud, enne kui saadab kliendile, kes algatas kirje, kinnituse selle eduka täitmise kohta. Praktikas on nende lähenemiste vahe selles, et asünkroonne meetod nõuab kahte võrgu hüpet, sünkroonne aga neli.

Kompromiss 2: Järjepidevus

Tulemused, kui liider ebaõnnestub, on mõlema meetodi puhul erinevad. Kui töö toimub asünkroonselt, siis sellise vea korral ei ole kõik kirjed koopiates kinnitatud. Kui palju tuleb kaotada? See sõltub rakendusest ja replikatsiooni efektiivsusest. Compose'i replikatsioon takistab koopial liidriks saamist, kui selle sisu on 1 MB võrra väiksem kui liidril, mis tähendab, et potentsiaalselt võib asünkroonse töö korral kaotada kuni 1 MB kirjeid.

Sünkroonses režiimis seda ei juhtu. Kui liider ebaõnnestub, uuendatakse kõiki koopiaid, kuna iga kirje, mis on liidris kinnitatud, peab olema kinnitatud ka koopiates. See ongi järjepidevus.

Sünkroonse käitumise kasutamine on mõttekas arveldamise rakenduses, kus järjepidevuse eelised on selgelt tasakaalus järjepidevuse ja jõudluse vahel. Sellise rakenduse jaoks on kõige tähtsam kehtivad andmed. Krediteerides peavad nad olema õiged. Ja nüüd meenutage sotsiaalmeediat, kus peamine eesmärk on hoida kasutaja tähelepanu, vastates päringutele võimalikult kiiresti. Sellisel juhul on jõudlus, millel on vähem võrgu hüppeid ja lühemad kinnituste ooterežiimid, prioriteediks. Siiski ei ole kompromiss jõudluse ja järjepidevuse vahel ainus, millele mõtlema peab.

Kompromiss 3: Vead

On oluline mõista, kuidas klaster rikete korral käitub. Vaatleme olukorda, kus üks või rohkem replikaatidest ebaõnnestub. Kui kinnitusprotsessid viiakse läbi asünkroonselt, jätkab juht funktsioneerimist, see tähendab, et ta võtab vastu ja töötleb kirjeid, teadmata puuduvatest replikaatidest. Kui repliigid naasevad klastrisse, siis nad jooksevad juhti taga. Sünkroonse replikatsiooni puhul, kui repliigid ei vasta, ei jää juhtidel muud valikut kui oodata kinnitust, kuni replik tagasi klastrisse naaseb ja suudab kirjeid vastu võtta ja kinnitada.

Üks ühendus ühe tehingu kohta?

Igal rakendusel on vajalik eriline kooskõla ja jõudluse kombinatsioon. Kui see pole meie arveid tasumise rakendus, mida kujutame täiesti kooskõlalise, või meie peaaegu eeterlik sotsiaalmeedia rakendus. Kõigil teistel juhtudel on olukordi, kus teatud toimingud peavad olema sünkroonsed ja teised asünkroonsed. Te ei pruugi soovida, et süsteem ootaks, kuni sõnum, mis on chat’i saadetud, on kinnitatud, kuid kui samas rakenduses toimub makse, siis tuleb oodata.

Kõik need otsused teeb loomulikult rakenduse arendaja. Õiged otsused selle kohta, millal rakendada ühte või teist lähenemist, aitavad klastrist maksimumi välja pigistada. Oluline on, et arendaja saaks SQL tasandil ühenduste ja tehingute puhul nende vahel vahetada.

Kontrolli tagamine praktikas

Vaikeväärtusena tagab PostgreSQL kooskõla. Seda kontrollitakse serveri parameetri kaudu synchronous_commit. Vaikimisi on see seisundis on, kuid tal on veel kolm muud varianti: local, remote_write või off.

Seades parameetrit off küsitakse tänu sünkroonsete kinnituste peatamisele ka kohalikus süsteemis. Parameeter local määrab sünkroonse režiimi kohaliku süsteemi jaoks, kuid kirjed repliikidesse tehakse asünkroonselt. Remote_write läheb veel kaugemale: kirjed repliikidesse tehakse asünkroonselt, kuid tagastatakse, kui replik on kirje vastu võtnud, kuid ei ole seda kettale salvestanud.

Vaadates olemasolevaid valikuid, valime käitumise ja meeles pidades, et on on sünkroonsed kirjed, valime local asünkroonsete kinnituste jaoks üle võrgu, samal ajal kui jätame kohalikud kinnitused sünkroonseks.

Nüüd räägime teile, kuidas seda hetkega seadistada, kuid kujutage ette, et oleme installinud synchronous_commit ja local serverile. Me küsisime endalt, kas saab parameetrit synchronous_commit jooksvalt muuta, ja selgus, et mitte ainult saab, vaid selleks on lausa kaks viisi. Esimene on seada oma ühenduse sessioon järgmiselt:

SET SESSION synchronous_commit TO ON;  
// Teie kirjutised tulevad siia

Kõik järgnevad kirjutised sessioonis kinnitavad kirjutamisoperatsioonid replikatsioonide jaoks enne, kui nad tagastavad positiivse tulemuse seotud kliendile. Kui te muidugi ei muuda seadet synchronous_commit taas. Osade võib jätta välja SESSION käsklusest, kuna see on vaikimisi väärtuses.

Teine viis on hea, kui soovite lihtsalt veenduda, et saate ühe tehingu jaoks sünkroonset replikatsiooni. Paljude „NoSQL” andmebaaside puhul ei eksisteeri tehingute mõistet, kuid PostgreSQL-is see eksisteerib. Sel juhul käivitate tehingu ja seejärel seate synchronous_commit ja on enne tehingu kirjutamise täitmist. COMMIT kinni peab tehingu, kasutades mis tahes parameetri väärtust, synchronous_commit, mis oli sel ajal seadistatud, kuigi parima tulemuse nimel on parem seada muutuja ette, et teised arendajad mõistaksid, et kirjutised ei ole asünkroonilised.

BEGIN;  
SET LOCAL synchronous_commit TO ON;  
// Teie kirjutised tulevad siia
COMMIT;  

Kõik tehingute kinnitused kinnitatakse nüüd, nagu oleksid need kirjutatud replikatsioonides juba enne, kui andmebaas tagastab positiivse vastuse seotud kliendile.

PostgreSQL seadistamine

Seni oleme ette kujutanud PostgreSQL süsteemi, millel on synchronous_commit, installitud local. Selle serveri poolel reaalsuseks tegemiseks peate seadma kaks serveri konfiguratsiooniparameetrit. Veel üks parameeter synchronous_standby_names hakkab kehtima, kui synchronous_commit on on. See määrab, millised replikad saavad sünkroonset kinnitust, ja seame selle *, mis tähendab, et kõik replikad on lubatud. Need väärtused seadistatakse tavaliselt konfiguratsioonifailis lisades:

synchronous_commit = local  
synchronous_standby_names='*'

Seades parameetri synchronous_commit väärtuseks local, loome süsteemi, kus kohalikud kettad jäävad sünkroonseks, kuid võrgureplikate kinnitused on vaikimisi asünkroonsed. Kui me loomulikult ei otsusta neid kinnitusi sünkroonseteks teha, nagu ülal näidatud.

Kui olete jälginud projekti Governor arengut, olete võib tähele pannud mõningaid hiljutisi muudatusi (1, 2), mis võimaldasid kasutajatel Governor neid seadistusi testida ja nende järjepidevust kontrollida.

Veel paar sõna…

Kujutage ette, et veel nädal tagasi oleksin öelnud, et PostgreSQL-i nii detailselt häälestamine pole võimalik. Just sel ajal rõhutas Compose'i platvormi meeskonna liige Kurt, et selline võimalus on olemas. Ta vaigistas mu vastuväited ja leidis PostgreSQL-i dokumentatsioonist järgneva:

Seda seadet saab igal ajal muuta. Iga tehingu käitumine määratakse seade järgi, mis on aktiivne committed'i ajal. Seetõttu on võimalik ja kasulik, et mõnede tehingute korral toimub commit-synkroonselt, ja teiste korral – asünkroonselt. Näiteks, et sundida ühte multistatement tehingut tegema commit'e asünkroonselt, kui vaikeseadete väärtus on vastupidine, seada SET LOCAL synchronous_commit TO OFF tehingu jooksul.

Selle väikese konfiguratsioonifaili muutmisega andsime kasutajatele võimaluse kontrollida nende järjepidevust ja jõudlust.

Allikas: habr.com