C.A.P.-lause

CAP - lause (tunnetaan myös nimellä Brewerin teoreema ) on heuristinen lausunto, jonka mukaan enintään kaksi seuraavista kolmesta ominaisuudesta voidaan tarjota missä tahansa hajautetun laskennan toteutuksessa:

Lauseen nimessä oleva lyhenne CAP muodostuu näiden kolmen ominaisuuden englanninkielisten nimien ensimmäisistä kirjaimista.

Periaatteen ehdotti UC Berkeleyn professori Eric Brewer heinäkuussa 2000 [1] [2], ja se saavutti myöhemmin laajan suosion ja tunnustuksen hajautettujen tietojenkäsittelyasiantuntijoiden keskuudessa [3] [4] . NoSQL - konsepti , jonka puitteissa luodaan hajautettuja ei- tapahtumallisia tietokantojen hallintajärjestelmiä , käyttää usein tätä periaatetta perusteena tietojen johdonmukaisuuden epäonnistumisen väistämättömyydelle [5] [6] [7] . Monet tiedemiehet [8] ja harjoittajat [9] kuitenkin arvostelevat CAP-lausetta sen löyhästä tulkinnasta ja jopa epäluotettavuudesta siinä mielessä, missä se on yleistä yhteisössä.

Perustelut

Vuonna 2002 Seth Gilbert ja Nancy Lynch Massachusetts Institute of Technologysta valitsivat asynkronisen ja synkronisen hajautetun laskennan muodolliset mallit, jotka osoittavat CAP-lauseen täyttymisen ilman synkronointia (yhteinen kello) hajautetun järjestelmän solmuissa ja perustavanlaatuinen mahdollisuus kompromissiin osittain synkronisissa järjestelmissä [10] . Tässä työssä "yhtenäisyys" CAP-lauseen merkityksessä korreloi kahden ensimmäisen vaatimuksen, ACID  - atomisuuden ja johdonmukaisuuden , täyttymisen kanssa . Jatkossa monet harjoittajat pitivät tätä työtä todisteena CAP-lauseesta [4] [11] [3] .

Seuraukset

CAP-lauseen näkökulmasta hajautetut järjestelmät, riippuen käytännössä tuetuista ominaisuuksista, kolmesta mahdollisesta, jakautuvat kolmeen luokkaan - CA, CP, AP.

CA-luokan järjestelmässä data on johdonmukaista ja saatavilla kaikissa solmuissa, samalla kun se uhraa kestävyyttä osioinnin vuoksi. Tällaiset järjestelmät ovat mahdollisia perustuen teknisiin ohjelmistoihin, jotka tukevat transaktiota ACID :n mielessä , esimerkkejä tällaisista järjestelmistä voivat olla klusteroituihin tietokantojen hallintajärjestelmiin tai hajautettuun hakemistopalveluun LDAP [12] perustuvat ratkaisut .

CP-luokan järjestelmä antaa joka hetki kokonaisvaltaisen tuloksen ja pystyy toimimaan rappeutumisolosuhteissa, mutta saavuttaa tämän saatavuuden kustannuksella: se ei välttämättä vastaa pyyntöön. Osioihin jakamisen sietokyky edellyttää muutosten päällekkäisyyttä kaikissa järjestelmän solmuissa, minkä yhteydessä havaitaan käytännön tarkoituksenmukaisuus käyttää hajautettuja pessimistisiä lukkoja tällaisissa järjestelmissä eheyden säilyttämiseksi [13] .

AP-luokan järjestelmässä eheyttä ei taata, mutta saavutettavuuden ja osiointikestävyyden ehdot täyttyvät. Vaikka tällaiset järjestelmät ovat olleet tiedossa jo kauan ennen CAP-periaatteen muotoilemista (esimerkiksi hajautetut verkkovälimuistit tai DNS ) [14] , tällä ominaisuuksilla varustettujen ratkaisujen kasvava suosio liittyy juuri CAP-teoreeman leviämiseen. . Siten useimmat NoSQL-järjestelmät eivät pohjimmiltaan takaa tietojen eheyttä, ja viittaavat CAP-lauseeseen motiivina tällaiselle rajoitukselle [5] . AP-järjestelmien rakentamisen tehtävänä on tarjota jonkinlainen käytännöllisesti katsoen tarkoituksenmukainen tietojen eheyden taso, tässä mielessä AP-järjestelmien sanotaan olevan "lopulta johdonmukaisia " [ 15] tai "heikosti johdonmukaisia" ( eng  . heikko konsistenssi ) [16] .  

BASE-arkkitehtuuri

2000-luvun jälkipuoliskolla muotoiltiin lähestymistapa hajautettujen järjestelmien rakentamiseen, joissa eheys- ja saatavuusvaatimukset eivät täysin täyty, ja sitä kutsuttiin BASE -lyhenteeksi ( englannin sanasta  Basically Available, Soft-state, Lopulta johdonmukainen  - peruskäytettävyys, epävakaa tila, johdonmukaisuus lopulta), kun taas tämä lähestymistapa on suoraan ACID :n vastainen [17] . Perussaatavuus viittaa lähestymistapaan sovelluksen suunnitteluun siten, että joidenkin solmujen vika johtaa palvelun estoon vain pienessä osassa istuntoja, samalla kun saatavuus säilyy useimmissa tapauksissa [ 18] . Haihtuva tila tarkoittaa kykyä uhrata istunnon tilan (kuten valintojen välitulokset, navigointitiedot, konteksti) pitkäaikainen tallennus, samalla kun keskitytään päivittämään vain kriittisiä toimintoja. Johdonmukaisuus, joka viime kädessä tulkitaan mahdolliseksi tietojen epäjohdonmukaisuuteen joissakin tapauksissa, mutta samalla kun varmistetaan yksimielisyys käytännössä ennakoitavissa olevassa ajassa, merkittävä määrä riippumatonta tutkimusta on omistettu [19] [20] .

Muistiinpanot

  1. ↑ Panimo, 2000 .
  2. ↑ Gilbert, Lynch, 2002 , PODC 2000:ssa Brewer esitti kutsutussa puheessa seuraavan olettamuksen: verkkopalvelun on mahdotonta tarjota kolmea seuraavaa takuuta: • Johdonmukaisuus • Saatavuus • Osion sieto, s. 55.
  3. ↑ 1 2 White Paper Beating the CAP Theorem  (englanniksi) ( PDF )  (linkki ei saatavilla) . genedb.com (17. huhtikuuta 2011). Haettu 7. kesäkuuta 2011. Arkistoitu alkuperäisestä 28. kesäkuuta 2011.
  4. ↑ 1 2 Browne, Julian Brewerin CAP-lause  ( 11. tammikuuta 2009). Haettu 7. kesäkuuta 2011. Arkistoitu alkuperäisestä 1. elokuuta 2012.
  5. ↑ 1 2 Brewer, 2010 , Laaja-aluejärjestelmien suunnittelijat, joissa verkkoosiot katsotaan väistämättömiksi, tietävät, että niillä ei voi olla sekä käytettävyyttä että yhdenmukaisuutta, joten he voivat nyt perustella heikomman johdonmukaisuuden. NoSQL-liikkeen nousu ("Not Only SQL") on tämän vapauden ilmaus, s. 335.
  6. ↑ Rice, 2011 , Tämä olettamus tunnetaan nykyään yleisesti CAP-lauseena, ja se on yksi tärkeimmistä argumenteista, miksi perinteiset relaatiotietokannat, jotka tarjoavat vahvat ACID-takuut (atomitapahtumat, transaktioiden johdonmukaisuus ja eristäminen sekä tietojen kestävyystekniikat) eivät voi tarjota molempia osioita. laajamittaisten hajautettujen sovellusten vaatima toleranssi ja saatavuus, s. 49.
  7. ↑ Kuznetsov, 2011 , Vakavampi "teoreettinen" perusta NoSQL-kehitykselle, jossa tiedonhallintajärjestelmien yleisesti hyväksytyt hyödylliset ominaisuudet uhrataan näiden järjestelmien saatavuuden vuoksi, on ns. "CAP-teoreema", jonka Eric muotoili ensimmäisenä. Brewer, s. 191.
  8. ↑ Kuznetsov, 2011 , Laitan sanan lauseen lainausmerkkeihin, koska en voi tunnistaa lausetta nimeltä Brewer lauseeksi, koska ongelmasta ei ole selkeää ja ainakin hieman muodollista ilmaisua ... mutta yleisesti uskotaan, että se tarkoittaa mahdotonta tukea yhdessä hajautetussa tiedonhallintajärjestelmässä tietojen johdonmukaisuuden (Consistency), käytettävyyden (Availability) ja verkon erottelukestävyyden (Osiointi), s. 191-192.
  9. ↑ Rice, 2011 , Miksi monet johtavista sosiaalisen verkostoitumisen sivustoista (Facebook, MySpace, Twitter), verkkokauppasivustoista (hotellin varausjärjestelmät ja ostossivustot) ja suuret pankkisovellukset toteutetaan edelleen perinteisten tietokantajärjestelmien, kuten MySQL, avulla (Facebook, Twitter) tai SQL Server (MySpace, Choice Hotels International, Bank Itau) uusien NoSQL-järjestelmien sijaan? … Korkean tason vastaus on, että sovellusarkkitehtuuri painaa edelleen samoja kompromisseja, joita CAP-lause vaatii, s. viisikymmentä.
  10. ↑ Gilbert, Lynch, 2002 , Asynkronisessa mallissa, kun kelloja ei ole saatavilla, mahdottomuustulos on melko vahva: on mahdotonta tarjota johdonmukaista dataa, vaikka sallittaisiin vanhentuneiden tietojen palauttaminen, kun viestit katoavat. Osittain synkronisissa malleissa on kuitenkin mahdollista saavuttaa käytännöllinen kompromissi johdonmukaisuuden ja saatavuuden välillä, s. 59.
  11. ↑ Grigorik, 2010 , Ongelmana on, että Eric Brewerin ehdottama ja Seth Gilbertin ja Nancy Lynchin myöhemmin todistama CAP-teoreema osoittaa, että näitä kolmea vaatimusta on mahdotonta saavuttaa samanaikaisesti.
  12. ↑ Carter, 2011 , Jotkut CA-järjestelmät sisältävät: yhden sivuston tietokannat, klusteritietokannat ja LDAP.
  13. ↑ Demidov, 2010 , CP (denial of service) on lähestymistapa, jossa on päällekkäisyyttä, tiukka ACID-yhtenäisyys ja muutosten synkroninen replikointi pessimististä estomenetelmää käyttäen.
  14. ↑ Carter, 2011 , Jotkut tukiasemajärjestelmät sisältävät: Web-välimuistijärjestelmät ja DNS-järjestelmän (Domain Name System).
  15. ↑ Carter, 2011 , Lopullinen johdonmukaisuus – lukutoiminnon suorittaminen voi antaa asiakkaalle vanhentuneita tietoja, mutta kaikki kirjoitukset leviävät lopulta koko järjestelmän läpi.
  16. ↑ Grigorik, 2010 , YMP merkitsee heikkoa johdonmukaisuutta.
  17. ↑ Pritchett, 2008 , Jos ACID tarjoaa johdonmukaisuusvaihtoehdon osioiduille tietokannoille, niin miten saavutetaan sen sijaan saatavuus? Yksi vastaus on BASE (periaatteessa saatavilla, pehmeä tila, lopulta johdonmukainen). BASE on täysin päinvastainen kuin ACID.
  18. ↑ Pritchett, 2008 , BASE:n saatavuus saavutetaan tukemalla osittaisia ​​vikoja ilman täydellistä järjestelmävikaa. Tässä on yksinkertainen esimerkki: jos käyttäjät on jaettu viiteen tietokantapalvelimeen, BASE-suunnittelu rohkaisee luomaan toimintoja siten, että käyttäjätietokannan vika vaikuttaa vain 20 prosenttiin kyseisen isäntäkoneen käyttäjistä.
  19. ↑ Kivenmurtaja, 2010 .
  20. ↑ Vogels, 2008 .

Kirjallisuus