Teorema CAP
IBM® Cloudant® for IBM Cloud® utilizza un modello "eventualmente congruente" . Quando effettui un aggiornamento a una parte di IBM Cloudant,
l'aggiornamento viene infine visualizzato da altre parti del sistema.
Per comprendere come funziona questo modello e perché è una parte essenziale dell'utilizzo di IBM Cloudant, considera cosa si intende per Congruenza.
La congruenza è una delle quattro proprietà "ACID" necessarie per elaborare e segnalare in modo affidabile le transazioni in un database.
Inoltre, la coerenza è uno dei tre attributi nel teorema "CAP" . Gli attributi sono consistenza (Consistency), disponibilità (Availability) e tolleranza di partizione (Partition tolerance). Il teorema afferma che non è possibile per un sistema di computer distribuito come IBM Cloudant per garantire tre attributi simultaneamente:
- Consistenza, dove tutti i nodi vedono gli stessi dati nello stesso momento.
- Disponibilità, che garantisce che ogni richiesta riceva una risposta su ciò che è riuscito o non riuscito.
- Tolleranza di partizione, dove il sistema continua a funzionare nonostante perdite o errori di una parte del sistema.
L'impossibilità di garantire tutti e tre gli attributi contemporaneamente significa che IBM Cloudant non garantisce l'attributo Consistency. Man mano che l'aggiornamento si propaga, si dice che il sistema "converge" sulla coerenza completa.
La consistenza eventuale è utile per le prestazioni. Con un forte modello di consistenza, un sistema deve attendere che gli aggiornamenti siano propagati completamente e correttamente prima che una richiesta di scrittura o aggiornamento possa essere completata. Con un modello eventualmente congruente, la richiesta di scrittura o di aggiornamento può essere restituita quasi immediatamente, mentre la propagazione attraverso il sistema continua dietro le quinte.
Un database può dimostrare solo due di questi tre attributi per motivi sia teorici che pratici. Un database che assegna priorità alla congruenza e alla disponibilità è semplice: un singolo nodo memorizza una singola copia dei propri dati. Ma questo modello è difficile da ridimensionare in quanto per ottenere maggiori prestazioni devi aggiornare il nodo anziché utilizzare nodi aggiuntivi. Inoltre, anche un minimo errore di sistema può arrestare un sistema a singolo nodo mentre una qualsiasi perdita di messaggi indica una perdita di dati significativi. Per resistere, il sistema deve diventare più sofisticato.
Compromessi nella tolleranza di partizione
Un database che assegna la priorità alla congruenza e alla tolleranza della partizione utilizza comunemente una configurazione primaria - secondaria, in cui un nodo dei molti nel sistema viene eletto leader. Solo il leader approva le scritture dati, mentre tutti i nodi secondari replicano i dati dal leader per gestire le letture. Se il coordinatore perde la connessione alla rete o non può comunicare con molti dei nodi del sistema, i rimanenti eleggono un nuovo coordinatore. Questo processo di elezione differisce tra i sistemi e potrebbe essere una fonte di problemi significativi.
IBM Cloudant dà la priorità alla disponibilità e alla tolleranza della partizione utilizzando una configurazione primaria - primaria, in modo che ogni nodo possa accettare sia le scritture che le letture nella sua porzione di dati. Più nodi includono copie di ogni parte dei dati. Ogni nodo copia i dati con altri nodi. Se un nodo diventa inaccessibile, gli altri nodi possono servire al suo posto mentre la rete si ricollega. In questo modo, il sistema restituisce i dati in modo tempestivo nonostante un malfunzionamento arbitrario del nodo e conserva la congruenza finale. Il compromesso di trascurare la consistenza assoluta è che ci vuole del tempo affinché tutti i nodi vedano gli stessi dati. Di conseguenza, alcune risposte potrebbero includere vecchi dati mentre i nuovi dati si propagano attraverso il sistema.
Modifica dell'approccio
La gestione di una vista coerente dei dati è logica e facile da capire perché un database relazionale svolge questo compito per te. L'aspettativa è che i servizi basati sul web che interagiscono con i sistemi di database si comportino in questo modo. Ma questa aspettativa non significa che funzionino in questo modo. La coerenza non è un dato di fatto, e ci vuole un po' di lavoro per cambiare l'approccio.
In effetti, la consistenza non è necessariamente indispensabile per molti servizi cloud aziendali. Con i grandi sistemi ampiamente utilizzati esiste un'elevata probabilità che una parte del sistema generi degli errori. Un database progettato intorno alla necessità di privilegiare la disponibilità e la consistenza eventuale è più adatto a mantenere la tua applicazione in linea. La consistenza dei dati applicativi può essere affrontata a posteriori.
Disponibilità dell'applicazione contro la consistenza nell'azienda
Uno sguardo ai popolari servizi basati sul web mostra che le persone si aspettano già l'alta disponibilità e scambiano felicemente questa disponibilità per dati eventualmente coerenti, spesso senza rendersi conto che lo stanno facendo.
Molte applicazioni fuorviano gli utenti in nome della disponibilità. Considerare i bancomat: I dati bancari incoerenti sono il motivo per cui è ancora possibile scontare il denaro senza rendersene conto. Non è realistico presentare una vista coerente del saldo del conto in tutto il sistema bancario se ogni nodo della rete deve arrestarsi e registrare questa cifra prima che le operazioni continuino. Una scelta migliore è quella di rendere il sistema altamente disponibile.
L'industria bancaria lo ha rivelato nel 1980, ma molte organizzazioni IT si preoccupano ancora di sacrificare la consistenza per il bene della disponibilità. Pensa al numero di chiamate di supporto effettuate quando il tuo team di vendita non può accedere all'applicazione CRM. Ora considera se questi si fossero resi conto che servono pochi secondi per propagare un aggiornamento di database nell'applicazione.
La disponibilità prevale sulla consistenza di più di quanto tu possa immaginare. I sistemi di shopping online, le cache HTTP e i DNS sono alcuni esempi. Le organizzazioni devono considerare il costo dei tempi di inattività, come la frustrazione degli utenti, la perdita di produttività e le opportunità perse.
Dalla teoria alla realizzazione
Affrontare l'alta disponibilità è di vitale importanza per le applicazioni cloud. In caso contrario, la coerenza del database globale rimane un grosso collo di bottiglia man mano che si esegue la scalabilità. Le applicazioni ad alta disponibilità devono mantenere un contatto costante con i propri dati, anche se tali dati non sono aggiornati. Questo è il concetto di consistenza eventuale e non c'è niente da temere. A volte, su larga scala, è meglio servire risposte che non sono perfettamente corrette piuttosto che non servirle affatto.
I sistemi di database nascondono la complessità della disponibilità rispetto alla coerenza in modi diversi, ma esistono sempre. IBM Cloudant, CouchDB e altri team di database NoSQL ritengono che la migliore politica richieda agli sviluppatori di affrontare queste complessità all'inizio del processo di progettazione. Facendo il duro lavoro in anticipo, ridurrai le sorprese perché le applicazioni sono pronte a ridimensionarsi dal primo giorno.