PACELC tétel
Az oldal jelenlegi verzióját még nem ellenőrizték tapasztalt közreműködők, és jelentősen eltérhet a 2021. május 17-én felülvizsgált
verziótól ; az ellenőrzések 6 szerkesztést igényelnek .
A PACELC tétel a CAP tétel kiterjesztése , amely kimondja, hogy egy elosztott számítógépes rendszerben a hálózati szétválasztás (P) esetén választani kell a rendelkezésre állás (A) és a konzisztencia (C) között (a CAP tétel szerint), de mindenesetre, még akkor is, ha a rendszer normálisan működik szétválasztás (E) hiányában, választani kell a késleltetések (L) és a konzisztencia (C) között.
Leírás
A PACELC tétel a CAP tételre épül . Mindkét tétel leírja azokat a korlátokat és kompromisszumokat, amelyekkel az elosztott adatbázisok rendelkeznek a konzisztencia, a rendelkezésre állás és a particionálás tekintetében. A PACELC tétel azonban kimondja, hogy a késleltetés és a konzisztencia között még particionálás hiányában is van kompromisszum, ami teljesebb képet ad az elosztott rendszerek lehetséges kompromisszumairól. [egy]
A magas rendelkezésre állás követelménye azt jelenti, hogy a rendszernek replikálnia kell az adatokat. Míg egy elosztott rendszer replikálja az adatokat, kompromisszum van a konzisztencia és a késleltetés között.
A PACELC-tételt először Daniel J. Abadi, a Yale Egyetemről írta le 2010-ben egy blogbejegyzésében [2] , majd 2012-ben cikkként is [1] . A PACELC-tétel fő célja, hogy kifejtse tézisét: „A konzisztencia és a késleltetés közötti választás igényének figyelmen kívül hagyása a replikált rendszerekben jelentős hiányosság [a CAP-on belül], mivel ennek a választásnak az igénye mindig jelen van a rendszer működése során. míg a CAP csak a hálózati szétválasztás tárgyalt ritka esetére vonatkozik.
A fő DBMS kiértékelése a PACELC tétel szerint
DBMS becslések a következőhöz: [3]
- Alapértelmezés szerint a Dynamo, a Cassandra , a Riak és a Cosmos DB PA/EL rendszerek: a hálózat felosztásakor elvesztik a koherenciát a magasabb rendelkezésre állás érdekében, normál működés során pedig az alacsonyabb késleltetés miatt.
- A teljesen ACID rendszerek, mint például a VoltDB /H-Store és a Megastore PC/EC: nem adnak fel a konzisztenciáról, és hajlandóak lesznek fizetni a rendelkezésre állás és a késleltetés miatt, hogy ezt elérjék. A BigTable és a kapcsolódó rendszerek, például a HBase szintén PC/EC.
- A Couchbase egy sor osztott idejű konzisztencia és rendelkezésre állás opciót, valamint egy sor késleltetési és nem osztott konzisztencia opciót kínál. A legtöbb más adatbázistól eltérően a Couchbase nem rendelkezik egyetlen API-készlettel, és nem replikálja egységesen az összes adatszolgáltatást. Írásnál a Couchbase a konzisztenciát részesíti előnyben az akadálymentesítéssel szemben, formálisan CP-vé teszi, de az olvasásnál nagyobb a felhasználó által vezérelt variabilitás az indexreplikációtól, a kívánt konzisztenciaszinttől és a hozzáférés típusától függően (egy dokumentumban végzett keresés vs. tartománybeolvasás, illetve teljes szöveg keresés stb.) .) . Ezen túlmenően további változékonyság érhető el a cross-datacenter replikációtól (XDCR) függően, amely több CP-fürtöt vesz fel és kapcsolja össze őket aszinkron replikációval, valamint a Couchbase Lite-től, amely egy beágyazott adatbázis, és egy teljesen több főkiszolgálót hoz létre (verziókezeléssel). ). ) elosztott topológia.
- A Cosmos DB öt konfigurálható konzisztencia szintet támogat, amelyek lehetővé teszik a C/A közötti választást a hálózati particionálás során és az L/C közötti választást normál működés közben. A Cosmos DB soha nem sérti meg a megadott konzisztencia szintet, ezért formálisan CP.
- A MongoDB a PA/EC rendszerekhez sorolható. Alapesetben a rendszer garantálja az olvasási és írási konzisztenciát.
- A PNUTS egy PC/EL rendszer.
| DDBS
|
P+A
|
P+C
|
E+L
|
E+C
|
| Dinamó
|
Igen
|
|
igen [a]
|
|
| Cassandra
|
Igen
|
|
igen [a]
|
|
| Cosmos DB
|
Igen
|
|
Igen
|
|
| Couchbase
|
|
Igen
|
Igen
|
Igen
|
| Riak
|
Igen
|
|
igen [a]
|
|
| VoltDB/H Store
|
|
Igen
|
|
Igen
|
| Mega bolt
|
|
Igen
|
|
Igen
|
| MongoDB
|
Igen
|
|
|
Igen
|
| PNUTS
|
|
Igen
|
Igen
|
|
Lásd még
Jegyzetek
- ↑ 1 2 3 A Dynamo, Cassandra és Riak rendelkezik az L és C közötti választás szabályozásával [3]
Források
- ↑ 1 2 Daniel J. Abadi. Következetes kompromisszumok a modern elosztott adatbázis-rendszer tervezésében // Yale Egyetem. - 2012. - január 25. Archiválva az eredetiből 2017. május 16-án.
- ↑ Daniel J. Abadi. DBMS Musings: Problémák a CAP-pel és a Yahoo kevéssé ismert NoSQL rendszerével . dbmsmusings.blogspot.ie (2010. április 23.). Letöltve: 2016. szeptember 11. Az eredetiből archiválva : 2016. szeptember 6.. (határozatlan)
- ↑ 1 2 Arinto Murdopo. Következetes kompromisszumok a modern elosztott adatbázis-rendszer tervezésében . - 2012. - április 17. Archiválva az eredetiből 2016. augusztus 22-én.
Linkek