CAP-tétel
A CAP-tétel (Consistency + Availability + Partition tolerance, vagy más néven Brewer tétele) kimondja, hogy egy elosztott adattároló rendszer a három alapvető képesség közül (konzisztencia, rendelkezésre állás, particionálástűrés) legfeljebb kettőt tud megvalósítani.
Elosztott rendszerek alapképességei
[szerkesztés]Az elosztott rendszerek három alapképességgel írhatók körül, aszerint, hogy a képességekkel rendelkeznek-e, vagy csak részben, korlátozottan rendelkeznek velük, vagy egyáltalán nincs meg bennük.
Konzisztencia, következetesség (Consistency)
[szerkesztés]Minden lekérés a legutóbbi írás eredményét adja vissza, vagy hibát.
Ezt az ACID-elvet alkalmazva valósítják meg a különböző adatbázis-kezelők (bár fontos megjegyezni, hogy az ott definiált konzisztencia nem azonos a CAP-tételben definiálttal). Azonban ha egy elosztott alkalmazást nem egy adatbázis szolgál ki, hanem az adatbázis is elosztott, akkor ezen elv megtartása nem triviális.
Rendelkezésre állás (Availability)
[szerkesztés]Minden kérésre (nem hiba) válasz érkezik, de nem garantálja, hogy a legfrissebb verziót adja vissza.
Particionálástűrés (Partition tolerability)
[szerkesztés]A rendszer továbbra is működik annak ellenére, hogy a hálózat tetszőleges számú üzenetet elhagy (vagy késleltet) a csomópontok között.
Döntés, ha hálózatipartíció-hiba történik
[szerkesztés]- Törölje a műveletet, és ezzel csökkentse a rendelkezésre állást, de biztosítsa a következetességet.
vagy
- Folytassa a műveletet, és így biztosítsa a rendelkezésre állást, de kockáztassa meg az inkonzisztenciát (inconsistency).
A CAP-tétel kimondja, hogy partícióhiba megjelenésekor a konzisztencia és a rendelkezésre állás között kell választani.
Gyakorlati megvalósítások
[szerkesztés]Hálózati hiba hiányában – vagyis ha az elosztott rendszer normálisan működik – mind a rendelkezésre állás, mind a konzisztencia elérhető.
Gyakori félreértés, hogy mindig el kell hagyni a három garancia valamelyikét. Valójában csak a konzisztencia és a rendelkezésre állás között kell választani, ha hálózatipartíció-hiba történik; minden más esetben szükségtelen kompromisszumot kötni.
A hagyományos ACID-ekkel tervezett adatbázis-rendszerek, mint például az RDBMS, a konzisztenciát választják a rendelkezésre állás helyett, míg a BASE filozófiája körül kialakított rendszerek (például NoSQL) a rendelkezésre állást választják a konzisztencia helyett.
- Particionálástűrés csökkentése: a megszorítás feloldható, ha minden adatot, ami részt vesz egy tranzakcióban, egy gépen tartunk - vagyis az adattároló rendszer nem elosztott. A megoldás hátránya, hogy az alkalmazás szempontjából az adatbázis csak vertikálisan lesz skálázható (minden sebességnövelésre szolgáló bővítés csak egy gépben lehetséges, aminek fizikai korlátai vannak)
- Rendelkezésre állás csökkentése: ha a rendszer particionálódik, mert mondjuk egyik adatbázisban eltérő adat szerepel, mint a másikban, akkor a partíciók megszűnéséig leállítjuk az alkalmazást, és az adatbázis-kezelőkre bízzuk az egységesítést.
- Konzisztencia enyhítése: vannak alkalmazások, amelyek nem követelik meg, hogy minden esetben a legfrissebb adatot adják vissza. Ezeknél egy bizonyos méretű időablakon belül elképzelhető, hogy korábbi adatokkal szolgálnak. Például a Google találatai közé 1-2 hét elteltével kerül be egy-egy új oldal, vagy a DNS-regisztrációt követően egy hetet kell legalább várni, míg a domain használhatóvá válik.
Fordítás
[szerkesztés]Ez a szócikk részben vagy egészben a CAP theorem című angol Wikipédia-szócikk fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.
