OK, immaginiamo di avere un database distribuito. Supponiamo che tu abbia un nodo in Oregon e uno in California. La teoria CAP afferma che si verificheranno problemi durante l'impostazione di questo tipo di database.
Ad esempio, se si eseguono query di dati da un database, devono essere uguali ai dati nell'altro database. Questo assicura che qualunque valore tu abbia in un database è garantito nell'altro ( Coerenza della teoria della PAC). In questo modo è possibile aggiornare i dati in un database e interrogarli da un altro, ottenendo gli stessi risultati.
Quando aggiorniamo i dati nel nodo Oregon, i dati vengono inviati al nodo California in modo che i database siano coerenti. Al fine di mantenere veramente la coerenza, dobbiamo assicurare che entrambi i database ottengano l'aggiornamento prima che uno dei due sia autorizzato a salvare veramente i dati (commit in due fasi utilizzando transazioni distribuite). In altre parole, se il database della California non è in grado di salvare i dati per qualche motivo (ad es. Guasto del disco rigido), il database in Oregon non salverà i dati e fallirà la transazione.
Il problema con le transazioni distribuite come quella sopra si presenta quando vogliamo avere un'alta disponibilità. In questo scenario, il processo di tentativo di sincronizzare entrambi i database è molto lento. (Immagina, dobbiamo inviare i dati dall'Oregon alla California, assicurarci che ci arrivino, assicurarti che entrambi i database abbiano dei blocchi sui dati, ecc.) Ciò causa gravi problemi quando vogliamo un sistema veloce e reattivo anche durante tempi di grande richiesta. (Questa è la disponibilità del teorema della PAC.)
Di solito, ciò che facciamo per assicurare un'elevata disponibilità è l'utilizzo della replica anziché delle transazioni distribuite. Quindi, invece di garantire che la California possa accettare i dati, andiamo avanti e li memorizziamo nel nodo Oregon e quindi li inviamo in California quando ci aggiriamo. Ciò garantisce che possiamo sempre archiviare i dati, indipendentemente dal fatto che la California sia pronta o meno per archiviarli.
Ciò migliora la disponibilità, ma a costo di coerenza. Vedi, se qualcuno aggiorna i dati in Oregon e poi qualcuno (allo stesso tempo) legge i dati in California, non stanno ottenendo i nuovi dati - i database non sono più coerenti. In realtà, non saranno coerenti fino a quando l'Oregon non invierà i dati in California!
Quindi, questo è il compromesso di disponibilità -vs- coerenza.
La tolleranza alla partizione è il terzo aspetto della teoria della PAC. Il partizionamento è, in questo contesto, l'idea che un database (o un altro sistema distribuito) possa spezzarsi in sezioni separate e funzionare ancora correttamente.
La domanda diventa: cosa succede quando entrambi i database funzionano correttamente, ma il collegamento dall'Oregon alla California è interrotto?
Se aggiorniamo il database in Oregon, dobbiamo trasferire i dati in California in un modo o nell'altro (transazione distribuita o replica). Tuttavia, se il collegamento tra i due viene interrotto, il sistema è diventato partizionato e i database non sono più collegati tra loro.
Quando ciò accade, le tue scelte sono di smettere di consentire gli aggiornamenti (per mantenere la coerenza) al costo della Disponibilità o di consentire gli aggiornamenti (per mantenere la Disponibilità) al costo della coerenza.
Come puoi vedere, la tolleranza della partizione crea compromessi diretti tra coerenza e disponibilità.
C'è ovviamente molto più di questo, ma quelli sono un paio di esempi su come questi tre aspetti principali dei sistemi distribuiti lavorano l'uno contro l'altro. La spiegazione di Julian Browne sulla teoria della PAC è un luogo eccellente per saperne di più.