Johdanto

on tunnettu Eric Brewerin ehdottama tietojenkäsittelytieteen lause, jonka mukaan hajautetun datan sisältävälle tietokannalle voidaan luvata vain kaksi seuraavista kolmesta ominaisuudesta:

• saatavuus
• Partition toleranssi

Tämä on hyvin abstrakti ja terminologia ei ole aivan intuitiivinen, joten tässä artikkelissa teemme parhaamme murtaaksemme tämän teoria alas abstraktista enemmän reaalimaailman puhetta ja esimerkkejä. Tämä lause voi saa sinut ajattelemaan tietokannan arkkitehtuuri kannalta, mitä sovellus todella tarvitsee ja uhrauksia se voi joutua tekemään saavuttaa nämä.

Cap-terminologian määrittely

otetaan joitakin perusmääritelmiä pois tieltä, jotta voimme olla samalla sivulla, kun siirrymme eteenpäin puhuen tästä lauseesta.

CAP – johdonmukaisuus, saatavuus, Osiotoleranssi

• johdonmukaisuus – kaikilla palvelimillasi on samat tiedot, joten voit kysellä miltä tahansa järjestelmän palvelimelta ja saada täsmälleen samat tiedot.
• saatavuus – jokaiseen datapalvelimille esitettyyn pyyntöön vastataan. Jos yksi palvelin on varattu, se reititetään toiselle, joka pystyy vastaamaan.
• Osiotoleranssi – järjestelmän kyky jatkaa toimintaansa, vaikka verkossa olisi vikoja ja osa palvelimista ei pystyisi kommunikoimaan.

taustalla oleva oletus – P on mahdoton

hajautetussa tietokantajärjestelmässä tietosi jaetaan eri palvelimille ja nämä palvelimet puhuvat keskenään verkon kautta, jotta ne voivat säilyttää saman datajoukon. Ongelmana on, että verkot katkeavat ja niin oletamme, että se kommunikoi aina, eli meillä ei voi olla täydellistä verkkoa. Tämän teorian kannalta se tarkoittaa sitä, että todellisessa maailmassa on uhrattava Jakautumistoleranssi. Jos täydellinen pettämätön verkko olisi olemassa, meillä ei olisi ongelmia johdonmukaisuuden ja saatavuuden saavuttamisessa, mutta tämä on todellinen maailma, joka on rakennettu fyysisille johdoille, jotka epäonnistuvat, joten oletamme, että se epäonnistuu.

jos P on mahdoton, mitä vaihtoehtoja meillä on?

koska olemme luopuneet Osiotoleranssista, lause sanoo, että meidän on nyt valittava johdonmukaisuuden ja käytettävyyden välillä.

voit valita käytettävyyden, jossa sovelluksesi voi täyttää kaikki saapuvat pyynnöt, mutta se ei voi taata, että tiedot ovat viimeisimpiä.

mitä hakemuksesi tarvitsee?

Jos sovelluksesi on sosiaalisen median sivusto, eikä sillä tarvitse olla aina tuoreimpia tietoja, voit valita käytettävyyden. Onko sillä väliä, että käyttäjät näkevät post jälkeen 30 sekunnin viive? Jos ei, niin saatat mieluummin saatavuus, koska priorisoit, että käyttäjät voivat käyttää tietoja, vaikka se ei ole kaikkein ajan tasalla tietoja.

Jos toisaalta hakemuksesi edellyttää, että jokainen tietokantaan luettu tieto on ehdottomasti tuorein tieto, sinun on uhrattava käytettävyys ja valittava johdonmukaisuus. Jotkut pyynnöt on virhe, koska tietoja ei voida taata, että se on ehdottomasti viimeisin.

relaatio-ja NoSQL

Tietokantatekniikan tekemät valinnat, kuten SQL ja muut RELAATIOTIETOKANTAJÄRJESTELMÄT, jotka on suunniteltu happaman tärkeysjärjestyksen mukaisiksi. Toisaalta useimmat NoSQL-tietokannat priorisoivat käytettävyyttä.

johtopäätös

uskomme, että tämän lauseen tutkiminen hakemuksesi kannalta on erinomainen harjoitus ja auttaa sinua arvioimaan hakemuksesi prioriteetteja. Jos sinulla on hajautettu tietojärjestelmä, tutki arkkitehtuuriasi ja ymmärrä, minkä uhrauksen olet tekemässä.

MongoDB, CockroachDB ja Postgres ovat kaikki hienoja tietokantatekniikoita, jotka tekevät tietokantaarkkitehtuureistamme erittäin vankkoja, mutta kuten keskustelimme, ne eivät ole täydellisiä. Meillä ei ole täydellistä verkkoa ja aina on ”käyttäjän virhe”. Jos olet siirtymässä tuotantoympäristöön ja haluat keskustella parhaista vaihtoehdoista hakemuksesi, älä epäröi ottaa yhteyttä meihin Object Rocket.