4.1 Konsistens om Brewera
Til å begynne med er ikke Eric Brewer, og har aldri hevdet å være, en databaseekspert. Han tilhører fellesskapet av distribuerte systemer, og hans berømte foredrag, der CAP "teorem" dukket opp, ble holdt på konferansen "Principles of Distributed Computing". (Forresten, ti år senere, i 2010, holdt han igjen et invitert foredrag på samme konferanse, og i dette foredraget ga han spesielt en rekke eksempler på distribuerte systemer, hvor utviklingen tok hensyn til " teorem" av CAP.) På dette området har sin egen tolkning av begrepene som brukes innen databaser.
Spesielt betyr uttrykket "umiddelbar konsistens" at etter at brukeren mottar varsel fra systemet om vellykket fullføring av en dataoppdateringsoperasjon, blir resultatet av denne operasjonen umiddelbart synlig for alle observatører.
Eventuell konsistens betyr at hvis ingen nye dataoppdateringsoperasjoner kommer inn i systemet over en tilstrekkelig lang periode, kan det forventes at resultatene av alle tidligere dataoppdateringsoperasjoner til slutt vil spre seg til alle noder i systemet, og alle replikadata er konsekvent (tilsynelatende skal dette forstås som "alle replikaer vil ha samme tilstand".
Med denne følelsen av konsistens i tankene, kan Brewers "teorem" betraktes som ganske forståelig og åpenbar: i ethvert distribuert system med delte data kan bare to av egenskapene for konsistens, tilgjengelighet og partisjonstoleranse for nettverket sikres samtidig. I denne forbindelse kontrasterer Brewer til og med settet med ACID-egenskaper med det foreslåtte settet med BASE-egenskaper (Basically Available, Soft-state, Eventuell konsistens - tilgjengelighet i de fleste tilfeller; ustabil tilstand; endelig konsistens). Men denne motstanden er etter min mening uberettiget, siden vi i det første tilfellet snakker om de logiske egenskapene til transaksjoner, og i det andre - om de fysiske egenskapene til distribuerte systemer.
4.2 Bevis for "teoremet"
Mange mener at Brewers "teorem" er formelt bevist. Faktisk introduserer papiret av Seth Gilbert og Nancy Lynch noen (nesten) formelle definisjoner i hvilken kontekst "teoremet" virkelig blir et teorem og bevises. La oss imidlertid se hvordan de tre egenskapene til et distribuert system bestemmes, hvorav, ifølge Brewers "teorem", bare to egenskaper kan støttes samtidig.
Konsistens kalles atomisk, eller lineariserbar konsistens (atomisk eller lineariserbar konsistens), som er en egenskap ved systemet, hvor alle individuelle dataobjekter er atomære (lineariserbare). I sin tur er et atomobjekt et objekt med flere operasjoner, slik at oppkallingen av operasjonen og mottak av responsdata skjer som umiddelbart, dvs. objektet godtar ikke anropet til neste operasjon før den forrige operasjonen er fullstendig fullført. Rekkefølgen som operasjoner mottas i må være slik at hvis en leseoperasjon kommer etter at en skriveoperasjon er utført, så må leseoperasjonen returnere verdien skrevet av denne eller en senere skriveoperasjon.
Et distribuert system er alltid tilgjengelig hvis hver forespørsel mottatt av en node som ikke har mislyktes må besvares. Systemets motstandskraft mot nettverkspartisjon er modellert som bevaring av systemets levedyktighet i tilfelle tap av et vilkårlig antall meldinger sendt fra en node til en annen.
Basert på disse definisjonene formulerer Hilbert og Lynch følgende teorem (det er ingen klokke i den asynkrone nettverksmodellen, og noder bør ta beslutninger kun på grunnlag av mottatte meldinger og lokale beregninger):
I en asynkron nettverksmodell er det ikke mulig å implementere et lese-/skrivedataobjekt som garanterer tilgjengelighets- og atomkonsistensegenskaper for alle gyldige kjøringer (inkludert de som mister meldinger).
Denne teoremet er egentlig ganske enkelt formelt bevist med metoden "ved motsetning". Artikkelen fortsetter med å konkludere med at:
I en asynkron nettverksmodell er det ikke mulig å implementere et lese-/skrivedataobjekt som garanterer tilgjengelighetsegenskaper for alle gyldige kjøringer og atomkonsistens for gyldige kjøringer der meldinger ikke går tapt.
I tillegg bevises sannheten til hovedteoremet for en delvis synkron nettverksmodell, der hver node har en klokke, hvor tiden vist øker med samme hastighet, men som ikke er synkronisert, dvs. kan vise forskjellige tider i samme virkelige øyeblikk. Det er vist at for dette tilfellet er det ikke utledet en lignende konsekvens, og derfor er det for delvis synkrone nettverk flere muligheter for å organisere distribuerte systemer med "gode" egenskaper.
Ja, på en måte (ikke nødvendigvis det samme som Brewers tilsiktet) kan Gilbert og Lynch anses å ha bevist at det er umulig å samtidig sikre egenskapene til atomkonsistens, tilgjengelighet og partisjonstoleranse til et nettverk i et enkelt distribuert system. Men hva har dette med databasetransaksjoner generelt og ACID-transaksjoner spesielt å gjøre?
4.3 SYRE-transaksjoner
Her er hva Julian Browne skriver om dette i sitt notat om diskusjonen om "teoremet" til CAP:
I sitt bevis bruker Hilbert og Lynch begrepet atomitet i stedet for konsistens, noe som gir mer mening fra et teknisk synspunkt fordi, strengt tatt, refererer konsistens i betydningen ACID til de ideelle egenskapene til databasetransaksjoner og betyr at ingen data vil bli vedvarende hvis de bryter noen forhåndsetablerte restriksjoner. Men hvis vi antar at en forhåndsetablert begrensning av distribuerte systemer er forbudet mot tilstedeværelsen av flere forskjellige verdier for det samme dataelementet, kan denne feilen i abstraksjonen av konsistens etter min mening vurderes ubetydelig (i tillegg, hvis Brewer brukte begrepet atomitet, ville AAP-teoremet dukke opp, hvis navn ville være ekstremt upraktisk å uttale).
Dette er ikke skrevet veldig seriøst, men ærlig. Og faktisk bør kravet om atomkonsistens ikke blandes med kravene til transaksjonskonsistens i betydningen ACID. Databaseintegritetsbegrensninger er logiske, om du vil, forretningskrav. De kommer fra applikasjonsdomenelogikk. Kravet om atomkonsistens er av en helt annen type. Dette er et implementeringskrav som faller inn i kategorien som tradisjonelt refereres til i databaseindustrien som fysisk konsistens (for eksempel, når du utfører en indeksendringsoperasjon, må alle blokker i det tilsvarende B+-treet inneholde gyldige verdier og være koblet sammen med gyldige referanser ).
Og her er hva representanter for databasesamfunnet Daniel Abadi og Alexander Thomson skriver ganske alvorlig i notatet sitt:
... kravet til tilgjengelighet av skalerbare transaksjonssystemer blir stadig mer kritisk, og dette møtes vanligvis gjennom replikering og automatisk omdirigering av forespørsler ved feil på en av nodene. Derfor forventer applikasjonsutviklere at konsistensgarantiene til ACID-systemer (opprinnelig bestående av lokal støtte for brukerdefinerte invarianter) vil bli utvidet for å sikre sterk konsistens (at alle replikaer av samme data til enhver tid vil være identiske kopier, dvs. i denne sakskonsistensen er underforstått i betydningen CAP/PACELC.
Brewer-konsistens har med andre ord ingenting å gjøre med konsistens i betydningen ACID, men det er i systemer fokusert på å gi høy tilgjengelighet gjennom datareplikering at det er ønskelig å opprettholde sterk replika-konsistens. Dette er ikke en ACID-egenskap, men en teknisk (fysisk) funksjon i massivt parallell DBMS som letter applikasjonsutvikling.
Ifølge Michael Stonebreaker er nøkkelen til å bygge et moderne DBMS av høy kvalitet det riktige valget av tekniske kompromisser. Når du velger en spesifikk ingeniørløsning, må mange faktorer tas i betraktning - kravene til fremtidige brukere, sannsynligheten for ulike feilsituasjoner, etc., og ikke være dogmatisk veiledet av noen generelle teoretiske retningslinjer (inkludert CAP "teoremet").
Stonebreaker mener at når det gjelder transaksjonelle parallelle databasesystemer, er det en dårlig avveining å forlate Brewers konsistens til fordel for å støtte høy tilgjengelighet og nettverkspartisjonstoleranse fordi (a) replikakonsistens er en svært nyttig funksjon i systemet; (b) transaksjonelle massivt parallelle DBMS trenger ikke klynger med et veldig stort antall noder, så nettverksdelte situasjoner er usannsynlige; (c) systemet kan lett bli utilgjengelig, ikke på grunn av en nettverkspartisjon, men for eksempel på grunn av tilstedeværelsen av regelmessig forekommende programvarefeil.
Dermed er den høye aktiviteten til representanter for NoSQL-leiren (les NoACID), som ofte refererer til Brewers "teorem", ikke forbundet med den teoretiske umuligheten av å bygge massivt parallelle transaksjonelle DBMS som støtter ACID-transaksjoner, men med det faktum at forenklede systemer som ikke bare støtter ACID-transaksjoner, men også replika-konsistens, skapes enklere og raskere. På grunn av deres forenklede organisering er de i stand til svært rask databehandling, og for noen applikasjoner er dette viktigere enn alle bekvemmelighetene som ligger i databaseteknologi.
La oss se hvordan databasefellesskapet reagerer på denne utfordringen.