Përkthimi i artikullit është përgatitur veçanërisht për studentët e kursit . A është interesante të zhvilloheni në këtë fushë? Ju ftojmë në , ku ne flasim në detaje për programin, veçoritë e formatit online, kompetencat dhe perspektivat e karrierës që presin të diplomuarit pas përfundimit të shkollimit.
PostgreSQL dhe konfigurimet e qëndrueshmërisë së shënimeve për çdo lidhje të caktuar
Ne në Compose përballemi me shumë baza të dhënash, dhe pikërisht kjo na ofron mundësinë të njohim më mirë funksionalitetin dhe mangësitë e tyre. Ndërsa mësojmë të duam veçoritë funksionale të bazave të reja të dhënash, ndonjëherë fillojmë të mendojmë se si do të ishte mirë nëse funksione të tilla do të ishin gjithashtu të pranishme në mjetet më të drejta me të cilat punojmë prej një kohë të gjatë. Një nga veçoritë e reja që do të doja të shihja në PostgreSQL ishte përputhja e personalizueshme e shkruarjes për lidhjen në të gjithë klasterin. Dhe siç duket, ne tashmë e kemi atë, dhe sot duam të ndajmë me ju informacionin se si mund ta përdorni atë.
Pse më duhet kjo?
Sesi duhet të veprojë klasteri varet nga aplikacioni juaj. Merrni si shembull një aplikacion për pagesat e faturave. Ju nevojitet një përputhje e plotë në klaster, prandaj do t'ju duhet të aktivizoni kommitetët sinkronë, për të pritur që të bëhen të gjitha ndryshimet. Megjithatë, nëse aplikacioni juaj është një rrjet social që po zhvillohet shpejt, ju me siguri do të preferoni një përgjigje të shpejtë mbi përputhshmërinë e plotë. Për ta arritur këtë, mund të përdorni kommitetët asinkronë në klasterin tuaj.
Njohtuni me kompromisin
Ju do të duhet të bëni një kompromis mes përputhshmërisë së të dhënave dhe performancës. PostgreSQL avancón nga përputhshmëria, pasi konfigurimi standard në këtë rast del të jetë parashikues dhe pa surpriza të papritura. Tani le të njohim kompromiset.
Kompromisi 1: Performanca
Nëse klusteri PostgreSQL nuk ka nevojë për gjithëpërfshirje, ai mund të funksionojë plotësisht asinkron. Shkruhet te lideri i klasterit, dhe përkopjet e tij do të dërgohen për azhurnim disa milisekonda më vonë. Kur klusteri PostgreSQL kërkon gjithëpërfshirje, ai duhet të funksionojë sinkron. Shkruhet te lideri i klasterit, i cili dërgon azhurnimin te përkopjet dhe pret konfirmimin se çdo përkopje ka kryer regjistrimin përpara se t'i dërgojë konfirmimin klientit që ka iniciuar shkruan, se ajo kaloi me sukses. Diferenca praktike midis këtyre qasjeve është se metoda asinkrone ka nevojë për dy skakanime në rrjet, ndërsa ajo sinkrone ka katër.
Kompromisi 2: Gjatëpërfshirja
Rezultati në rast të dështimit të liderit në këto dy qasje gjithashtu do të jetë ndryshe. Nëse operacioni kryhet asinkronisht, atëherë, në rast të një gabimi, jo të gjitha regjistrimet do të jenë përfshirë nga përkopjet. Sa do të humbasë? Varet nga aplikacioni vetë dhe efekti i përkopjimit. Përkopjimi i Compose do të parandalojë përkopjen të bëhet lider nëse sasia e informacionit në të është 1 MB më e vogël se ajo në lider, që do të thotë se potencialisht mund të humbasin deri në 1 MB regjistrimesh gjatë funksionimit asinkron.
Në modin sinkron, kjo nuk ndodh. Nëse lideri dështon, të gjitha përkopjet azhurnohen, pasi çdo regjistrim i konfirmuar te lideri duhet të konfirmohet në përkopje. Këtu është – gjithëpërfshirja.
Kjo sjellje sinkrone ka kuptim të përdoret në një aplikacion për pagesa, ku gjithëpërfshirja ka një avantazh të dukshëm në kërkimin e kompromisit midis gjithëpërfshirjes dhe performancës. E rëndësishme për një aplikacion të tillë janë të dhënat valide. Dhe tani kujtoni për rrjetin social, ku detyra kryesore është të mbani vëmendjen e përdoruesit, duke u përgjigjur sa më shpejt të jetë e mundur. Në këtë rast, performanca me më pak skakanime në rrjet dhe më pak pritje për konfirmimet do të jetë prioritet. Megjithatë, kompromisi midis performancës dhe gjithëpërfshirjes nuk është e vetmja gjë për të cilën duhet të mendoni.
Kompromisi 3: Dështimet
Është shumë e rëndësishme të kuptojmë se si e drejton klasteri sjelljen e tij gjatë një crash-i. Le të shqyrtojmë situatën kur një ose më shumë replika dështojnë. Kur angazhimet përpunohen asinkronisht, lideri do të vazhdojë të funksionojë, dmth do të pranojë dhe përpunojë shënimet pa pritur për replikat që mungojnë. Kur replikat kthehen në klaster, ato e ndjekin liderin. Në rastin e replikimit sinkron, nëse replikat nuk përgjigjen, lideri nuk do të ketë zgjidhje dhe do të vazhdojë të presë konfirmimin e angazhimit derisa rekorda të kthehet në klaster dhe të jetë në gjendje të pranojë dhe të konfirmojë shënimin.
Një lidhje për transaksion?
Çdo aplikacion ka nevojë për një lloj të veçantë të kombinimit të koherencës dhe performancës. Nëse sigurisht që nuk është aplikacioni ynë për pagesat e llogarive, të cilin e imagjinojmë si plotësisht koherent, apo aplikacioni ynë pothuajse efemer për rrjetin social. Në të gjitha rastet e tjera, do të ketë momente kur disa operacione duhet të jenë sinkrone, ndërsa të tjerat asinkrone. Ndoshta nuk dëshironi që sistemi të presë derisa një mesazh i dërguar në bisedë të angazhohet, por nëse në të njëjtin aplikacion bëhet një pagesë, atëherë do të duhet të presim.
Të gjitha këto vendime, sigurisht, merr zhvilluesi i aplikacionit. Vendimet e duhura për kur të përdoren qasje të ndryshme do të ndihmojnë të nxirren maksimumin nga klasteri. Është e rëndësishme që zhvilluesi të jetë në gjendje të kalojë midis tyre në nivelin SQL për lidhjet dhe për transaksionet.
Sigurimi i kontrollit në praktikë
Me default, PostgreSQL ofron koherencë. Kjo kontrollohet nga parametri i serverit synchronous_commit. Me default, ai është në pozicionin në, por ka tre opsione të tjera: local, remote_write ose off.
Kur parametrat janë vendosur në off të gjitha angazhimet sinkrone do të ndalen, madje edhe në sistemin lokal. Parametri në lokal përcakton modin sinkron për sistemin lokal, por shënimet në replika bëhen asinkronisht. Remote_write shkon edhe më tej: shënimet në replika bëhen asinkronisht, por kthehen kur replika pranon shënimin, por jo kur e regjistron atë në disk.
Duke marrë parasysh gamën e disponueshme të opsioneve, ne zgjedhim sjelljen dhe, duke mbajtur mend se në – është shënime sinkrone, ne do të zgjedhim local për angazhimet asinkrone përmes rrjetit, duke lënë të angazhuarit lokalë sinkrone.
Tani, do të tregojmë se si ta konfiguroni këtë në një çast, por imagjinoni se kemi instaluar synchronous_commit në local për serverin. Na erdhi në mendje, a është e mundur të ndryshohet parametri synchronous_commit në flakë, dhe doli se jo vetëm që është e mundur, por për këtë ka edhe dy mënyra të plota. E para – është të caktoni sesionin tuaj të lidhjes si më poshtë:
SET SESSION synchronous_commit TO ON;
// Shkruani këtuTë gjitha shkrimet e mëtejshme në sesion do të konfirmojnë operacionet e shkrimit për replikat, para se të kthejnë një rezultat pozitiv për klientin e lidhur. Nëse, sigurisht, nuk e ndryshoni përsëri konfigurimin synchronous_commit Mund të injoroni pjesën SESSION në komandë, pasi do të jetë në vlerën e parazgjedhur.
Mënyra e dytë është e mirë kur thjesht doni të jeni të sigurt se po merrni replikim sinkron për një transaksion. Në shumë bazat e të dhënave të brezit "NoSQL" nuk ekziston koncepti i transaksioneve, por ai ekziston në PostgreSQL. Në këtë rast, filloni një transaksion dhe pastaj vendosni synchronous_commit në në para ekzekutimit të shkrimit për transaksionin. KREJT do të regjistrojë transaksionin, duke përdorur çdo vlerë të parametrin synchronous_commit, e cila ishte vendosur në atë moment, megjithatë është më mirë të caktoni ndryshoren paraprakisht për të siguruar që zhvilluesit e tjerë të kuptojnë se shkrimet nuk janë asinkrone.
BEGIN;
SET LOCAL synchronous_commit TO ON;
// Shkruani këtu
COMMIT; Të gjitha komitetet e transaksioneve tani do të konfirmohen, si të regjistruara në replikat para se baza e të dhënave të kthejë një përgjigje pozitive për klientin e lidhur.
Konfigurimi i PostgreSQL
Më parë, ne e imagjinonim sistemin PostgreSQL me synchronous_commit, vendosur në local. Për ta bërë këtë të mundur në anën e serverit, duhet të vendosni dy parametra të konfigurimit të serverit. Një parametr tjetër synchronous_standby_names do të hyjë në fuqi kur synchronous_commit të jetë në në. Ai përcakton cilat replika kanë të drejtë për komitetet sinkrone, dhe ne do ta vendosim atë në *, e cila do të thotë përfshirjen e të gjitha replikave. Këto vlera zakonisht konfigurohen në duke shtuar:
synchronous_commit = local
synchronous_standby_names='*'Duke vendosur parametrin synchronous_commit në vlerën local, ne krijojmë një sistem në të cilin disqet lokale mbeten sinkrone, por komitetet e replikave në rrjet janë parazgjedhur asinkrone. Nëse, sigurisht, nuk vendosim të bëjmë këto komitete sinkrone, siç është treguar më sipër.
Nëse keni ndjekur zhvillimin e , mund të keni vënë re disa ndryshime të fundit., ), që lejuan përdoruesit e Governor të testojnë këto parametra dhe të kontrollojnë koherencën e tyre.
Pak fjalë të tjera...
Vetëm një javë më parë, do t'ju isha thënë që ishte e pamundur të përshtaten kaq hollësisht PostgreSQL. Pikërisht atëherë, Kurt, një anëtar i ekipit të platformës Compose, insistonte se një mundësi e tillë ekzistonte. Ai qetësoi kundërshtimet e mia dhe gjeti në dokumentacionin e PostgreSQL :
Ky parametër mund të ndryshohet në çdo kohë. Sjellja për çdo transaksion përcaktohet nga konfigurimi që është në fuqi në momentin e komitit. Prandaj, është e mundur dhe e dobishme që për disa transaksione komitimet të bëhen sinkronikisht, derisa për të tjerat të jenë asinkronike. Për shembull, për të bërë një multistatement transaksion të bëjë komitimet asinkronike, kur vlera e parametrit të default ë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, i dhamë mundësinë përdoruesve të kontrollonin koherencën dhe performancën e tyre.
Burimi: habr.com
