Teorema CAP: disponibilità

Riguardo al mio articolo su MokaByte, ho avuto uno scambio di e-mail con alcuni lettori riguardo il teorema CAP, in particolare sulla disponibilità del sistema. Il primo è stato Enrico Oliosi che mi ha chiesto:

Se desidero mantenere la consistenza di dati su tutti i nodi e voglio che il sistema sia tollerante ai guasti, in che modo posso perdere la disponibilità del sistema? Questa perdita si riferisce all'interno sistema o ad un singolo nodo?

Premettendo che non sono un ricercatore né un progettista di database NoSql (anzi, se a qualcuno di loro capitasse di leggere, lo invito a commentare eventuali inesattezze o madornali errori) provo a rispondere in base a quello che ho letto sull'argomento. La domanda, mi pare possa essere riassunta in:

Cosa significa che il sistema non è disponibile? Cos'è un sistema non disponibile ma tollerante?

Tempo fa ho letto un post molto interessante di Daniel Abadi, che secondo me può essere molto d'aiuto per rispondere. Se, calando il teorema CAP in pratica, per disponibilità si intende la possibilità di trovare una replica dei dati in caso di fallimento, cosa succede dunque ai sistemi AP, CP e CA in caso di network partition? Abadi dice: in realtà sembrerebbe che non ho tre alternative, ma solo due: AP oppure CP/CA, ossia consistenza oppure no, perché se voglio la consistenza:

• o non sono tollerante al partizionamento (il sistema non scambia messaggi, quindi in pratica non funziona)
• oppure non è disponibile (quindi in pratica non funziona).

Abadi vede in questo un'incompletezza del teorema CAP, dice che, per essere utile, un teorema a riguardo dovrebbe considerare anche la latenza del sistema e si dovrebbe suddividere l'analisi in due parti: in caso di funzionamento normale e in caso di partizionamento della rete, perché in effetti queste proprietà si esplicano in un certo istante nel tempo.
Secondo me, il punto è che, al di là di dispute accademiche, i vari sistemi Sql o NoSql, non rinunciano del tutto a una delle tre proprietà, ma di fatto ne rilassano una o più di una per raggiungere determinati scopi e in determinati tempi. Tant'è che Abadi porta ad esempio PNUTS che sembra garantire una sola proprietà. In realtà, rilassa sia C e A in favore di una più bassa latenza. Ecco perché spesso è difficile catalogare un sistema secondo la nomenclatura CAP. Quello che si può fare è dare un'indicazione di massima. Tutto ciò perché CAP stabilisce quello che non può succedere in un istante, non quello che succede in generale. Detto ciò, in cosa si traduce la perdita di disponibilità? In un fallimento dell'intero sistema o del singolo nodo? Se la disponibilità è la possibilità del sistema di supplire al fallimento di un nodo, quindi disponibilità rilassata significa che al fallimento di un nodo il sistema non riesce ad andare avanti come se niente fosse, ma il come dipende da come è stato progettato il sistema.
Provo, ad esempio ad ipotizzare come i tre sistemi potrebbero comportarsi in caso di partizionamento, a causa della rottura di un nodo:

• CA: i dati rimangono consistenti, il nodo rotto è stato sostituito da una replica che ha dati consistenti, ma alcune funzioni sono state disabilitate come la scrittura. Classica situazione RDBMS.
• AP: perdita di consistenza, le due sottoreti continuano a funzionare (essere disponibili) in autonomia, il nodo rotto è stato sostituito da una replica in una delle sottoreti, ma i dati tra le reti divergono oppure i dati tra le reti non divergono ma la replica non ha dati consistenti con il nodo rotto (si sono persi gli ultimi n update). Quando la rete si metterà a posto, la consistenza (forse) si raggiungerà a regime (tipica situazione NoSql).
• CP: le due sottoreti continuano a funzionare autonomamente (P) e ad avere dati tra loro consistenti (C) perché c'è un failover che ri-assembla la rete in un altro modo, ma poiché la disponibilità non è garantita, ci potrebbe essere un transitorio in cui il sistema non è per nulla raggiungibile, oppure che ci saranno diversi operazioni fallite (altra situazione NoSql).

Ma il partizionamento potrebbe essere dato anche da altri fattori, o in altre modalità e il comportamento potrebbe non essere quello, perché magari i nodi non hanno tutti la stessa importanza o le stesse funzioni. Dipende da come è stato architettato il sistema.