Che cos'è il teorema CAP?

Il teorema CAP afferma che un sistema distribuito può fornire solo due delle tre caratteristiche desiderate:
coerenza (consistency), disponibilità (availability) e tolleranza di partizione (partition tolerance) (la "C", la "A"e la "P" in CAP).

Hai mai visto la pubblicità di un imbianchino, di un falegname o di un altro artigiano con lo slogan "Economico, veloce e di qualità: scegline solo due"? Il teorema CAP applica un tipo di logica simile ai sistemi distribuiti.

Un sistema distribuito è una rete che memorizza i dati su più di un nodo allo stesso tempo (nodi fisici o macchine virtuali). Poiché tutte le applicazioni cloud sono sistemi distribuiti, al momento della progettazione è essenziale comprendere il teorema CAP in modo da poter scegliere un sistema di gestione dati in grado di fornire le caratteristiche di cui la tua applicazione ha più bisogno.

Il teorema CAP è detto anche teorema di Brewer, perché è stato ideato per la prima volta dal professor Eric A. Brewer nel 2000 durante una conferenza sul computing distribuito. Due anni dopo, i professori del MIT Seth Gilbert e Nancy Lynch pubblicarono una dimostrazione della “Congettura di Brewer”.

Esaminiamo in modo dettagliato le tre caratteristiche del sistema distribuito a cui si riferisce il teorema CAP.

Consistenza

Consistenza significa che tutti i clienti vedono contemporaneamente gli stessi dati, indipendentemente dal nodo a cui si connettono. Affinché ciò accada, ogni volta che i dati vengono scritti su un nodo, devono essere immediatamente inoltrati o replicati a tutti gli altri nodi nel sistema prima che la scrittura venga considerata "riuscita".

Disponibilità

Disponibilità significa che un cliente che effettua una richiesta di dati riceve una risposta, anche se uno o più nodi sono inattivi. In altre parole, tutti i nodi funzionanti nel sistema distribuito restituiscono una risposta valida per qualsiasi richiesta, senza eccezioni.

Tolleranza alle partizioni

Una partizione è un'interruzione delle comunicazioni all'interno di un sistema distribuito: una connessione persa o temporaneamente ritardata tra due nodi. La tolleranza alle partizioni significa che il cluster deve continuare a funzionare anche quando si verificano interruzioni di comunicazione tra i nodi del sistema.

I database NoSQL sono ideali per le applicazioni di rete distribuite. A differenza delle loro controparti SQL (relazionali) scalabili verticalmente, i database NoSQL sono scalabili orizzontalmente e distribuiti by design: possono adattarsi rapidamente a una rete in crescita composta da più nodi interconnessi. (Per maggiori informazioni, vedi "Database SQL e NoSQL: qual è la differenza?")

Oggi, i database NoSQL sono classificati in base alle due caratteristiche CAP supportate:

• Database CP: un database CP offre coerenza e tolleranza alle partizioni a scapito della disponibilità. Quando si verifica una partizione tra due nodi, il sistema deve arrestare il nodo non coerente (ovvero renderlo non disponibile) fino a quando la partizione non viene risolta.
  
  
• Database AP: un database AP offre disponibilità e tolleranza alle partizioni a scapito della consistenza. Quando si verifica una partizione, tutti i nodi rimangono disponibili, ma quelli dal lato sbagliato di una partizione potrebbero restituire una versione precedente dei dati rispetto ad altri. (Quando la partizione viene risolta, i database AP solitamente risincronizzano i nodi per riparare tutte le inconsistenze nel sistema).
  
  
• Database CA: un database CA offre coerenza e disponibilità su tutti i nodi. Tuttavia, non può farlo se esiste una partizione tra due nodi nel sistema e quindi non può garantire tolleranza agli errori.

Abbiamo elencato per ultimo il tipo di database CA per una ragione ben precisa: in un sistema distribuito, le partizioni non si possono evitare. Pertanto, mentre in teoria possiamo discutere di un database distribuito CA, a tutti gli effetti un database distribuito CA non può esistere. Ciò non significa che non è possibile avere un database CA per la propria applicazione distribuita, in caso di esigenze. Molti database relazionali, come PostgreSQL, offrono coerenza e disponibilità e possono essere distribuiti su più nodi tramite replica.

MongoDB è un sistema di gestione database NoSQL molto diffuso che archivia i dati come documenti BSON (JSON binario). Viene spesso utilizzato per big data e applicazioni in tempo reale in esecuzione in più posizioni diverse. Rispetto al teorema CAP, MongoDB è un archivio dati CP: risolve le partizioni di rete mantenendo la coerenza, ma compromettendo la disponibilità.

MongoDB è un sistema single-master: ogni set di repliche può avere un solo nodo primario che riceve tutte le operazioni di scrittura. Tutti gli altri nodi nella stessa serie di replica sono nodi secondari che replicano il log delle operazioni del nodo primario e lo applicano alla propria serie di dati. Di default, anche i client leggono dal nodo primario, ma possono anche specificare una preferenza di lettura che consente loro di leggere da nodi secondari.

Quando il nodo primario diventa non disponibile, il nodo secondario con il log operazioni più recente sarà scelto come nuovo nodo primario. Dopo che tutti gli altri nodi secondari raggiungono il nuovo master, il cluster diventa nuovamente disponibile. Poiché i client non possono effettuare richieste di scrittura durante questo intervallo, i dati rimangono consistenti su tutta la rete.

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

Rispetto al teorema CAP, Cassandra è un database AP: offre disponibilità e tolleranza alle partizioni, ma non è in grado di garantire sempre la coerenza. Poiché Cassandra non ha un nodo master, tutti i nodi devono essere disponibili continuamente. Tuttavia, Cassandra fornisce una coerenza finale consentendo ai client di scrivere su qualsiasi nodo in qualsiasi momento e riconciliando le incongruenze il più rapidamente possibile.

Poiché i dati diventano inconsistenti solo nel caso di una partizione di rete e le inconsistenze si risolvono rapidamente, Cassandra offre una funzionalità di "riparazione" per aiutare i nodi a mettersi in pari con i loro corrispondenti. Tuttavia, la disponibilità costante determina un sistema ad alte prestazioni, che in molti casi potrebbe valere il compromesso.

I microservizi sono componenti applicativi liberamente accoppiati e distribuibili in modo indipendente che incorporano il proprio stack, inclusi il proprio database e il proprio modello di database, e comunicano tra loro tramite una rete. Poiché è possibile eseguire i microservizi sia su server cloud che su data center on-premises, sono diventati molto popolari per le applicazioni ibride e multicloud.

La comprensione del teorema CAP può aiutarti a scegliere il database migliore quando progetti un'applicazione basata su microservizi in esecuzione da più ubicazioni. Ad esempio, se la capacità di iterare rapidamente il modello di dati e ridimensionare orizzontalmente è essenziale per l'applicazione, ma è possibile tollerare la coerenza finale (anziché quella rigorosa), un database AP come Cassandra o Apache CouchDB può soddisfare i requisiti e semplificare la distribuzione. D'altra parte, se la tua applicazione dipende strettamente dalla coerenza dei dati, come in un'applicazione di e-commerce o in un servizio di pagamento, potresti optare per un database relazionale come PostgreSQL.