La traduko de la artikolo estis preparita specife por la kursanoj . Ĉu vi interesiĝas disvolvi ĉi tiun direkton? Ni invitas vin al , kie ni detale parolas pri la programo, trajtoj de la reta formato, kompetentecoj kaj karieraj perspektivoj, kiuj atendas diplomiĝintojn post trejnado.
PostgreSQL kaj konekto-specifaj skribaj konsekvencaj agordoj
Ni devas trakti multajn datumbazojn en Compose, kio donas al ni la ŝancon pli bone koni iliajn funkciojn kaj mankojn. Dum ni lernas ami la funkciojn de novaj datumbazoj, ni foje komencas pensi, kiel agrable estus, se ĉi tiuj funkcioj ĉeestus en pli maturaj iloj, kun kiuj ni jam delonge laboris. Unu el la novaj funkcioj, kiujn mi volis vidi en PostgreSQL, estis agordebla skribo-po-koneksa konsistenco tra la tuta areto. Kaj kiel rezultas, ni jam havas ĝin, kaj hodiaŭ ni volas dividi kun vi informojn pri kiel vi povas uzi ĝin.
Kial mi bezonas ĝin?
Kiel la areto devus konduti dependas de via aplikaĵo. Prenu, ekzemple, aplikaĵon por pagi fakturojn. Vi bezonos XNUMX% konsekvencon tra la areto, do vi devos ebligi sinkronajn komitaĵojn por ke via datumbazo atendu ĉiujn ŝanĝojn. Tamen, se via aplikaĵo estas rapide kreskanta socia reto, tiam vi certe preferos rapidan respondon al XNUMX% konsistenco. Por atingi ĉi tion, vi povas uzi nesinkronajn komitojn sur via areto.
Renkontu Kompromison
Vi devas fari interŝanĝon inter datuma konsistenco kaj rendimento. PostgreSQL malproksimiĝas de konsistenco ĉar la defaŭlta agordo estas antaŭvidebla kaj libera de neatenditaj surprizoj. Kaj nun ni konatiĝu kun la kompromisoj.
Komerco 1: Efikeco
Se PostgreSQL-areo ne postulas konsistencon, ĝi povas bone funkcii nesinkrone. La skribo estas farita al la clustergvidanto, kaj ĝisdatigoj estos senditaj al ĝiaj kopioj post kelkaj milisekundoj. Kiam PostgreSQL-areto bezonas konsistencon, ĝi devas funkcii sinkrone. La skribo estos farita ĉe la clustergvidanto, kiu sendos ĝisdatigon al la kopioj kaj atendos konfirmon, ke ĉiu skribis antaŭ sendi konfirmon al la kliento, kiu iniciatis la skribadon, ke ĝi sukcesis. La praktika diferenco inter tiuj aliroj estas ke la nesinkrona metodo postulas du retajn saltojn, dum la sinkrona metodo postulas kvar.
Komerco 2: Konsistenco
La rezulto en kazo de malsukceso en la laboro de la gvidanto en ĉi tiuj du aliroj ankaŭ estos malsama. Se la laboro estas farita nesinkrone, tiam kiam tia eraro okazas, ne ĉiuj rekordoj estos faritaj per kopioj. Kiom estos perdita? Dependas de la apliko mem kaj la efikeco de reproduktado. Komponita reproduktado malhelpos kopion iĝi gvidanto se la kvanto de informoj en ĝi estas 1 MB malpli ol en la ĉefo, tio estas, ĝis 1 MB da rekordoj eble povas esti perditaj dum nesinkrona operacio.
Ĉi tio ne okazas en sinkrona reĝimo. Se la gvidanto malsukcesas, ĉiuj kopioj estas ĝisdatigitaj, ĉar ĉiu rekordo agnoskita sur la gvidanto devas esti agnoskita en la kopioj. Jen ĝi estas - konsistenco.
Sinkrona konduto havas sencon en faktur-paga aplikaĵo kie konsistenco havas klaran avantaĝon en kompromisoj inter konsistenco kaj efikeco. La plej grava afero por tia aplikaĵo estas validaj datumoj. Nun pensu pri socia reto, en kiu la ĉefa tasko estas konservi la atenton de la uzanto respondante al petoj kiel eble plej rapide. En tia kazo, agado kun malpli da retaj saltoj kaj malpli da kommit-atendoj estus prioritatita. Tamen, la kompromiso inter rendimento kaj konsistenco ne estas la sola pri kiu pensi.
Komerco 3: Fiaskoj
Estas tre grave kompreni kiel la areto kondutas dum malsukceso. Konsideru situacion kie unu aŭ pluraj kopioj malsukcesas. Kiam kommits estas procesitaj nesinkrone, la gvidanto daŭre funkcios, tio estas, akceptos kaj prilaboros rekordojn sen atendi mankantajn kopiojn. Kiam la kopioj revenas al la areto, ili atingas la gvidanton. Kun sinkrona reproduktado, se la kopioj ne respondas, tiam la gvidanto havas neniun elekton ol daŭri atendi ke la transdono por esti konfirmita ĝis la kopio revenas al la areto kaj povas akcepti kaj transigi la skribon.
Unu konekto por transakcio?
Ĉiu aplikaĵo bezonas specifan specon de kombinaĵo de konsistenco kaj rendimento. Krom se, kompreneble, ĝi estas nia faktur-paganta programo, kiun ni imagas esti tute konsekvenca, aŭ nia preskaŭ efemera socia reto-aplikaĵo. En ĉiuj aliaj kazoj, estos tempoj kiam iuj operacioj devas esti sinkronaj kaj iuj devas esti nesinkronaj. Vi eble ne volas, ke la sistemo atendu ĝis la mesaĝo sendita al la babilejo estas farita, sed se estas pago en la sama aplikaĵo, tiam vi devos atendi.
Ĉiuj ĉi tiuj decidoj estas, kompreneble, faritaj de la programisto de la aplikaĵo. Preni la ĝustajn decidojn pri kiam apliki unu aŭ la alian aliron helpos vin akiri la plej grandan parton de via areto. Gravas, ke la programisto povas ŝanĝi inter ili ĉe la SQL-nivelo por konektoj kaj por transakcioj.
Certigante kontrolon en la praktiko
PostgreSQL devigas konsistencon defaŭlte. Ĉi tio estas kontrolata de la agordo de la servilo synchronous_commit. Defaŭlte ĝi estas en pozicio on, sed ĝi havas tri aliajn eblojn: local, remote_write aŭ off.
Kiam oni fiksas la parametron al off ĉesigas ĉiujn sinkronajn komitaĵojn, eĉ sur la loka sistemo. La agordo en loka specifas sinkronan reĝimon por la loka sistemo, sed skriboj al kopioj estas nesinkronaj. Remote_write iras eĉ plu: skriboj al kopioj estas faritaj nesinkrone, sed estas resenditaj kiam la kopio akceptis la skribon sed ne skribis ĝin al disko.
Konsiderante la disponeblan gamon da ebloj, ni elektas konduton kaj, konsiderante tion on estas sinkronaj registradoj, ni elektos local por nesinkronaj retaj komitaĵoj, dum lasante lokajn komitaĵojn sinkronaj.
Nun ni diros al vi kiel agordi ĝin tuj, sed imagu, ke ni starigis synchronous_commit в local por la servilo. Ni scivolis ĉu eblas ŝanĝi la parametron synchronous_commit sur la flugo, kaj montriĝis, ke ĝi ne nur eblas, sed ekzistas eĉ du tutaj manieroj por ĉi tio. La unua estas agordi la seancon de via konekto jene:
SET SESSION synchronous_commit TO ON;
// Your writes go hereĈiuj postaj skribaĵoj al la sesio agnoskos skribojn al kopioj antaŭ ol redoni pozitivan rezulton al la konektita kliento. Krom se vi kompreneble ŝanĝas la agordon synchronous_commit denove. Vi povas preterlasi parton SESSION en la komando kiel ĝi estos en la defaŭlta valoro.
La dua maniero estas bona kiam vi nur volas certigi, ke vi ricevas sinkronan reproduktadon por ununura transakcio. En multaj datumbazoj de la generacio "NoSQL", la koncepto de transakcioj ne ekzistas, sed ĝi ekzistas en PostgreSQL. En ĉi tiu kazo, vi komencas transakcion kaj poste agordas synchronous_commit в on antaŭ ol fari transakcion. COMMIT faros la transakcion uzante ajnan parametran valoron synchronous_commit, kiu estis agordita tiutempe, kvankam estas plej bone agordi la variablon antaŭe por certigi, ke aliaj programistoj komprenu, ke skribaĵoj ne estas nesinkronaj.
BEGIN;
SET LOCAL synchronous_commit TO ON;
// Your writes go here
COMMIT; Ĉiuj transakciaj transakcioj nun estos konfirmitaj kiel skribitaj al kopioj antaŭ ol la datumbazo resendas pozitivan respondon al la konektita kliento.
Agordante PostgreSQL
Ĝis nun, ni imagis sistemon PostgreSQL kun synchronous_commitstarigis local. Por ke ĉi tio estu realisma ĉe la servilo, vi devos agordi du servilajn agordajn opciojn. Alia opcio synchronous_standby_names efikos kiam synchronous_commit eniros on. Ĝi determinas, kiuj kopioj estas elekteblaj por sinkronaj komitaĵoj, kaj ni agordos ĝin *, kio signifos ke ĉiuj kopioj estas implikitaj. Ĉi tiuj valoroj estas kutime agordita en aldonante:
synchronous_commit = local
synchronous_standby_names='*'Agordante la parametron synchronous_commit en signifon local, ni kreas sistemon kie lokaj diskoj restas sinkronaj, sed retaj kopioj estas nesinkronaj defaŭlte. Krom se, kompreneble, ni decidas igi ĉi tiujn komitaĵojn sinkronaj, kiel montrite supre.
Se vi sekvis la evoluon , vi eble rimarkis kelkajn lastatempajn ŝanĝojn (, ) kiu permesis al Guberniestro-uzantoj testi ĉi tiujn agordojn kaj kontroli ilian konsistencon.
Kelkaj pliaj vortoj...
Antaŭ nur semajno, mi estus dirinta al vi, ke estas neeble tiel fajne agordi PostgreSQL. Estis tiam ke Kurt, membro de la Compose platformteamo, insistis ke ekzistis tia ebleco. Li trankviligis miajn obĵetojn kaj trovis en la PostgreSQL-dokumentado :
Ĉi tiu agordo povas esti ŝanĝita iam ajn. La konduto por iu ajn transakcio estas determinita de la fikso en efiko ĉe la transdono. Tial, estas eble kaj utile ke iuj transakcioj estu faritaj sinkrone kaj ke aliaj estu faritaj nesinkrone. Ekzemple, devigi unu multistatement transakcio por fari kommits nesinkrone kiam la defaŭlta valoro de la parametro estas kontraŭa, agordu SET LOCAL synchronous_commit TO OFF en transakcio.
Kun ĉi tiu eta modifo al la agorda dosiero, ni donis al uzantoj la kapablon kontroli ilian konsekvencon kaj efikecon.
fonto: www.habr.com