CAP-tétel

A Wikipédiából, a szabad enciklopédiából

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.

Források[szerkesztés]