Introduzione

C’è un ben noto informatica teorema proposto da Eric Brewer che dice di un database con dati distribuiti, si può solo promettere due dei seguenti tre caratteristiche:

• la Coerenza
• Disponibilità
• Partizione di tolleranza

Questo è molto astratto e la terminologia non è esattamente intuitivo quindi, in questo articolo faremo del nostro meglio per rompere questa teoria giù dall’astratto al mondo più reale di conversazione e di esempi. Questo teorema può farti pensare alla tua architettura di database in termini di ciò di cui la tua applicazione ha davvero bisogno e dei sacrifici che potrebbe dover fare per raggiungerli.

Definizione della terminologia CAP

Togliamo di mezzo alcune definizioni di base in modo da poter essere sulla stessa pagina mentre andiamo avanti parlando di questo teorema.

CAP – Coerenza, disponibilità, tolleranza partizione

• Coerenza – Tutti i server di dati hanno gli stessi dati, in modo da poter interrogare qualsiasi server nel sistema e ottenere gli stessi dati esatti.
• Disponibilità-Ogni richiesta ai server di dati ottiene una risposta. Se un server è occupato, viene indirizzato a un altro che è in grado di rispondere.
• Partition Tolerance-La possibilità per il sistema di continuare a lavorare anche se ci sono errori di rete e alcuni dei server non possono comunicare.

L’ipotesi sottostante – P è impossibile

In un sistema di database distribuito i dati sono suddivisi su server diversi e questi server parlano tra loro su una rete in modo che possano mantenere lo stesso set di dati. Il problema è che le reti si rompono e quindi assumiamo che comunicherà sempre, cioè non possiamo avere una rete perfetta. In termini di questa teoria ciò significa che nel mondo reale devi sacrificare la tolleranza alla partizione. Se la rete perfetta inesauribile esistesse, non avremmo problemi a raggiungere la coerenza e la disponibilità, ma questo è il mondo reale costruito su fili fisici che falliscono e quindi assumiamo che fallirà.

Se P è Impossibile, quali sono le nostre scelte?

Dato che abbiamo rinunciato alla tolleranza delle partizioni, il teorema dice che ora dobbiamo scegliere tra Coerenza e disponibilità.

È possibile scegliere di avere Disponibilità in cui l’applicazione può soddisfare tutte le richieste in arrivo ma NON può garantire che i dati siano i più recenti.

Di cosa ha bisogno la tua applicazione?

Se l’applicazione è un sito di social media e non ha bisogno di avere i dati più recenti in ogni momento, allora si consiglia di scegliere la disponibilità. Importa che i tuoi utenti vedano un post dopo un ritardo di 30 secondi? In caso contrario, si potrebbe preferire la disponibilità, perché si dà la priorità che gli utenti possano accedere ai dati anche se non sono i dati più aggiornati.

Se d’altra parte la tua applicazione richiede che ogni lettura nel database sia i dati più recenti assoluti, dovrai sacrificare la Disponibilità e scegliere la coerenza. Alcune richieste dovranno essere errate a causa del fatto che le informazioni non possono essere garantite che sono le più recenti in assoluto.

Le scelte fatte da Relazionale e NoSQL

Database tech come SQL e altri sistemi di database relazionali progettati con ACID priorità Coerenza. D’altra parte la maggior parte dei database NoSQL dà priorità alla disponibilità.

Conclusione

Riteniamo che l’esame di questo teorema in termini di applicazione sia un esercizio eccellente e ti aiuti a valutare le priorità della tua applicazione. Se si dispone di un sistema di dati distribuito, esaminare la propria architettura e capire quale sacrificio si sta facendo.

MongoDB, CockroachDB e Postgres sono tutti ottimi database tech oggi che rendono le nostre architetture di database estremamente robuste, ma come abbiamo discusso non sono perfette. Non abbiamo una rete perfetta e c’è sempre “errore utente”. Se ti stai trasferendo in un ambiente di produzione e vuoi discutere le migliori opzioni per la tua applicazione, non esitare a contattarci a Object Rocket.