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.
