Artikkelin käännös on tehty erityisesti kurssin opiskelijoille "Tietokanta". Oletko kiinnostunut kehittymään tähän suuntaan? Kutsumme sinut mukaan Avointen ovien päivä, jossa puhumme yksityiskohtaisesti ohjelmasta, verkkomuodon ominaisuuksista, osaamisesta ja uranäkymistä, jotka odottavat valmistuneita koulutuksen jälkeen.

PostgreSQL ja yhteyskohtaiset kirjoitusyhdenmukaisuusasetukset
Composella käsittelemme monia tietokantoja, mikä antaa meille mahdollisuuden tutustua paremmin niiden toimivuuteen ja puutteisiin. Kun opimme rakastamaan uusien tietokantojen ominaisuuksia, alamme joskus miettiä, kuinka mukavaa olisi, jos samanlaisia ​​ominaisuuksia olisi kypsemmissä työkaluissa, joiden kanssa olemme työskennelleet pitkään. Yksi uusista ominaisuuksista, jonka halusin nähdä PostgreSQL:ssä, oli konfiguroitava kirjoitusyhteensopivuus yhteyskohtaisesti koko klusterissa. Ja kuten kävi ilmi, meillä on se jo, ja tänään haluamme jakaa kanssasi tietoja siitä, kuinka voit käyttää sitä.

Miksi tarvitsen sitä?

Se, miten klusterin pitäisi toimia, riippuu sovelluksestasi. Otetaan esimerkiksi laskunmaksusovellus. Tarvitset XNUMX-prosenttisen johdonmukaisuuden koko klusterissa, joten sinun on otettava käyttöön synkroniset sitoumukset, jotta tietokanta odottaa kaikkien muutosten tekemistä. Jos sovelluksesi on kuitenkin nopeasti kasvava sosiaalinen verkosto, pidät todennäköisesti parempana nopeaa vastausta kuin XNUMX-prosenttista johdonmukaisuutta. Tämän saavuttamiseksi voit käyttää asynkronisia sitoumuksia klusterissasi.

Tapaa kompromissi

Sinun on tehtävä kompromisseja tietojen johdonmukaisuuden ja suorituskyvyn välillä. PostgreSQL siirtyy pois johdonmukaisuudesta, koska oletuskokoonpano on silloin ennustettavissa ja ilman odottamattomia yllätyksiä. Katsotaanpa nyt kompromisseja.

Kompromissi 1: Suorituskyky

Jos PostgreSQL-klusteri ei vaadi johdonmukaisuutta, se voi toimia asynkronisesti. Kirjoitus tehdään klusterin johtajalle, ja päivitykset lähetetään sen replikoihin muutamaa millisekuntia myöhemmin. Kun PostgreSQL-klusteri vaatii johdonmukaisuutta, sen on toimittava synkronisesti. Kirjoitus tehdään klusterin johtajalle, joka lähettää päivityksen replikoihin ja odottaa vahvistusta, että jokainen on kirjoittanut, ennen kuin lähettää vahvistuksen kirjoittamisen aloittaneelle asiakkaalle, että se onnistui. Käytännön ero näiden lähestymistapojen välillä on, että asynkroninen menetelmä vaatii kaksi verkkohyppää, kun taas synkroninen menetelmä vaatii neljä.

Kompromissi 2: Johdonmukaisuus

Tulos, jos johtaja epäonnistuu näissä kahdessa lähestymistavassa, on myös erilainen. Jos työ suoritetaan asynkronisesti, jos tällainen virhe tapahtuu, replikat eivät sitoudu kaikkia tietueita. Kuinka paljon häviää? Riippuu itse sovelluksesta ja replikoinnin tehokkuudesta. Kirjoitusreplikointi estää replikan muodostumisen johtajaksi, jos siinä on 1 Mt vähemmän tietoa kuin johtajassa, eli jopa 1 Mt tietueita voi mahdollisesti kadota asynkronisen toiminnan aikana.

Tätä ei tapahdu synkronisessa tilassa. Jos johtaja epäonnistuu, kaikki kopiot päivitetään, koska kaikki johtajan vahvistetut kirjoitukset on vahvistettava replikoissa. Tämä on johdonmukaisuutta.

Synkroninen käyttäytyminen on järkevää laskutussovelluksessa, jossa johdonmukaisuudella on selkeä etu johdonmukaisuuden ja suorituskyvyn välisessä kompromississa. Tärkein asia tällaiselle sovellukselle on kelvolliset tiedot. Ajattele nyt sosiaalista verkostoa, jossa päätehtävänä on pitää käyttäjän huomio vastaamalla pyyntöihin mahdollisimman nopeasti. Tässä tapauksessa suorituskyky, jossa on vähemmän verkkohyppejä ja vähemmän odotustoimia, on etusijalla. Suorituksen ja johdonmukaisuuden välinen kompromissi ei kuitenkaan ole ainoa, jota sinun on mietittävä.

Kompromissi 3: Kaatumiset

On erittäin tärkeää ymmärtää, kuinka klusteri käyttäytyy epäonnistumisen aikana. Harkitse tilannetta, jossa yksi tai useampi kopio epäonnistuu. Kun toimitukset käsitellään asynkronisesti, johtaja jatkaa toimintaansa eli hyväksyy ja käsittelee kirjoituksia odottamatta puuttuvia replikoita. Kun kopiot palaavat klusteriin, ne saavuttavat johtajan. Synkronisessa replikaatiossa, jos replikat eivät vastaa, johtajalla ei ole vaihtoehtoa ja hän odottaa vahvistusta, kunnes replika palaa klusteriin ja voi hyväksyä ja sitoa kirjoituksen.

Yksi yhteys tapahtumaa kohden?

Jokainen sovellus tarvitsee erilaisen johdonmukaisuuden ja suorituskyvyn yhdistelmän. Ellei se tietenkään ole laskunmaksusovelluksemme, jonka kuvittelemme olevan täysin johdonmukainen, tai melkein lyhytaikainen sosiaalisen verkostoitumisen sovellus. Kaikissa muissa tapauksissa tulee aikoja, jolloin joidenkin toimintojen on oltava synkronisia ja joidenkin asynkronisia. Et ehkä halua järjestelmän odottavan, kunnes chatiin lähetetty viesti on sitoutunut, mutta jos maksu käsitellään samassa sovelluksessa, sinun on odotettava.

Kaikki nämä päätökset tekee tietysti sovelluksen kehittäjä. Oikeiden päätösten tekeminen kunkin lähestymistavan käyttöajasta auttaa sinua saamaan kaiken irti klusteristasi. On tärkeää, että kehittäjä voi vaihtaa niiden välillä SQL-tasolla yhteyksiä ja tapahtumia varten.

Valvonnan varmistaminen käytännössä

Oletuksena PostgreSQL tarjoaa johdonmukaisuuden. Tätä ohjaa palvelinparametri synchronous_commit. Oletuksena se on paikallaan on, mutta siinä on kolme muuta vaihtoehtoa: local, remote_write tai off.

Kun parametri asetetaan arvoon off kaikki synkroniset toimitukset pysäytetään, jopa paikallisessa järjestelmässä. Paikallinen parametri määrittää paikallisen järjestelmän synkronisen tilan, mutta replikoihin kirjoitukset suoritetaan asynkronisesti. Remote_write menee vielä pidemmälle: kirjoitukset replikoihin tehdään asynkronisesti, mutta ne palautetaan, kun replika on hyväksynyt kirjoituksen, mutta ei ole kirjoittanut sitä levylle.

Harkitsemalla käytettävissä olevia vaihtoehtoja valitsemme käyttäytymisen ja pitäen sen mielessä on – Nämä ovat synkronisia tallenteita, me valitsemme local asynkronisille toimituksille verkon yli, kun taas paikalliset sitoumukset jätetään synkronisiksi.

Kerromme nyt, kuinka tämä määritetään hetkessä, mutta kuvittele, että määritämme sen synchronous_commit в local palvelimelle. Mietimme, olisiko mahdollista muuttaa parametria synchronous_commit lennossa, ja kävi ilmi, että se ei ole vain mahdollista, vaan siihen on jopa kaksi tapaa. Ensimmäinen on määrittää yhteytesi istunto seuraavasti:

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

Kaikki istunnon myöhemmät kirjoitukset kuitattavat replikoihin tehdyt kirjoitukset ennen kuin ne palauttavat positiivisen tuloksen yhdistetylle asiakkaalle. Ellei tietysti muuta asetusta synchronous_commit uudelleen. Voit jättää osan pois SESSION komennossa, koska se on oletusarvossa.

Toinen menetelmä on hyvä, kun haluat vain varmistaa, että saat synkronisen replikoinnin yhdelle tapahtumalle. Monissa NoSQL-sukupolven tietokannassa transaktioiden käsitettä ei ole olemassa, mutta PostgreSQL:ssä on. Tässä tapauksessa aloitat tapahtuman ja asetat sitten synchronous_commit в on ennen tapahtuman merkinnän suorittamista. COMMIT suorittaa tapahtuman käyttämällä mitä tahansa parametrin arvoa synchronous_commit, joka asetettiin tuolloin, vaikka on parasta asettaa muuttuja etukäteen varmistaaksesi, että muut kehittäjät ymmärtävät, että kirjoittaminen ei ole asynkronista.

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

Kaikki tapahtumasitoumukset vahvistetaan nyt replikoihin kirjoitetuiksi, ennen kuin tietokanta palauttaa positiivisen vastauksen yhdistetylle asiakkaalle.

PostgreSQL:n määrittäminen

Ennen tätä kuvittelimme PostgreSQL-järjestelmän synchronous_commit, asennettu sisään local. Jotta tämä olisi realistinen palvelinpuolella, sinun on määritettävä kaksi palvelimen määritysvaihtoehtoa. Vielä yksi parametri synchronous_standby_names tulee omakseen milloin synchronous_commit tulee olemaan on. Se määrittää, mitkä kopiot ovat oikeutettuja synkronisiin toimituksiin, ja asetamme sen *, mikä tarkoittaa, että kaikki kopiot ovat mukana. Nämä arvot on yleensä määritetty sisään asetustiedosto lisäämällä:

synchronous_commit = local  
synchronous_standby_names='*'

Asettamalla parametrin synchronous_commit merkitykseen local, luomme järjestelmän, jossa paikalliset levyt pysyvät synkronisina, mutta verkkoreplikatoimitukset ovat oletuksena asynkronisia. Ellemme tietysti päätä tehdä näistä sitoumuksista synkronisia, kuten yllä on esitetty.

Jos olet seurannut kehitystä Kuvernöörin projekti, olet ehkä huomannut joitain viimeaikaisia ​​muutoksia (1, 2), jonka avulla Governor-käyttäjät voivat testata näitä parametreja ja valvoa niiden yhdenmukaisuutta.

Vielä muutama sana...

Vain viikko sitten olisin sanonut, että PostgreSQL:n hienosäätö on mahdotonta niin hienoksi. Silloin Kurt, Compose-alustan tiimin jäsen, väitti, että tällainen mahdollisuus on olemassa. Hän rauhoitti vastalauseeni ja löysi PostgreSQL-dokumentaatiosta seuraavat:

Tätä asetusta voidaan muuttaa milloin tahansa. Minkä tahansa tapahtuman käyttäytyminen määräytyy sitomishetkellä voimassa olevan asetuksen mukaan. Siksi on mahdollista ja hyödyllistä, että jotkut tapahtumat sitoutuvat synkronisesti ja toiset asynkronisesti. Esimerkiksi pakottaaksesi yhden multistatement tapahtuma, joka tekee sitoumuksia asynkronisesti, kun parametrin oletusarvo on vastakkainen, aseta SET LOCAL synchronous_commit TO OFF kaupassa.

Tällä konfigurointitiedostoon tehdyllä pienellä muutoksella annoimme käyttäjille hallinnan niiden johdonmukaisuudesta ja suorituskyvystä.

Lähde: will.com