Teorema CAP

menu icon

Teorema CAP

In questa guida, analizziamo il teorema CAP e la sua pertinenza quando progettiamo applicazioni distribuite e scegliamo un archivio dati relazionale o NoSQL.

Cos'è il teorema CAP?

Hai mai visto una pubblicità per un giardiniere paesaggista, un imbianchino o qualche altro lavoratore specializzato che inizia con il titolo di apertura " Economico, veloce e buono: scegline due"?

Il teorema CAP applica un tipo di logica analogo ai sistemi distribuiti, ovvero che un sistema distribuito può fornire solo due su tre delle caratteristiche desiderate: coerenza, disponibilità, e tolleranza alle partizioni (indicate dalle iniziali dei termini in inglese 'C (consistency)', 'A (availability)' e 'P (partition tolerance)' nell'acronimo CAP).

Un sistema distribuito è una rete che archivia i dati su più di un nodo (macchine fisiche o macchine virtuali) allo stesso tempo. Poiché tutte le applicazioni cloud sono sistemi distribuiti, è fondamentale capire il teorema CAP quando progetti un'app cloud in modo da poter scegliere un sistema di gestione dei dati che fornisca le caratteristiche di cui la tua applicazione ha più bisogno.

Il teorema CAP è noto anche teorema di Brewer, perché è stato avanzato per la prima volta dal professor Eric A. Brewer durante una conferenza che tenne sul calcolo distribuito nel 2000. Due anni dopo, i professori del MIT Seth Gilbert e Nancy Lynch pubblicarono una dimostrazione formale della "congettura di Brewer".

Descrizione di 'CAP' nel teorema di CAP

Diamo uno sguardo dettagliato alle tre caratteristiche del sistema distribuito a cui si riferisce il teorema CAP.

Coerenza

Coerenza significa che tutti i client vedono gli stessi dati contemporaneamente, indipendentemente dal nodo a cui si connettono. Perché questo accada, ogni qualvolta i dati vengono scritti su un nodo, devono essere istantaneamente inoltrati o replicati su tutti gli altri nodi nel sistema prima che la scrittura sia considerata 'riuscita'.

Disponibilità

Disponibilità significa che qualsiasi client che effettua una richiesta di dati ottiene una risposta, anche se uno o più nodi sono inattivi. Per dirlo in altre parole, tutti i nodi di lavoro nel sistema distribuito restituiscono una risposta valida per qualsiasi richiesta, senza eccezioni.

Tolleranza alle partizioni

Una partizione è una interruzione nelle comunicazioni all'interno di un sistema distribuito - una connessione interrotta o temporaneamente ritardata tra due nodi. La tolleranza alle partizioni significa che il cluster deve continuare a funzionare indipendentemente dal numero di interruzioni nelle comunicazioni tra i nodi nel sistema.

Tipi di database NoSQL del teorema CAP

I database NoSQL (non relazionali) sono ideali per le applicazioni di rete distribuite. A differenza delle loro controparti SQL scalabili verticalmente (relazionali), i database NoSQL sono scalabili orizzontalmente e distribuiti a livello di progettazione - possono essere ridimensionati rapidamente in una rete crescente formata da più nodi interconnessi. (Per ulteriori informazioni, consulta "SQL vs. NoSQL Databases: What's the Difference?".)

Attualmente, i database NoSQL sono classificati in base alle due caratteristiche CAP che supportano:

  • Database CP: un database CP fornisce coerenza e tolleranza alle partizioni a discapito della disponibilità. Quando si verifica una partizione tra due nodi qualsiasi, il sistema deve arrestare il nodo non coerente (ossia renderlo non disponibile) fino a quando la partizione non viene risolta.
  • Database AP: un database AP fornisce la disponibilità e la tolleranza alle partizioni a discapito della coerenza. Quando si verifica una partizione, tutti i nodi rimangono disponibili ma quelli all'estremità in errore di una partizione potrebbero restituire una versione meno recente di dati rispetto agli altri. (Quando la partizione viene risolta, i database AP di norme risincronizzano i nodi per risolvere tutte le incoerenze nel sistema.)
  • Database CA: un database CA fornisce coerenza e disponibilità su tutti i nodi. Tuttavia, non può farlo se esiste una partizione tra due nodi nel sistema e, pertanto, non può fornire la tolleranza agli errori.

Abbiamo elencato questo tipo alla fine per un motivo - in un sistema distribuito, le partizioni non possono essere evitate. Così, anche se possiamo discutere di un database distribuito CA in teoria, per tutti gli scopi pratici un database distribuito CA non può esistere. Questo però non significa che non puoi avere un database CA per la tua applicazione distribuita, se te ne serve uno. Molti database relazionali, come PostgreSQL, forniscono coerenza e disponibilità e possono essere implementati su più nodi utilizzando la replica.

MongoDB e il teorema CAP (CP)

MongoDB è un sistema diffuso di gestione del database NoSQL che archivia i dati come documenti BSON (JSON binario). Viene frequentemente utilizzato per i big data e le applicazioni in tempo reale in esecuzione presso più ubicazioni diverse. Relativamente al teorema CAP, MongoDB è un archivio dati CP - risolve le partizioni di rete mantenendo la coerenza, pur a discapito della disponibilità.

MongoDB è un sistema a master singolo - ogni set di repliche (link esterno a IBM) può avere un solo nodo primario che riceve tutte le operazioni di scrittura. Tutti gli altri nodi dello stesso set di repliche sono nodi secondari che replicano il log operazioni del nodo primario e lo applicano al loro dataset. Per impostazione predefinita, anche i client leggono dal nodo primario ma possono anche specificare una preferenza di lettura (link esterno a IBM) che consente loro di leggere da nodi secondari.

Quando il nodo primario diventa non disponibile, il nodo secondario con il log operazioni più recente viene eletto come nuovo nodo primario. Dopo che tutti gli altri nodi secondari si saranno messi in pari con il nuovo master, il cluster diventerà nuovamente disponibile. Poiché i client non possono effettuare richieste di scrittura durante questo intervallo, i dati rimangono coerenti in tutta la rete.

Cassandra e il teorema CAP (AP)

Apache Cassandra è un database open source NoSQL gestito da Apache Software Foundation. È un database a colonne larghe che ti consente di archiviare i dati su una rete distribuita. Tuttavia, a differenza di MongoDB, Cassandra ha un'architettura senza master e, di conseguenza, ha più punti di errore, piuttosto che uno solo.

Relativamente al teorema CAP, Cassandra è un database AP - fornisce la disponibilità e la tolleranza alle partizioni ma non può garantire sempre la coerenza. Perché Cassandra non ha un nodo master, tutti i nodi devono essere disponibili continuamente. Tuttavia, Cassandra fornisce una coerenza eventuale consentendo ai client di scrivere su qualsiasi nodo in qualsiasi momento e riconciliando le incoerenze il più rapidamente possibile.

Poiché i dati diventano incoerenti solo in caso di una partizione di rete e le incoerenze vengono risolte rapidamente, Cassandra offre una funzionalità di "riparazione" (link esterno a IBM) per aiutare i nodi a mettersi in pari con i loro omologhi. Tuttavia, una disponibilità costante si traduce in un sistema altamente performante che, in molti casi, potrebbe valere il compromesso.

Gestione dei microservizi

I microservizi sono componenti applicativi accoppiati in modo lasco e implementabili indipendentemente che incorporano un loro stack, compresi un loro database e modello di database, e comunicano tra loro su una rete. Poiché puoi eseguire i microservizi sia su server cloud che su data center on-premises, sono diventati diffusissimi per le applicazioni ibride e multicloud.

Comprendere il teorema CAP può aiutarti a scegliere il miglior database quando progetti un'applicazione basata sui microservizi in esecuzione da più ubicazioni. Ad esempio, se la capacità di iterare rapidamente il modello di dati ed eseguire la scalabilità orizzontale sono essenziali per la tua applicazione, ma puoi tollerare una coerenza eventuale (anziché stretta), un database AP come Cassandra o Apache CouchDB può soddisfare i tuoi requisiti e semplificare la tua implementazione. D'altra parte, se la tua applicazione dipende in notevole misura dalla coerenza dei dati, come in un'applicazione di e-commerce o un servizio di pagamento, potresti optare per un database relazionale come PostgreSQL.

Teorema CAP e IBM Cloud

IBM offre un'intera gamma di servizi di database completamente gestiti. Oltre ai sistemi di gestione dei database relazionali, puoi anche eseguire MongoDB, Cloudant (un altro archivio dati distribuito AP), Elasticsearch, etcd e altre soluzioni database su IBM Cloud.

Per consultare la nostra scelta completa di database (senza alcun impegno), registrati per un IBMid e crea il tuo account IBM Cloud.