4.1 Konsekvens om Brewera
Till att börja med är Eric Brewer inte, och påstods aldrig vara, en databasexpert. Han tillhör gemenskapen av distribuerade system, och hans berömda föredrag, där CAP "teorem" förekom, hölls på konferensen "Principles of Distributed Computing". (Förresten, tio år senare, 2010, höll han återigen ett inbjudet föredrag vid samma konferens, och i detta föredrag gav han särskilt ett antal exempel på distribuerade system, vars utveckling tog hänsyn till " theorem" av CAP.) Inom detta område har sin egen tolkning av termerna som används inom området databaser.
Speciellt betyder termen "omedelbar konsistens" att efter att användaren fått meddelande från systemet om framgångsrikt slutförande av någon datauppdateringsoperation, blir resultatet av denna operation omedelbart synligt för alla observatörer.
Eventuell konsistens innebär att om inga nya datauppdateringsoperationer kommer in i systemet under en tillräckligt lång tid, så kan det förväntas att resultaten av alla tidigare datauppdateringsoperationer så småningom kommer att spridas till alla noder i systemet, och all replikdata är konsekvent (uppenbarligen ska detta förstås som "alla repliker kommer att ha samma tillstånd".
Med denna känsla av konsistens i åtanke kan Brewers "sats" anses vara ganska förståeligt och uppenbart: i vilket distribuerat system som helst med delad data kan endast två godtyckliga egenskaper för konsistens, tillgänglighet och partitionstolerans för nätverket säkerställas samtidigt. I detta avseende kontrasterar Brewer till och med uppsättningen av ACID-egenskaper med hans föreslagna uppsättning av BASE-egenskaper (Basically Available, Soft-state, Eventuell konsistens - tillgänglighet i de flesta fall; instabilt tillstånd; slutlig konsistens). Men denna opposition, enligt min mening, är omotiverad, eftersom vi i det första fallet talar om de logiska egenskaperna hos transaktioner och i det andra - om de fysiska egenskaperna hos distribuerade system.
4.2 Bevis för "satsen"
Många tror att Brewers "sats" har bevisats formellt. Faktum är att uppsatsen av Seth Gilbert och Nancy Lynch introducerar några (nästan) formella definitioner i vilka sammanhang "satsen" verkligen blir ett teorem och bevisas. Men låt oss se hur de tre egenskaperna hos ett distribuerat system bestäms, av vilka, enligt Brewers "sats", endast två egenskaper kan stödjas samtidigt.
Konsistens kallas atomär eller lineariserbar konsistens (atomär eller linjäriserad konsistens), vilket är en egenskap hos systemet, vars alla individuella dataobjekt är atomära (linjäriserbara). I sin tur är ett atomobjekt ett objekt med flera operationer, så att anropet av operationen och mottagandet av svarsdata sker som omedelbart, d.v.s. objektet accepterar inte anropet av nästa operation förrän den föregående operationen är helt slutförd. Ordningen i vilken operationer tas emot måste vara sådan att om en läsoperation anländer efter att någon skrivoperation har utförts, så måste läsoperationen returnera värdet som skrivits av denna eller någon senare skrivoperation.
Ett distribuerat system är alltid tillgängligt om varje förfrågan som tas emot av en icke-misslyckad nod måste besvaras. Systemets motståndskraft mot nätverkspartition modelleras som bevarandet av systemets livskraft i händelse av förlust av ett godtyckligt antal meddelanden som skickas från en nod till en annan.
Baserat på dessa definitioner formulerar Hilbert och Lynch följande teorem (det finns ingen klocka i den asynkrona nätverksmodellen, och noder bör fatta beslut endast på basis av mottagna meddelanden och lokala beräkningar):
I en asynkron nätverksmodell är det inte möjligt att implementera ett läs/skrivdataobjekt som garanterar tillgänglighet och atomär konsistensegenskaper för alla giltiga körningar (inklusive de som förlorar meddelanden).
Denna sats bevisas egentligen helt enkelt formellt med metoden "genom motsägelse". Artikeln fortsätter med att dra slutsatsen att:
I en asynkron nätverksmodell är det inte möjligt att implementera ett läs/skrivdataobjekt som garanterar tillgänglighetsegenskaper för alla giltiga körningar och atomär konsistens för giltiga körningar där meddelanden inte går förlorade.
Dessutom bevisas sanningen i huvudsatsen för en delvis synkron nätverksmodell, där varje nod har en klocka, den tid som visas med vilken ökar i samma takt, men som inte är synkroniserade, d.v.s. kan visa olika tider vid samma verkliga ögonblick. Det har visat sig att för detta fall inte en liknande konsekvens härleds, och därför finns det för delvis synkrona nätverk fler möjligheter att organisera distribuerade system med "bra" egenskaper.
Ja, i en mening (inte nödvändigtvis samma som Brewers avsedda) kan Gilbert och Lynch anses ha bevisat att det är omöjligt att samtidigt säkerställa egenskaperna för atomär konsistens, tillgänglighet och partitionstolerans hos ett nätverk i ett enda distribuerat system. Men vad har detta att göra med databastransaktioner i allmänhet och ACID-transaktioner i synnerhet?
4.3 SYRA-transaktioner
Här är vad Julian Browne skriver om detta i sin anteckning om diskussionen om "satsen" för CAP:
I sitt bevis använder Hilbert och Lynch termen atomicitet istället för konsistens, vilket är mer meningsfullt ur teknisk synvinkel, eftersom konsistens i betydelsen ACID strängt taget hänvisar till de ideala egenskaperna hos databastransaktioner och innebär att ingen data kommer att bli ihållande om de bryter mot vissa förutbestämda restriktioner. Men om vi antar att en förutbestämd begränsning av distribuerade system är förbudet mot närvaron av flera olika värden för samma dataelement, så kan enligt min mening denna brist i abstraktionen av konsistens övervägas obetydlig (om Brewer dessutom använde termen atomicitet, skulle AAP-satsen dyka upp, vars namn skulle vara extremt obekvämt att uttala).
Detta är skrivet inte särskilt seriöst, men ärligt. Och i själva verket bör kravet på atomär konsistens inte blandas med kraven på transaktionskonsistens i betydelsen ACID. Databasintegritetsbegränsningar är logiska, om du så vill, affärskrav. De kommer från applikationsdomänlogik. Kravet på atomär konsistens är av ett helt annat slag. Detta är ett implementeringskrav som faller inom den kategori som traditionellt hänvisas till i databasindustrin som fysisk konsistens (till exempel när du utför någon indexändringsoperation måste alla block i motsvarande B+-träd innehålla giltiga värden och vara länkade med giltiga referenser ).
Och här är vad representanter för databasgemenskapen Daniel Abadi och Alexander Thomson skriver på allvar i sin anteckning:
... kravet på tillgänglighet av skalbara transaktionssystem blir allt mer kritiskt, och detta tillgodoses vanligtvis genom replikering och automatisk omdirigering av förfrågningar i händelse av fel på en av noderna. Därför förväntar sig applikationsutvecklare att konsistensgarantierna för ACID-system (ursprungligen bestående av lokalt stöd för användardefinierade invarianter) kommer att utökas för att säkerställa stark konsistens (att alla repliker av samma data vid varje given tidpunkt kommer att vara identiska kopior, dvs. denna fallkonsistens antyds i betydelsen CAP/PACELC.
Brewer-konsistens har med andra ord ingenting att göra med konsistens i betydelsen ACID, men det är i system fokuserade på att tillhandahålla hög tillgänglighet genom datareplikering som det är önskvärt att upprätthålla en stark replikkonsistens. Detta är inte en ACID-egenskap, utan en teknisk (fysisk) egenskap hos massivt parallell DBMS som underlättar applikationsutveckling.
Enligt Michael Stonebreaker är nyckeln till att bygga ett högkvalitativt modernt DBMS det rätta valet av tekniska kompromisser. När man väljer en specifik ingenjörslösning måste många faktorer beaktas - framtida användares krav, sannolikheten för olika felsituationer, etc., och inte vara dogmatiskt vägledd av några generella teoretiska riktlinjer (inklusive CAP "teorem").
Stonebreaker anser att inom området för transaktionella parallella databassystem är det en dålig avvägning att överge Brewers konsistens till förmån för att stödja hög tillgänglighet och nätverkspartitionstolerans eftersom (a) replikkonsistens är en mycket användbar funktion i systemet; (b) transaktionella massivt parallella DBMS behöver inte kluster med ett mycket stort antal noder, så situationer med uppdelning av nätverk är osannolika; (c) systemet kan lätt bli otillgängligt, inte på grund av en nätverkspartition, utan till exempel på grund av förekomsten av regelbundet förekommande programvarufel.
Den höga aktiviteten hos representanter för NoSQL-lägret (läs NoACID), som ofta hänvisar till Brewers "sats", är alltså inte kopplad till den teoretiska omöjligheten att bygga massivt parallella transaktions-DBMS som stöder ACID-transaktioner, utan med det faktum att förenklade system som inte bara stöder ACID-transaktioner, utan även replikkonsistens, skapas enklare och snabbare. På grund av sin förenklade organisation klarar de mycket snabb databearbetning, och för vissa applikationer är detta viktigare än alla bekvämligheter som är inneboende i databasteknik.
Låt oss se hur databasgemenskapen svarar på denna utmaning.