4.1 Összhang a Brewerával kapcsolatban
Először is, Eric Brewer nem adatbázis-szakértő, és soha nem is állította, hogy ő lenne. Az elosztott rendszerek közösségéhez tartozik, híres előadása, amelyben a CAP „tétele” megjelent, az „Elosztott számítástechnika alapelvei” című konferencián hangzott el. (Egyébként tíz évvel később, 2010-ben ismét meghívott előadást tartott ugyanezen a konferencián, és ezen az előadáson különösen az elosztott rendszerekre hozott számos példát, amelyek fejlesztése során figyelembe vették a " tétele" a CAP.) Ezen a területen saját értelmezése van az adatbázisok területén használt kifejezéseknek.
Az „azonnali konzisztencia” kifejezés különösen azt jelenti, hogy miután a felhasználó értesítést kap a rendszertől valamilyen adatfrissítési művelet sikeres befejezéséről, a művelet eredménye azonnal láthatóvá válik minden megfigyelő számára.
A végső konzisztencia azt jelenti, hogy ha kellően hosszú ideig nem lépnek be új adatfrissítési műveletek a rendszerbe, akkor várható, hogy az összes korábbi adatfrissítési művelet eredménye végül a rendszer összes csomópontjára terjed, és minden replika adat konzisztens (nyilván ezt úgy kell érteni, hogy "minden replika azonos állapotú lesz".
A konzisztencia ezen érzetét szem előtt tartva Brewer „tétele” egészen érthetőnek és kézenfekvőnek tekinthető: bármely megosztott adatokkal rendelkező elosztott rendszerben egyszerre csak a hálózat bármely két tulajdonsága biztosítható: a konzisztencia, a rendelkezésre állás és a partíciótűrés. Ebben a tekintetben Brewer még az ACID tulajdonságok halmazát is szembeállítja az általa javasolt BASE tulajdonságokkal (alapvetően elérhető, lágy állapot, végső konzisztencia - a legtöbb esetben elérhető; instabil állapot; végső konzisztencia). De ez az ellenkezés véleményem szerint indokolatlan, mivel az első esetben a tranzakciók logikai jellemzőiről, a második esetben pedig az elosztott rendszerek fizikai tulajdonságairól beszélünk.
4.2 A "tétel" bizonyítása
Sokan úgy vélik, hogy Brewer „tétele” formálisan bebizonyosodott. Valójában Seth Gilbert és Nancy Lynch írása bevezet néhány (majdnem) formális definíciót, amelyben a „tétel” valóban tétellé válik, és bebizonyosodik. Nézzük azonban meg, hogyan határozható meg egy elosztott rendszernek az a három tulajdonsága, amelyek közül Brewer „tétele” szerint egyszerre csak két tulajdonság támogatható.
A konzisztenciát atomi, vagy linearizálható konzisztenciának (atomi, vagy linearizálható konzisztenciának) nevezzük, amely annak a rendszernek a tulajdonsága, amelynek minden egyes adatobjektuma atomi (linearizálható). Az atomi objektum viszont több művelettel rendelkező objektum, így a művelet hívása és a válaszadatok fogadása mintha azonnal megtörténik, azaz. az objektum nem fogadja el a következő művelet hívását, amíg az előző művelet teljesen be nem fejeződött. A műveletek fogadásának sorrendjének olyannak kell lennie, hogy ha valamilyen írási művelet végrehajtása után érkezik egy olvasási típusú művelet, akkor az olvasási műveletnek az ezzel vagy egy későbbi írási művelettel írt értéket kell visszaadnia.
Az elosztott rendszer mindig rendelkezésre áll, ha minden, nem sikertelen csomópont által kapott kérésre válaszolni kell. A rendszer hálózati partíciókkal szembeni ellenálló képességét úgy modellezzük, mint a rendszer életképességének megőrzését az egyik csomóponttól a másikba küldött tetszőleges számú üzenet elvesztése esetén.
E definíciók alapján Hilbert és Lynch a következő tételt fogalmazza meg (az aszinkron hálózati modellben nincs óra, és a csomópontok csak a kapott üzenetek és helyi számítások alapján döntsenek):
Egy aszinkron hálózati modellben nem lehet olyan olvasási/írási adatobjektumot megvalósítani, amely garantálja a rendelkezésre állást és az atomi konzisztencia tulajdonságokat minden érvényes végrehajtáshoz (beleértve azokat is, amelyek elveszítik az üzeneteket).
Ezt a tételt valójában egész egyszerűen formálisan igazoljuk az "ellentmondásos" módszerrel. A cikk arra a következtetésre jut, hogy:
Egy aszinkron hálózati modellben nem lehet olyan olvasási/írási adatobjektumot megvalósítani, amely garantálja a hozzáférhetőségi tulajdonságokat az összes érvényes végrehajtáshoz, és az atomi konzisztenciát az olyan érvényes végrehajtásokhoz, amelyekben az üzenetek nem vesznek el.
Ezen túlmenően a főtétel igazsága bizonyítást nyert egy részlegesen szinkron hálózati modellre, amelyben minden csomópontnak van egy órája, amely által mutatott idő azonos ütemben növekszik, de amelyek nincsenek szinkronizálva, azaz. különböző időpontokat mutathat ugyanabban a valós pillanatban. Megmutattuk, hogy ebben az esetben hasonló következmény nem származik, és ezért a részlegesen szinkron hálózatok esetében több lehetőség van "jó" tulajdonságokkal rendelkező elosztott rendszerek szervezésére.
Igen, bizonyos értelemben (nem feltétlenül megegyezik Brewer szándékával) Gilbert és Lynch bebizonyította, hogy egyetlen elosztott rendszerben lehetetlen egyszerre biztosítani a hálózat atomkonzisztenciájának, rendelkezésre állásának és partíciótűrésének tulajdonságait. De mi köze ennek az adatbázis-tranzakciókhoz általában és az ACID-tranzakciókhoz különösen?
4.3 ACID-tranzakciók
Julian Browne ezt írja erről a KAP „tételének” tárgyalásáról szóló jegyzetében:
Hilbert és Lynch bizonyításukban az atomitás kifejezést használja a konzisztencia helyett, ami technikai szempontból sokkal értelmesebb, mivel szigorúan véve az ACID értelmében vett konzisztencia az adatbázis-tranzakciók ideális tulajdonságaira utal, és azt jelenti, hogy semmilyen adat nem fog tartóssá válnak, ha megsértenek néhány előre meghatározott korlátozást. De ha feltételezzük, hogy az elosztott rendszerek előre meghatározott korlátja több különböző érték jelenlétének tilalma ugyanarra az adatelemre vonatkozóan, akkor véleményem szerint ez a konzisztencia absztrakciójának hibája tekinthető. jelentéktelen (ráadásul, ha Brewer az atomitás kifejezést használná, akkor megjelenne az AAP tétel, aminek a nevét rendkívül kényelmetlen lenne kiejteni).
Ez nem túl komolyan van megírva, hanem őszintén. Valójában az atomi konzisztencia követelményét nem szabad összekeverni a ACID értelmében vett tranzakciós konzisztencia követelményeivel. Az adatbázis-integritási korlátozások logikusak, ha úgy tetszik, üzleti követelmények. Az alkalmazási tartomány logikájából származnak. Az atomi konzisztencia követelménye egészen más jellegű. Ez egy olyan megvalósítási követelmény, amely az adatbázisiparban hagyományosan fizikai konzisztenciaként emlegetett kategóriába tartozik (például bármilyen indexmódosítási művelet végrehajtásakor a megfelelő B+ fa minden blokkjának érvényes értékeket kell tartalmaznia, és érvényes hivatkozásokkal kell összekapcsolni ).
És íme, amit az adatbázis-közösség képviselői Daniel Abadi és Alexander Thomson egészen komolyan írnak jegyzetükben:
... a méretezhető tranzakciós rendszerek elérhetőségének követelménye egyre kritikusabb, és ez általában a kérések replikációjával és automatikus átirányításával teljesül az egyik csomópont meghibásodása esetén. Ezért az alkalmazásfejlesztők arra számítanak, hogy az ACID-rendszerek (eredetileg a felhasználó által definiált invariánsok helyi támogatásából álló) konzisztenciagaranciáit kiterjesztik, hogy biztosítsák az erős konzisztenciát (hogy ugyanazon adatok minden replikája egy adott időpontban azonos másolat legyen, azaz ez az eset konzisztenciája a CAP/PACELC értelmében.
Más szavakkal, a Brewer konzisztenciának semmi köze az ACID értelmében vett konzisztenciához, de azokban a rendszerekben, amelyek magas szintű rendelkezésre állást biztosítanak az adatok replikációján keresztül, kívánatos az erős replikakonzisztencia fenntartása. Ez nem ACID tulajdonság, hanem a masszívan párhuzamos DBMS technikai (fizikai) jellemzője, amely megkönnyíti az alkalmazásfejlesztést.
Michael Stonebreaker szerint a magas színvonalú modern DBMS felépítésének kulcsa a műszaki kompromisszumok megfelelő megválasztása. Egy konkrét mérnöki megoldás kiválasztásakor számos tényezőt figyelembe kell venni - a jövőbeni felhasználók igényeit, a különféle meghibásodási helyzetek valószínűségét stb., és nem szabad dogmatikusan vezérelni semmilyen általános elméleti irányelvet (beleértve a CAP „tételét”).
Stonebreaker úgy véli, hogy a tranzakciós párhuzamos adatbázis-rendszerek területén a Brewer-féle konzisztencia feladása a magas rendelkezésre állás és a hálózati partíciótűrés támogatása érdekében rossz kompromisszum, mivel (a) a replika konzisztenciája a rendszer nagyon hasznos funkciója; (b) a tranzakciós masszívan párhuzamos DBMS-eknek nincs szükségük nagyon sok csomóponttal rendelkező fürtökre, így a hálózat felosztása nem valószínű; (c) a rendszer könnyen elérhetetlenné válhat, nem hálózati partíció miatt, hanem például rendszeresen előforduló szoftverhibák miatt.
A Brewer-féle „tételre” gyakran hivatkozó NoSQL-tábor (értsd: NoACID) képviselőinek nagy aktivitása tehát nem az ACID-tranzakciókat támogató, masszívan párhuzamos tranzakciós DBMS-ek felépítésének elméleti lehetetlenségével függ össze, hanem azzal, hogy az egyszerűsített rendszerek. amelyek nem csak az ACID tranzakciókat támogatják, hanem a replika konzisztenciát is, könnyebben és gyorsabban jönnek létre. Leegyszerűsített felépítésüknek köszönhetően igen gyors adatfeldolgozásra képesek, és egyes alkalmazásoknál ez fontosabb, mint az adatbázis-technológiában rejlő minden kényelem.
Nézzük meg, hogyan reagál az adatbázis-közösség erre a kihívásra.