Përkthimi i artikullit është përgatitur posaçërisht për studentët e kursit . A jeni të interesuar të zhvilloni këtë drejtim? Ju ftojmë në , ku ne do të flasim në detaje për programin, veçoritë e formatit online, kompetencat dhe perspektivat e karrierës që presin diplomantët pas përfundimit të studimeve.
PostgreSQL dhe konfigurimi i konsistencës së shkrimit për çdo lidhje të veçantë
Në Compose, ne përballemi me shumë baza të dhënash, dhe kjo na jep mundësinë të njohim më nga afër funksionalitetin dhe të metat e tyre. Ndërsa mësojmë të duam veçoritë funksionale të bazave të dhënash të reja, ndonjëherë fillojmë të mendojmë se sa mirë do të ishte nëse funksione të ngjashme do të ishin të pranishme edhe në mjetet më të pjekura me të cilat kemi punuar për një kohë të gjatë. Një nga veçoritë e reja që do të doja të shihja në PostgreSQL ishte koherenca e regjistrit të personalizuar sipas lidhjes në të gjithë klasterin. Dhe siç doli, ne tashmë e kemi atë, dhe sot dëshirojmë të ndajmë me ju informacionin se si mund ta përdorni atë.
Pse më nevojitet kjo?
Si një klaster duhet të sillet varet nga aplikacioni juaj. Merrni si shembull një aplikacion për pagesat. Ju nevojitet një përputhje e plotë në klaster, prandaj do të duhet të aktivizoni komitetet sinkrone, në mënyrë që databaza juaj të presë derisa të bëhen të gjitha ndryshimet. Megjithatë, nëse aplikacioni juaj është një rrjet social që po zhvillohet shpejt, sigurisht që do të preferoni një reagim të shpejtë me përputhje të plotë. Për ta arritur këtë, mund të përdorni komitetet asinkrone në klasterin tuaj.
Njoftohuni me kompromisin
Ju do të duhet të bëni një kompromis mes përputhshmërisë së të dhënave dhe performancës. PostgreSQL ecën nga përputhshmëria, pasi konfigurimi standart në këtë rast është i parashikueshëm dhe pa surpriza të papritura. Tani le të njihemi me kompromiset.
Kompromisi 1: Performanca
Nëse klusteri PostgreSQL nuk ka nevojë për koherencë, ai mund të funksionojë asinkronisht. Shkruarja bëhet te lideri i klasterit, dhe përkopjet e tij do të marrin përditësime pas disa milisekondash. Kur klusteri PostgreSQL kërkon koherencë, ai duhet të funksionojë sinkronisht. Shkruarja do të bëhet te lideri i klasterit, i cili do t'i dërgojë përkopjeve përditësimin dhe do të presë konfirmimin që secila ka kryer shkruarjen, para se të dërgojë konfirmimin te klienti që iniciatoi shkruarjen, në lidhje me suksesin e saj. Një ndryshim praktik midis këtyre qasjeve është se metoda asinkrone kërkon dy skacera në rrjet, ndërsa ajo sinkrone katër.
Kompromisi 2: Koherenca
Rezultati në rast të dështimit të liderit në këto dy qasje do të jetë gjithashtu i ndryshëm. Nëse puna kryhet asinkronisht, atëherë në rast të një gabimi të tillë, jo të gjitha regjistrimet do të konfirmohen nga replikat. Sa do të humbasë? Varet nga vetë aplikacioni dhe efikasiteti i replikimit. Replikimi Compose do të pengojë replikën të bëhet lider nëse sasia e informacionit në të është 1 MB më pak se në lider, që do të thotë se potencialisht mund të humben deri në 1 MB të regjistrimeve gjatë punës asinkrone.
NĂ« modalitetin sinkron kjo nuk ndodh. NĂ«se lideri dĂ«shton, tĂ« gjitha replikat pĂ«rditĂ«sohen, pasi çdo regjistrim i konfirmuar nga lideri duhet tĂ« konfirmohet nĂ« replikat. KĂ«tu Ă«shtĂ« â konsistenca.
Përgjigjja sinkronike ka kuptim të përdoret në një aplikacion për pagesën e faturave, ku qëndrueshmëria ka një avantazh të qartë në gjetjen e një kompromisi midis qëndrueshmërisë dhe performancës. Më e rëndësishmja për një aplikacion të tillë janë të dhënat e vlefshme. Tani kujtoni për një rrjet social, ku qëllimi kryesor është të ruhet vëmendja e përdoruesit duke iu përgjigjur kërkesave sa më shpejt. Në këtë rast, performanca me më pak hopa rrjeti dhe më pak pritje për komitete do të jetë në prioritet. Megjithatë, kompromisi midis performancës dhe qëndrueshmërisë nuk është i vetmi që duhet të mendohet.
Kompromisi 3: DĂ«shtimet
Ăsht shumĂ« e rĂ«ndĂ«sishme tĂ« kuptohet se si sillet klusteri gjatĂ« njĂ« dĂ«shtimi. Le tĂ« marrim njĂ« situatĂ« ku njĂ« ose mĂ« shumĂ« replika dĂ«shtojnĂ«. Kur angazhimet pĂ«rpunohen asinkronisht, lideri do tĂ« vazhdojĂ« tĂ« funksionojĂ«, duke pranuar dhe pĂ«rpunuar regjistrime pa pritur pĂ«r replikat e humbura. Kur replikat kthehen nĂ« kluster, ato arrijnĂ« liderin. Me replikimin sinkron, nĂ«se replikat nuk pĂ«rgjigjen, lideri nuk do tĂ« ketĂ« zgjedhje tjetĂ«r dhe do tĂ« vazhdojĂ« tĂ« pret konfirmimin e angazhimit deri sa replika tĂ« kthehet nĂ« kluster dhe tĂ« mund tĂ« pranojĂ« dhe konfirmojĂ« regjistrimin.
Një lidhje për transaksion?
Ădo aplikacion ka nevojĂ« pĂ«r njĂ« lloj tĂ« veçantĂ« kombinimi tĂ« konsistencĂ«s dhe performancĂ«s. NĂ«se natyrisht nuk Ă«shtĂ« aplikacioni ynĂ« pĂ«r pagesa, tĂ« cilin ne e imagjinojmĂ« si plotĂ«sisht tĂ« konsoliduar, ose aplikacioni ynĂ« pĂ«r rrjetet sociale, qĂ« Ă«shtĂ« pothuajse etereal. NĂ« tĂ« gjithĂ« rastet e tjera, do tĂ« ketĂ« momente kur disa operacione duhet tĂ« jenĂ« sinkrone dhe disa asinkrone. Mund tĂ« mos dĂ«shironit qĂ« sistemi tĂ« presĂ« derisa njĂ« mesazh i dĂ«rguar nĂ« bisedĂ« tĂ« komitohet, por nĂ«se nĂ« tĂ« njĂ«jtin aplikacion kalon njĂ« pagesĂ«, atĂ«herĂ« do tĂ« duhet tĂ« presĂ«sh.
TĂ« gjitha kĂ«to vendime, natyrisht, i merr zhvilluesi i aplikacionit. Vendimet e duhura pĂ«r atĂ« se kur tĂ« aplikoni njĂ« qasje tĂ« caktuar do tĂ« ndihmojnĂ« nĂ« nxjerrjen e maksimumit nga klasteri. ĂshtĂ« e rĂ«ndĂ«sishme qĂ« zhvilluesi tĂ« mund tĂ« kalojĂ« midis tyre nĂ« nivelin SQL pĂ«r lidhjet dhe pĂ«r transaksionet.
Sigurimi i kontrollit në praktikë
Në mënyrë default, PostgreSQL siguron konsistencë. Kjo kontrollohet nga parametri i serverit synchronous_commit. Nga default, ai është në pozitën në, por ka edhe tre variante të tjera: local, remote_write ose off.
Kur vendosni parametrin në off ndalen të gjitha komitetet sinjkrone, madje edhe në sistemin lokal. Parametri në local përcakton modin sinjkrone për sistemin lokal, por regjistrimet në replika kryhen asinkronisht. Remote_write shkon edhe më thellë: regjistrimet në replika kryhen asinkronisht, por kthehen, kur replika ka pranuar regjistrimin, por nuk e ka shkruar atë në disk.
Duke shqyrtuar gamĂ«n e mundĂ«sive ekzistuese, ne zgjedhim sjelljen dhe, duke mbajtur parasysh se nĂ« â janĂ« regjistrime sinjkrone, ne do tĂ« zgjedhim local pĂ«r komitetet asinkrone nĂ« rrjet, duke lĂ«nĂ« komitetet lokale si sinjkrone.
Tani, ne do t'ju tregojmĂ« se si tĂ« konfiguroni kĂ«tĂ« shpejt, por imagjinoni se ne kemi instaluar synchronous_commit nĂ« local pĂ«r serverin. Ne u pyetĂ«m, a Ă«shtĂ« e mundur tĂ« ndryshohet parametri synchronous_commit nĂ« fluturim, dhe rezultoi se jo vetĂ«m qĂ« Ă«shtĂ« e mundur, por ka madje dy mĂ«nyra pĂ«r tĂ« bĂ«rĂ« kĂ«tĂ«. E para â Ă«shtĂ« tĂ« caktoni sesionin e lidhjes tuaj nĂ« kĂ«tĂ« mĂ«nyrĂ«:
SET SESSION synchronous_commit TO ON;
// Shkruani këtuTë gjitha regjistrimet e mëpasshme në sesion do të konfirmojnë operacionet e regjistrimit për replikat, para se t'i kthejnë një përgjigje pozitive klientit të lidhur. Nëse, sigurisht, nuk e ndryshoni përsëri cilësimin synchronous_commit mund të hiqet pjesa SESSION në ekip, pasi do të jetë me vlerë të paracaktuar.
Mënyra e dytë është e mirë kur thjesht dëshiron të sigurohesh që po merr replikimin sinqetë për një transaksion. Në shumë baza të dhënash të brezit "NoSQL" konceptet e transaksioneve nuk ekzistojnë, por ato ekzistojnë në PostgreSQL. Në këtë rast, nis një transaksion dhe pastaj vendos synchronous_commit në në para se të kryesh shkrimin për transaksionin. COMMIT do të regjistrojë transaksionin duke përdorur çdo vlerë parametri synchronous_commit, e cila ishte vendosur në atë moment, por është më mirë të përcaktosh variablën paraprakisht për të siguruar që zhvilluesit e tjerë të kuptojnë se shkrimet nuk janë asinkrone.
BEGIN;
SET LOCAL synchronous_commit TO ON;
// Shkrimet tuaja këtu
COMMIT; Të gjitha komitetet e transaksioneve tani do të konfirmohen, siç janë regjistruar në replika para se baza e të dhënave të kthejë një përgjigje pozitive për klientin e lidhur.
Konfigurimi i PostgreSQL
Para kësaj, ne imagjinonim sistemin PostgreSQL me synchronous_commit, i vendosur në local. Për ta bërë këtë realitet në anën e serverit, do t'ju duhet të vendosni dy parametra konfigurimi të serverit. Një tjetër parametr synchronous_standby_names do të hyjë në fuqi kur synchronous_commit të jetë në në. Ai përcakton se cilat replikat kanë të drejtë të bëjnë komitete sinkronike, dhe ne do ta vendosim atë në *, që do të thotë angazhimi i të gjitha replikave. Këto vlera zakonisht konfigurohen në nëpërmjet shtimit të:
synchronous_commit = local
synchronous_standby_names='*'Duke vendosur parametrin synchronous_commit në vlerë local, ne krijojmë një sistem ku disqet lokale mbeten sinkronike, por komitetet e replikave rrjet më default janë asinkronike. Nëse, sigurisht, nuk vendosim t'i bëjmë këto komitete sinkronike, siç tregohet më sipër.
Nëse keni ndjekur zhvillimin e , mund të keni vënë re disa ndryshime të fundit (, ), të cilat lejuan përdoruesit e Governor të testojnë këto parametra dhe të kontrollojnë koherencën e tyre.
KĂ«tu janĂ« disa fjalĂ«âŠ
Në fakt, javën e kaluar do t'ju thosha se ishte e pamundur të bëje një optimizim kaq të detajuar të PostgreSQL. Atëherë, Kurt, një anëtar i ekipit të platformës Compose, insistoi që një mundësi e tillë ekzistonte. Ai qetësoi kundërshtimet e mia dhe gjeti në dokumentacionin e PostgreSQL :
Ky kyç mund tĂ« ndryshohet nĂ« çdo kohĂ«. Sjellja pĂ«r çdo transaksion pĂ«rcaktohet nga konfigurimi qĂ« Ă«shtĂ« nĂ« fuqi gjatĂ« komitit. Prandaj, Ă«shtĂ« e mundur dhe e dobishme qĂ« pĂ«r disa transaksione komitĂ«t tĂ« realizohen nĂ« mĂ«nyrĂ« sinkrone, ndĂ«rsa pĂ«r tĂ« tjerĂ«t â nĂ« mĂ«nyrĂ« asinkrone. PĂ«r shembull, pĂ«r tĂ« detyruar njĂ« multistatement transaksion tĂ« bĂ«jĂ« komitĂ« asinkrone, kur vlera e parametrave tĂ« paracaktuar Ă«shtĂ« e kundĂ«rt, vendosni SET LOCAL synchronous_commit TO OFF nĂ« transaksion.
Me një modifikim të tillë të vogël në skedarin e konfigurimit, u dhamë përdoruesve mundësinë për të kontrolluar koherencën dhe performancën e tyre.
Burimi: habr.com
