Teorema PACELC
Nell'informatica teorica, il teorema PACELC è un'estensione del teorema CAP. Asserisce che nel caso di tolleranza di partizione (P) in un sistema informatico distribuito si deve scegliere tra disponibilità (A) e consistenza (C) (come per il teorema CAP), ma altrimenti (E), anche quando il sistema è in esecuzione normalmente in assenza di partizioni, si deve scegliere tra latenza (L) e consistenza (C).
Descrizione[modifica | modifica wikitesto]
PACELC si basa sul teorema CAP. Entrambi i teoremi descrivono come i database distribuiti abbiano delle limitazioni e presentano i compromessi relativi a consistenza, disponibilità e tolleranza al partizionamento dei dati. PACELC tuttavia va oltre e asserisce che esiste anche un compromesso, questa volta tra latenza e consistenza, anche in assenza di partizioni, fornendo così una rappresentazione più completa del potenziale compromesso per sistemi distribuiti.[1]
Un requisito di alta disponibilità implica che il sistema debba replicare dei dati. Non appena un sistema distribuito replica dei dati, nasce un compromesso tra consistenza e latenza.
Il teorema PACELC è stato inizialmente descritto nel 2010 da Daniel J. Abadi nell'università di Yale in un post di un blog,[2] che successivamente formalizzò in uno scritto nel 2012.[3] Lo scopo di PACELC è di indirizzare la sua tesi che "ignorando il conflitto consistenza/latenza di sistemi replicati è uno dei principali errori in CAP, visto che questo è presente in tutte le operazioni di sistema, mentre CAP è soltanto rilevante nei rari casi di tolleranza di partizione."
Classifica dei database rispetto a PACELC[modifica | modifica wikitesto]
La classifica dei database rispetto a PACELC è ripreso da [4]
- Le versioni predefinite di Dynamo, Cassandra e Riak sono sistemi PA/EL: se occorre una partizione, essi rinunciano alla consistenza per la disponibilità e sotto operazioni normali essi rinunciano alla consistenza per bassa latenza.
- Sistemi rispettanti completamente ACID come VoltDB/H-Store e Megastore sono PC/EC: rifiutano di rinunciare alla consistenza e, per raggiungerla, pagano in disponibilità e costi di latenza. Anche BigTable e sistemi congiunti come HBase sono PC/EC.
- MongoDB può essere classificato come un sistema PC/EC: nel caso base il sistema garantisce la consistenza di letture e scritture.
- PNUTS è un sistema PC/EL.
| DDBS | P+A | P+C | E+L | E+C |
|---|---|---|---|---|
| Dynamo | sì | sì[5] | ||
| Cassandra | sì | sì[5] | ||
| Riak | sì | sì[5] | ||
| VoltDB/H-Store | sì | sì | ||
| Megastore | sì | sì | ||
| MongoDB | sì | sì | ||
| PNUTS | sì | sì |
Note[modifica | modifica wikitesto]
- ^ "Consistency Tradeoffs in Modern Distributed Database System Design", di Daniel J. Abadi, Università di Yale
- ^ DBMS Musings: Problems with CAP, and Yahoo’s little known NoSQL system, su dbmsmusings.blogspot.ie. URL consultato l'11 settembre 2016.
- ^ Consistency Tradeoffs in Modern Distributed Database System Design (PDF), su cs-www.cs.yale.edu.
- ^ "Consistency Tradeoffs in Modern Distributed Database System Design" slide summary by Arinto Murdopo, Research Engineer
- ^ a b c Dynamo, Cassandra, and Riak have user-adjustable settings to control the LC tradeoff.
Voci correlate[modifica | modifica wikitesto]
Collegamenti esterni[modifica | modifica wikitesto]
- "Consistency Tradeoffs in Modern Distributed Database System Design", di Daniel J. Abadi, Università di Yale scritto originale che formalizzò PACELC
- "Problems with CAP, and Yahoo’s little known NoSQL system", di Daniel J. Abadi, Università di Yale. Post originale sul blog che descrisse per primo PACELC