4.1 Coerenza su Brewera
Per cominciare, Eric Brewer non è, e non ha mai affermato di essere, un esperto di database. Appartiene alla comunità dei sistemi distribuiti e il suo famoso discorso, in cui è apparso il "teorema" CAP, è stato tenuto alla conferenza "Principles of Distributed Computing". (A proposito, dieci anni dopo, nel 2010, ha nuovamente tenuto un discorso su invito alla stessa conferenza, e in questo discorso ha fornito, in particolare, una serie di esempi di sistemi distribuiti, il cui sviluppo ha tenuto conto del " teorema" del CAP.) In questo settore ha una propria interpretazione dei termini utilizzati nel campo dei database.
In particolare, il termine "coerenza immediata" significa che dopo che l'utente riceve notifica dal sistema del completamento con successo di un'operazione di aggiornamento dei dati, il risultato di questa operazione diventa immediatamente visibile a tutti gli osservatori.
Coerenza finale significa che se nessuna nuova operazione di aggiornamento dei dati entra nel sistema per un periodo di tempo sufficientemente lungo, allora ci si può aspettare che i risultati di tutte le precedenti operazioni di aggiornamento dei dati si diffondano infine a tutti i nodi del sistema e tutti i dati delle repliche siano coerente (apparentemente, questo dovrebbe essere inteso come "tutte le repliche avranno lo stesso stato".
Con questo senso di coerenza in mente, il "teorema" di Brewer può essere considerato abbastanza comprensibile e ovvio: in qualsiasi sistema distribuito con dati condivisi, solo due proprietà qualsiasi di coerenza, disponibilità e tolleranza di partizione della rete possono essere garantite contemporaneamente. A questo proposito, Brewer contrappone persino l'insieme delle proprietà ACID con il suo insieme proposto di proprietà BASE (Basically Available, Soft-state, Eventual consistent - disponibilità nella maggior parte dei casi; stato instabile; consistenza finale). Ma questa opposizione, a mio avviso, è ingiustificata, poiché nel primo caso si tratta delle caratteristiche logiche delle transazioni e nel secondo delle proprietà fisiche dei sistemi distribuiti.
4.2 Dimostrazione del "teorema"
Molti credono che il "teorema" di Brewer sia stato formalmente dimostrato. In effetti, l'articolo di Seth Gilbert e Nancy Lynch introduce alcune definizioni (quasi) formali in cui il "teorema" diventa realmente un teorema e viene dimostrato. Vediamo però come si determinano quelle tre proprietà di un sistema distribuito, di cui, secondo il "teorema" di Brewer, solo due proprietà possono essere supportate contemporaneamente.
La coerenza è chiamata coerenza atomica o linearizzabile (coerenza atomica o linearizzabile), che è una proprietà del sistema, tutti i singoli oggetti di dati di cui sono atomici (linearizzabili). A sua volta, un oggetto atomico è un oggetto con diverse operazioni, in modo tale che la chiamata dell'operazione e la ricezione dei dati di risposta avvengano come se fossero istantaneamente, ad es. l'oggetto non accetta la chiamata dell'operazione successiva finché l'operazione precedente non è stata completata completamente. L'ordine in cui le operazioni vengono ricevute deve essere tale che se un'operazione di tipo lettura arriva dopo che è stata eseguita un'operazione di tipo scrittura, l'operazione di lettura deve restituire il valore scritto da questa o da un'operazione di scrittura successiva.
Un sistema distribuito è sempre disponibile se si deve rispondere a ogni richiesta ricevuta da un nodo non guasto. La resilienza del sistema alla partizione di rete è modellata come la conservazione della fattibilità del sistema in caso di perdita di un numero arbitrario di messaggi inviati da un nodo all'altro.
Sulla base di queste definizioni, Hilbert e Lynch formulano il seguente teorema (non c'è orologio nel modello di rete asincrono, e i nodi dovrebbero prendere decisioni solo sulla base dei messaggi ricevuti e dei calcoli locali):
In un modello di rete asincrono, non è possibile implementare un oggetto dati di lettura/scrittura che garantisca disponibilità e proprietà di consistenza atomica per tutte le esecuzioni valide (incluse quelle che perdono messaggi).
Questo teorema è in realtà molto semplicemente dimostrato formalmente con il metodo "per assurdo". L'articolo prosegue concludendo che:
In un modello di rete asincrono, non è possibile implementare un oggetto dati di lettura/scrittura che garantisca proprietà di accessibilità per tutte le esecuzioni valide e consistenza atomica per esecuzioni valide in cui i messaggi non vengono persi.
Inoltre, la verità del teorema principale è dimostrata per un modello di rete parzialmente sincrono, in cui ogni nodo ha un orologio, il cui tempo mostrato aumenta alla stessa velocità, ma che non sono sincronizzati, ad es. può mostrare tempi diversi nello stesso momento reale. Si dimostra che per questo caso una conseguenza simile non è derivata, e, quindi, per reti parzialmente sincrone ci sono più possibilità di organizzare sistemi distribuiti con proprietà "buone".
Sì, in un certo senso (non necessariamente lo stesso previsto da Brewer) si può ritenere che Gilbert e Lynch abbiano dimostrato che è impossibile garantire simultaneamente le proprietà di consistenza atomica, disponibilità e tolleranza di partizione di una rete in un singolo sistema distribuito. Ma cosa c'entra questo con le transazioni di database in generale e le transazioni ACID in particolare?
4.3 Transazioni ACID
Ecco cosa scrive in proposito Julian Browne nella sua nota sulla discussione del "teorema" di CAP:
Nella loro dimostrazione, Hilbert e Lynch usano il termine atomicità invece di coerenza, che ha più senso da un punto di vista tecnico perché, in senso stretto, la coerenza nel senso di ACID si riferisce alle proprietà ideali delle transazioni di database e significa che nessun dato verrà diventano persistenti se violano alcune restrizioni prestabilite. Ma se assumiamo che una limitazione prestabilita dei sistemi distribuiti sia il divieto della presenza di più valori diversi per lo stesso elemento di dati, allora, a mio avviso, questo difetto nell'astrazione della coerenza può essere considerato insignificante (inoltre, se Brewer usasse il termine atomicità, allora apparirebbe il teorema AAP, il cui nome sarebbe estremamente scomodo da pronunciare).
Questo è scritto non molto seriamente, ma onestamente. E, infatti, il requisito della coerenza atomica non dovrebbe essere mescolato con i requisiti della coerenza transazionale nel senso di ACID. I vincoli di integrità del database sono logici, se vuoi, requisiti aziendali. Provengono dalla logica del dominio dell'applicazione. Il requisito della consistenza atomica è di tipo molto diverso. Si tratta di un requisito di implementazione che rientra nella categoria tradizionalmente indicata nel settore dei database come coerenza fisica (ad esempio, quando si esegue qualsiasi operazione di modifica dell'indice, tutti i blocchi dell'albero B+ corrispondente devono contenere valori validi ed essere collegati da riferimenti validi ).
Ed ecco cosa scrivono abbastanza seriamente nella loro nota i rappresentanti della comunità di database Daniel Abadi e Alexander Thomson:
... il requisito della disponibilità di sistemi transazionali scalabili sta diventando sempre più critico, e questo viene solitamente soddisfatto attraverso la replica e il reindirizzamento automatico delle richieste in caso di guasto di uno dei nodi. Pertanto, gli sviluppatori di applicazioni si aspettano che le garanzie di coerenza dei sistemi ACID (originariamente costituite dal supporto locale per invarianti definiti dall'utente) saranno estese per garantire una forte coerenza (che tutte le repliche degli stessi dati in un dato momento saranno copie identiche, ad es. questa coerenza di casi è implicita nel senso di CAP/PACELC.
In altre parole, la coerenza di Brewer non ha nulla a che fare con la coerenza nel senso di ACID, ma è nei sistemi incentrati sulla fornitura di un'elevata disponibilità attraverso la replica dei dati che è auspicabile mantenere una forte coerenza della replica. Questa non è una proprietà ACID, ma una caratteristica tecnica (fisica) di DBMS massicciamente paralleli che facilita lo sviluppo dell'applicazione.
Secondo Michael Stonebreaker, la chiave per costruire un DBMS moderno di alta qualità è la giusta scelta di compromessi tecnici. Quando si sceglie una soluzione ingegneristica specifica, è necessario tenere conto di molti fattori: i requisiti degli utenti futuri, la probabilità di varie situazioni di guasto, ecc., E non essere guidati dogmaticamente da alcuna linea guida teorica generale (incluso il "teorema" CAP).
Stonebreaker ritiene che nell'ambito dei sistemi di database paralleli transazionali, abbandonare la coerenza di Brewer a favore del supporto dell'alta disponibilità e della tolleranza delle partizioni di rete sia uno scarso compromesso perché (a) la coerenza della replica è una caratteristica molto utile del sistema; (b) i DBMS transazionali massivamente paralleli non necessitano di cluster con un numero molto elevato di nodi, quindi le situazioni di suddivisione della rete sono improbabili; (c) il sistema può facilmente diventare non disponibile, non a causa di una partizione di rete, ma, ad esempio, a causa della presenza di errori software che si verificano regolarmente.
Pertanto, l'elevata attività dei rappresentanti del campo NoSQL (leggi NoACID), che spesso fanno riferimento al "teorema" di Brewer, non è collegata all'impossibilità teorica di costruire DBMS transazionali massicciamente paralleli che supportino transazioni ACID, ma al fatto che sistemi semplificati che non supportano solo le transazioni ACID, ma anche la coerenza delle repliche, vengono create in modo più semplice e veloce. A causa della loro organizzazione semplicistica, sono in grado di elaborare i dati molto velocemente e per alcune applicazioni questo è più importante di tutte le comodità inerenti alla tecnologia dei database.
Vediamo come la comunità dei database risponde a questa sfida.