Ang pagsasalin ng artikulo ay partikular na inihanda para sa mga mag-aaral ng kurso "Database". Interesado sa pagbuo sa direksyong ito? Iniimbitahan ka namin Bukas na Araw, kung saan pinag-uusapan namin nang detalyado ang tungkol sa programa, mga tampok ng online na format, mga kakayahan at mga prospect sa karera na naghihintay sa mga nagtapos pagkatapos ng pagsasanay.

Mga setting ng pagkakapare-pareho ng pagsulat ng PostgreSQL at partikular sa koneksyon
Sa Compose, nakikitungo kami sa maraming database, na nagbibigay sa amin ng pagkakataong maging mas pamilyar sa kanilang functionality at mga pagkukulang. Habang natututo tayong mahalin ang mga feature ng mga bagong database, minsan ay naiisip natin kung gaano kaganda kung may mga katulad na feature sa mga mas mature na tool na matagal na nating ginagamit. Isa sa mga bagong feature na gusto kong makita sa PostgreSQL ay ang configurable write consistency sa bawat koneksyon sa buong cluster. At sa lumalabas, mayroon na kami nito, at ngayon gusto naming ibahagi sa iyo ang impormasyon kung paano mo ito magagamit.

Bakit kailangan ko ito?

Kung paano dapat kumilos ang cluster ay depende sa iyong aplikasyon. Kunin, halimbawa, ang isang app sa pagbabayad ng bill. Kakailanganin mo ang XNUMX% na pagkakapare-pareho sa buong cluster, kaya kailangan mong paganahin ang mga synchronous commit upang maghintay ang iyong database para sa lahat ng mga pagbabago na magawa. Gayunpaman, kung ang iyong aplikasyon ay isang mabilis na lumalagong social network, malamang na mas gusto mo ang mabilis na pagtugon sa XNUMX% na pagkakapare-pareho. Para makamit ito, maaari mong gamitin ang mga asynchronous na commit sa iyong cluster.

Matugunan ang kompromiso

Kailangan mong gumawa ng mga tradeoff sa pagitan ng pagkakapare-pareho ng data at pagganap. Ang PostgreSQL ay lumalayo sa pagkakapare-pareho dahil ang default na configuration ay mahuhulaan at walang mga hindi inaasahang sorpresa. Ngayon tingnan natin ang mga kompromiso.

Tradeoff 1: Pagganap

Kung ang PostgreSQL cluster ay hindi nangangailangan ng consistency, maaari itong tumakbo nang asynchronously. Ang pagsulat ay ginawa sa cluster leader, at ang mga update ay ipapadala sa mga replika nito pagkalipas ng ilang millisecond. Kapag ang isang PostgreSQL cluster ay nangangailangan ng pare-pareho, dapat itong tumakbo nang sabay-sabay. Ang pagsulat ay gagawin sa pinuno ng cluster, na magpapadala ng update sa mga replika at maghihintay ng kumpirmasyon na nakasulat ang bawat isa bago magpadala ng kumpirmasyon sa kliyenteng nagpasimula ng pagsulat na ito ay matagumpay. Ang praktikal na pagkakaiba sa pagitan ng mga pamamaraang ito ay ang asynchronous na pamamaraan ay nangangailangan ng dalawang network hops, habang ang kasabay na pamamaraan ay nangangailangan ng apat.

Tradeoff 2: Consistency

Magiiba din ang resulta kung sakaling mabigo ang isang lider sa dalawang pamamaraang ito. Kung ang gawain ay isinagawa nang asynchronously, kung gayon kung ang gayong pagkakamali ay nangyari, hindi lahat ng mga tala ay gagawin ng mga replika. Magkano ang mawawala? Depende sa application mismo at sa kahusayan ng pagtitiklop. Pipigilan ng pagkopya ng pag-email ang isang replika na maging pinuno kung ang halaga ng impormasyon sa loob nito ay 1 MB na mas mababa kaysa sa pinuno, iyon ay, hanggang sa 1 MB ng mga tala ay maaaring potensyal na mawala sa panahon ng asynchronous na operasyon.

Hindi ito nangyayari sa synchronous mode. Kung nabigo ang pinuno, ang lahat ng mga replika ay ina-update, dahil ang anumang sulat na nakumpirma sa pinuno ay dapat na kumpirmahin sa mga replika. Ito ay consistency.

Ang kasabay na gawi ay may katuturan sa isang application sa pagsingil kung saan ang pagkakapare-pareho ay may malinaw na kalamangan sa trade-off sa pagitan ng pagkakapare-pareho at pagganap. Ang pinakamahalagang bagay para sa naturang aplikasyon ay wastong data. Ngayon isipin ang tungkol sa isang social network kung saan ang pangunahing gawain ay panatilihin ang atensyon ng user sa pamamagitan ng pagtugon sa mga kahilingan sa lalong madaling panahon. Sa kasong ito, magiging priyoridad ang pagganap na may mas kaunting network hops at mas kaunting paghihintay para sa mga commit. Gayunpaman, ang tradeoff sa pagitan ng pagganap at pagkakapare-pareho ay hindi lamang ang dapat mong isipin.

Trade-off 3: Mga Pag-crash

Napakahalagang maunawaan kung paano kumikilos ang isang kumpol sa panahon ng pagkabigo. Isaalang-alang ang isang sitwasyon kung saan nabigo ang isa o higit pang mga replika. Kapag ang mga commit ay naproseso nang asynchronous, ang pinuno ay patuloy na gagana, iyon ay, tanggapin at iproseso ang pagsusulat, nang hindi naghihintay ng nawawalang mga replika. Pagbalik ng mga replika sa kumpol, naabutan nila ang pinuno. Sa sabay-sabay na pagtitiklop, kung ang mga replika ay hindi tumugon, ang pinuno ay walang pagpipilian at patuloy na maghihintay para sa kumpirmasyon ng commit hanggang sa ang replica ay bumalik sa cluster at maaaring tanggapin at isagawa ang pagsulat.

Isang koneksyon sa bawat transaksyon?

Ang bawat aplikasyon ay nangangailangan ng iba't ibang uri ng kumbinasyon ng pagkakapare-pareho at pagganap. Maliban kung, siyempre, ito ay ang aming bill-paying app, na iniisip naming ganap na pare-pareho, o ang aming halos panandaliang social networking app. Sa lahat ng iba pang mga kaso, magkakaroon ng mga pagkakataon na ang ilang mga operasyon ay dapat na kasabay at ang ilan ay dapat na asynchronous. Maaaring hindi mo nais na maghintay ang system hanggang sa maisagawa ang isang mensahe na ipinadala sa chat, ngunit kung ang isang pagbabayad ay naproseso sa parehong aplikasyon, kakailanganin mong maghintay.

Ang lahat ng mga desisyong ito, siyempre, ay ginawa ng developer ng application. Ang paggawa ng mga tamang desisyon tungkol sa kung kailan gagamitin ang bawat diskarte ay makakatulong sa iyong masulit ang iyong cluster. Mahalaga na ang developer ay maaaring lumipat sa pagitan ng mga ito sa antas ng SQL para sa mga koneksyon at para sa mga transaksyon.

Pagtiyak ng kontrol sa pagsasanay

Bilang default, ang PostgreSQL ay nagbibigay ng pagkakapare-pareho. Ito ay kinokontrol ng parameter ng server synchronous_commit. Bilang default, nasa posisyon ito on, ngunit mayroon itong tatlong iba pang mga opsyon: local, remote_write o off.

Kapag nagtatakda ng parameter sa off lahat ng kasabay na commit ay itinigil, kahit na sa lokal na sistema. Tinukoy ng lokal na parameter ang kasabay na mode para sa lokal na sistema, ngunit ang pagsusulat sa mga replika ay ginagawa nang asynchronously. Remote_write napupunta pa: ang pagsusulat sa mga replika ay ginawa nang asynchronously, ngunit ibinabalik kapag tinanggap ng replica ang pagsulat ngunit hindi ito naisulat sa disk.

Sa pamamagitan ng pagsasaalang-alang sa magagamit na hanay ng mga opsyon, pumili kami ng isang pag-uugali at, isinasaisip iyon on – ito ay mga kasabay na pag-record, pipiliin namin local para sa mga asynchronous na commit sa network, habang iniiwan ang mga lokal na commit na kasabay.

Ngayon, sasabihin namin sa iyo kung paano i-set up ito sa isang sandali, ngunit isipin na nag-set up kami synchronous_commit в local para sa server. Nagtaka kami kung posible bang baguhin ang parameter synchronous_commit on the fly, at ito ay naging hindi lamang posible, mayroon pang dalawang paraan upang gawin ito. Ang una ay upang itakda ang session ng iyong koneksyon tulad ng sumusunod:

SET SESSION synchronous_commit TO ON;  
// Your writes go here

Ang lahat ng kasunod na pagsusulat sa session ay kikilalanin ang mga pagsusulat sa mga replika bago magbalik ng positibong resulta sa konektadong kliyente. Maliban na lang kung binago mo ang setting synchronous_commit muli. Maaari mong alisin ang bahagi SESSION sa utos dahil ito ay nasa default na halaga.

Ang pangalawang paraan ay mabuti kapag gusto mo lang tiyakin na makakakuha ka ng sabay-sabay na pagtitiklop para sa isang transaksyon. Sa maraming mga database ng henerasyon ng NoSQL ang konsepto ng mga transaksyon ay hindi umiiral, ngunit mayroon ito sa PostgreSQL. Sa kasong ito, magsisimula ka ng isang transaksyon at pagkatapos ay itakda synchronous_commit в on bago isagawa ang entry para sa transaksyon. COMMIT gagawin ang transaksyon gamit ang anumang halaga ng parameter synchronous_commit, na itinakda noong panahong iyon, bagama't pinakamainam na itakda ang variable sa harap upang matiyak na nauunawaan ng ibang mga developer na ang mga pagsusulat ay hindi asynchronous.

BEGIN;  
SET LOCAL synchronous_commit TO ON;  
// Your writes go here
COMMIT;  

Ang lahat ng mga transaksyon na ginawa ay makukumpirma na ngayon bilang nakasulat sa mga replika bago ang database ay nagbalik ng positibong tugon sa konektadong kliyente.

Pag-configure ng PostgreSQL

Bago ito, naisip namin ang isang PostgreSQL system na may synchronous_commit, naka-install sa local. Upang gawin itong makatotohanan sa panig ng server, kakailanganin mong magtakda ng dalawang opsyon sa pagsasaayos ng server. Isa pang parameter synchronous_standby_names ay darating sa sarili nitong kapag synchronous_commit ay papasok on. Tinutukoy nito kung aling mga replika ang karapat-dapat para sa mga sabaysabay na commit, at itatakda namin ito *, na nangangahulugan na ang lahat ng mga replika ay kasangkot. Ang mga halagang ito ay karaniwang naka-configure sa configuration file sa pamamagitan ng pagdaragdag:

synchronous_commit = local  
synchronous_standby_names='*'

Sa pamamagitan ng pagtatakda ng parameter synchronous_commit sa kahulugan local, gumawa kami ng system kung saan ang mga lokal na disk ay nananatiling magkasabay, ngunit ang mga network replica commit ay asynchronous bilang default. Maliban kung, siyempre, nagpasya kaming gawing magkasabay ang mga commit na ito, tulad ng ipinapakita sa itaas.

Kung sinusubaybayan mo ang pag-unlad Proyekto ng gobernador, maaaring napansin mo ang ilang kamakailang pagbabago (1, 2), na nagbigay-daan sa mga user ng Gobernador na subukan ang mga parameter na ito at subaybayan ang pagkakapare-pareho ng mga ito.

Ilang salita pa...

Isang linggo lang ang nakalipas, sasabihin ko sana sa iyo na imposibleng i-fine-tune ang PostgreSQL nang napakapino. Noon iginiit ni Kurt, isang miyembro ng Compose platform team, na may ganitong pagkakataon. Pinakalma niya ang aking mga pagtutol at natagpuan sa dokumentasyon ng PostgreSQL ang mga sumusunod:

Maaaring baguhin ang setting na ito anumang oras. Ang pag-uugali para sa anumang transaksyon ay tinutukoy ng setting na may bisa sa oras ng pag-commit. Samakatuwid, ito ay posible at kapaki-pakinabang para sa ilang mga transaksyon na gumawa ng sabay-sabay at para sa iba nang asynchronous. Halimbawa, upang pilitin ang isa multistatement transaksyon na gagawin ay commits asynchronously kapag ang default na halaga ng parameter ay kabaligtaran, set SET LOCAL synchronous_commit TO OFF sa isang transaksyon.

Sa kaunting pagbabago sa configuration file, binigyan namin ang mga user ng kontrol sa kanilang consistency at performance.

Pinagmulan: www.habr.com