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, che possono fornire solo due delle tre caratteristiche desiderate: coerenza, disponibilità e tolleranza di partizione (che in inglese formano l'acronimo C, A, P).

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”.

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.

I database VoSQL sono ideali per le applicazioni di rete distribuita. A differenza delle loro controparti SQL (relazionali) scalabili verticalmente, i database NoSQL sono scalabili orizzontalmente e distribuiti in base alla progettazione: possono adattarsi rapidamente a una rete in crescita composta da più nodi interconnessi. (Per ulteriori 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 consistenza 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 consistenza 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 consistenza 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 consistenza, ma compromettendo la disponibilità.

MongoDB è un sistema a singolo master: ciascuna serie di replica (collegamento all'esterno ibm.com) 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 (collegamento all'esterno ibm.com) 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 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 finale 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" 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.

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 consistenza 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 dati, come in un'applicazione di eCommerce o in un servizio di pagamento, potresti optare per un database relazionale come PostgreSQL.