„CAP-tétel” változatai közötti eltérés
| [nem ellenőrzött változat] | [nem ellenőrzött változat] |
Tartalom törölve Tartalom hozzáadva
Érthetőbbé prübáltam tenni, az angol verzió alapján: https://en.wikipedia.org/wiki/CAP_theorem |
Címkék: HTML-sortörés Vizuális szerkesztés |
||
4. sor:
Az elosztott rendszerek három alapképességgel írhatok 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.
===
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)'' ===
13 ⟶ 15 sor:
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.
<br />
==== Ha egy hálózati partíció hiba történik, akkor kell-e döntenünk: ====
* Törölje a műveletet, és ezzel csökkentse a rendelkezésre állást, de biztosítsa a következetességet
* Folytassa a művelettel, és így biztosítsa a rendelkezésre állást, de kockáztassa meg az inkonzisztenciát (inconsistency).A KAP 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 ==
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ő.
* '''Particionálás-tűrés csökkentése:''' a megszorítás feloldható, ha minden adatot, ami részt vesz egy tranzakcióban egy gépen tartunk. 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ég növekedése szolgáló bővítés, csak egy gépben lehetséges, aminek fizikai korlátai vannak)▼
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ózati partíció vagy hiba történik; minden más esetben szükségtelen kompromisszumot kötni.
* '''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ás é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- ([[Domain Name System]]) regisztrációt követően egy hetet kell legalább várni, míg a [[domain]] használhatóvá válik.▼
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.
▲*
▲*
▲*
== Lásd még ==
| |||