4.1 Konsistens om Brewera
Til at begynde med er Eric Brewer ikke, og har aldrig hævdet at være, en databaseekspert. Han tilhører fællesskabet af distribuerede systemer, og hans berømte foredrag, hvor CAP "sætningen" optrådte, blev givet på konferencen "Principles of Distributed Computing". (Ti år senere, i 2010, holdt han i øvrigt igen et inviteret foredrag på samme konference, og i dette foredrag gav han især en række eksempler på distribuerede systemer, hvis udvikling tog højde for " teorem" af CAP.) På dette område har sin egen fortolkning af de termer, der bruges inden for databaser.
Især betyder udtrykket "øjeblikkelig konsistens" , at efter at brugeren har modtaget meddelelse fra systemet om en vellykket gennemførelse af en dataopdateringsoperation, bliver resultatet af denne operation øjeblikkeligt synligt for alle observatører.
Eventuel konsistens betyder, at hvis der ikke kommer nye dataopdateringsoperationer ind i systemet i en tilstrækkelig lang periode, så kan det forventes, at resultaterne af alle tidligere dataopdateringsoperationer til sidst vil spredes til alle noder i systemet, og alle replikadata er konsekvent (tilsyneladende skal dette forstås som "alle replikaer vil have samme tilstand".
Med denne følelse af sammenhæng i tankerne, kan Brewers "sætning" betragtes som ganske forståelig og indlysende: I ethvert distribueret system med delte data kan kun to egenskaber for netværkets konsistens, tilgængelighed og partitionstolerance sikres samtidigt. I denne henseende kontrasterer Brewer endda sættet af ACID-egenskaber med hans foreslåede sæt af BASE-egenskaber (Basically Available, Soft-state, Eventual consistentency - tilgængelighed i de fleste tilfælde; ustabil tilstand; endelig konsistens). Men denne modstand er efter min mening uberettiget, da vi i det første tilfælde taler om de logiske egenskaber ved transaktioner, og i det andet - om de fysiske egenskaber ved distribuerede systemer.
4.2 Bevis for "sætningen"
Mange mener, at Brewers "teorem" er blevet formelt bevist. Faktisk introducerer papiret af Seth Gilbert og Nancy Lynch nogle (næsten) formelle definitioner, i hvilken sammenhæng "sætningen" virkelig bliver en teorem og bevises. Lad os dog se, hvordan disse tre egenskaber af et distribueret system bestemmes, hvoraf ifølge Brewers "sætning" kun to egenskaber kan understøttes samtidigt.
Konsistens kaldes atomisk eller lineariserbar konsistens (atomisk eller lineariserbar konsistens), som er en egenskab ved systemet, hvis alle individuelle dataobjekter er atomare (lineariserbare). Til gengæld er et atomobjekt et objekt med flere operationer, sådan at opkaldet af operationen og modtagelsen af svardata sker som om det øjeblikkeligt, dvs. objektet accepterer ikke opkaldet til den næste operation, før den forrige operation er fuldført. Rækkefølgen, hvori operationer modtages, skal være sådan, at hvis en læse-type-operation ankommer efter en skrive-type-operation er blevet udført, så skal læse-operationen returnere værdien skrevet af denne eller en senere skrive-operation.
Et distribueret system er altid tilgængeligt, hvis hver forespørgsel modtaget af en ikke-mislykket node skal besvares. Systemets modstandsdygtighed over for netværkspartition er modelleret som bevarelsen af systemets levedygtighed i tilfælde af tab af et vilkårligt antal meddelelser sendt fra en node til en anden.
Baseret på disse definitioner formulerer Hilbert og Lynch følgende teorem (der er intet ur i den asynkrone netværksmodel, og noder bør kun træffe beslutninger på grundlag af modtagne beskeder og lokale beregninger):
I en asynkron netværksmodel er det ikke muligt at implementere et læse/skrive dataobjekt, der garanterer tilgængelighed og atomare konsistensegenskaber for alle gyldige eksekveringer (inklusive dem, der mister meddelelser).
Denne teorem er egentlig ganske simpelt formelt bevist med metoden "ved modsigelse". Artiklen fortsætter med at konkludere, at:
I en asynkron netværksmodel er det ikke muligt at implementere et læse/skrive dataobjekt, der garanterer tilgængelighedsegenskaber for alle gyldige udførelser og atomkonsistens for gyldige udførelser, hvor meddelelser ikke går tabt.
Derudover bevises hovedsætningens sandhed for en delvist synkron netværksmodel, hvor hver knude har et ur, hvormed den viste tid stiger med samme hastighed, men som ikke er synkroniseret, dvs. kan vise forskellige tidspunkter på det samme virkelige øjeblik. Det er vist, at der i dette tilfælde ikke er en lignende konsekvens, og derfor er der for delvist synkrone netværk flere muligheder for at organisere distribuerede systemer med "gode" egenskaber.
Ja, i en vis forstand (ikke nødvendigvis den samme som Brewers tilsigtede) kan Gilbert og Lynch anses for at have bevist, at det er umuligt samtidig at sikre egenskaberne for atomart konsistens, tilgængelighed og partitionstolerance af et netværk i et enkelt distribueret system. Men hvad har dette at gøre med databasetransaktioner i almindelighed og ACID-transaktioner i særdeleshed?
4.3 SYRE-transaktioner
Her er, hvad Julian Browne skriver om dette i sin note om diskussionen om "sætningen" af CAP:
I deres bevis bruger Hilbert og Lynch udtrykket atomicitet i stedet for konsistens, hvilket giver mere mening fra et teknisk synspunkt, fordi strengt taget konsistens i betydningen ACID refererer til de ideelle egenskaber ved databasetransaktioner og betyder, at ingen data vil blive vedholdende, hvis de overtræder nogle på forhånd fastlagte restriktioner. Men hvis vi antager, at en forud-etableret begrænsning af distribuerede systemer er forbuddet mod tilstedeværelsen af flere forskellige værdier for det samme dataelement, så kan denne fejl i abstraktionen af konsistens efter min mening overvejes ubetydelig (derudover, hvis Brewer brugte udtrykket atomicitet, ville AAP-sætningen dukke op, hvis navn ville være ekstremt ubelejligt at udtale).
Dette er skrevet ikke særlig seriøst, men ærligt. Og faktisk bør kravet om atomart konsistens ikke blandes med kravene om transaktionskonsistens i betydningen ACID. Databaseintegritetsbegrænsninger er logiske, om du vil, forretningskrav. De kommer fra applikationsdomænelogik. Kravet om atomart konsistens er af en meget anden art. Dette er et implementeringskrav, der falder ind under den kategori, der traditionelt omtales i databaseindustrien som fysisk konsistens (for eksempel, når du udfører enhver indeksændringsoperation, skal alle blokke i det tilsvarende B+ træ indeholde gyldige værdier og være forbundet med gyldige referencer ).
Og her er, hvad repræsentanter for databasesamfundet Daniel Abadi og Alexander Thomson skriver ganske alvorligt i deres notat:
... kravet om tilgængelighed af skalerbare transaktionssystemer bliver mere og mere kritisk, og dette opfyldes normalt gennem replikering og automatisk omdirigering af anmodninger i tilfælde af fejl i en af noderne. Derfor forventer applikationsudviklere, at konsistensgarantierne for ACID-systemer (oprindeligt bestående af lokal understøttelse af brugerdefinerede invarianter) vil blive udvidet for at sikre stærk konsistens (at alle replikaer af de samme data på et givet tidspunkt vil være identiske kopier, dvs. denne sammenhæng er underforstået i betydningen CAP/PACELC.
Brewer-konsistens har med andre ord intet at gøre med konsistens i betydningen ACID, men det er i systemer, der er fokuseret på at levere høj tilgængelighed gennem datareplikering, at det er ønskeligt at opretholde en stærk replika-konsistens. Dette er ikke en ACID-egenskab, men en teknisk (fysisk) funktion af massivt parallel DBMS, der letter applikationsudvikling.
Ifølge Michael Stonebreaker er nøglen til at bygge et moderne DBMS af høj kvalitet det rigtige valg af tekniske kompromiser. Når du vælger en specifik ingeniørløsning, skal mange faktorer tages i betragtning - fremtidige brugeres krav, sandsynligheden for forskellige fejlsituationer osv., og ikke være dogmatisk styret af nogen generelle teoretiske retningslinjer (herunder CAP "sætningen").
Stonebreaker mener, at i området for transaktionelle parallelle databasesystemer er det en dårlig afvejning at opgive Brewers konsistens til fordel for at understøtte høj tilgængelighed og netværkspartitionstolerance, fordi (a) replika-konsistens er en meget nyttig funktion ved systemet; (b) transaktionelle massivt parallelle DBMS behøver ikke klynger med et meget stort antal knudepunkter, så situationer med opdeling af netværk er usandsynlige; (c) systemet kan let blive utilgængeligt, ikke på grund af en netværkspartition, men for eksempel på grund af tilstedeværelsen af regelmæssigt forekommende softwarefejl.
Den høje aktivitet hos repræsentanter for NoSQL-lejren (læs NoACID), som ofte refererer til Brewers "sætning", er således ikke forbundet med den teoretiske umulighed af at bygge massivt parallelle transaktionelle DBMS, der understøtter ACID-transaktioner, men med det faktum, at forenklede systemer der ikke kun understøtter ACID-transaktioner, men også replika-konsistens, skabes nemmere og hurtigere. På grund af deres forenklede organisation er de i stand til meget hurtig databehandling, og for nogle applikationer er dette vigtigere end alle de bekvemmeligheder, der ligger i databaseteknologi.
Lad os se, hvordan databasesamfundet reagerer på denne udfordring.