Architetture di dati distribuite

Come detto più volte, nei primi anni 2000 si è assistito ad una crescita impressionante della quantità di dati disponibili in formato digitale. Da un lato le tecnologie della comunicazione hanno reso possibile il trasferimento di dati in maniera sempre più veloce, dall’altro le tecnologie hardware hanno reso possibile lo sviluppo di sensori in grado di acquisire dati in tempo reale descrittivi di svariati fenomeni naturali. Inoltre, i social network e i contenuti generati dagli utenti hanno consentito a chiunque di diventare un produttore di dati.

La necessità di rappresentare e gestire dati in una rete distribuita di sensori o nodi elaborativi era già presente nei sistemi relazionali e, di fatto, i sistemi NoSQL si sono avvalsi di questa esperienza pluridecennale per sviluppare architetture distribuite basate sui nuovi modelli. Esistono tuttavia alcune importanti differenze progettuali che rendono i sistemi NoSQL significativamente diversi da quelli relazionali.

I sistemi relazionali su architetture distribuite sono stati progettati per garantire rigidamente le proprietà cosiddette ACID. Con questo acronimo si fa riferimento ad un insieme di caratteristiche che un sistema software per la gestione dei dati relazionali deve garantire. Le proprietà impongono che un sistema di gestione di basi di dati relazionale nell’eseguire una transazione, cioè un insieme di operazioni di scrittura e lettura su una base di dati relazionale, debba garantire che:

 anche in presenza di guasti, la transazione sia eseguita tutta o per niente (Atomicità, pensate cosa succederebbe se di un bonifico fosse solo eseguito il prelievo e non l’accredito…)

 la transazione deve lasciare il sistema in uno stato consistente con quello di partenza (Consistenza, ad esempio in una operazione di bonifico la somma dei saldi dei due conti coinvolti deve rimanere la stessa)

 la transazione deve essere eseguita come se non ci fosse nessuna altra transazione eseguita in quello stesso momento sulle stesse risorse (Isolamento, se vengono eseguite due prenotazioni sull’ultimo posto libero in un treno, il posto va assegnato all’una o all’altra, senza intrecci tra le transazioni per cui il posto viene assegnato ad entrambe).

 i risultati della transazione devono essere memorizzati permanentemente nel sistema per tutta la vita dell’applicazione (Durabilità, non mi devo preoccupare che dopo aver prenotato un posto su un treno, quel posto venga in futuro assegnato ad altra transazione).

Il rispetto delle proprietà ACID ha reso i sistemi software per la gestione dei dati relazionali molto popolari e di riconosciuta affidabilità, e anche oggi sono estremamente utili in molti contesti. Tuttavia, il rispetto delle proprietà è andato a discapito dell’efficienza, per le tante attività che devono essere eseguite dal sistema software di gestione per garantirle; per fare solo un esempio, per garantire la atomicità in presenza di guasti, occorre ricordare tutta la sequenza di operazioni elementari eseguite, così che sia possibile quando si verifica il guasto annullarle o rieseguirle come un filo di Arianna.

109

Le nuove applicazioni nate con Internet e con il Web non sempre richiedono caratteristiche così stringenti. Si pensi ad un social network dove la garanzia che tutte le persone che seguono un determinato utente devono vedere subito ogni nuovo contenuto pubblicato è sicuramente eccessiva, mentre, come abbiamo visto nel caso di una operazione bancaria, l’atomicità è fondamentale perché il cliente si fidi della banca e tenga i suoi soldi in un conto corrente.

L’enorme volume di utenti e operazioni che ogni giorno si svolgono su Internet ha anche messo in evidenza che le soluzioni fino a quel momento utilizzate per gestire grandi carichi di lavoro non erano più sostenibili. Fino alla fine degli anni 90, l’idea principale per “scalare” nelle capacità di elaborazione, essere cioè in grado di mantenere il sistema efficiente in presenza di carichi sempre maggiori, era quella di usare server sempre più potenti. Tale misura non è sostenibile nell’era di Internet, perché da un lato il numero di utenti è in continua costante crescita e dall’altro le soluzioni non sono funzionali per carichi di lavoro ridotti. Si pensi ad esempio ad un sito di commercio elettronico che ha dei picchi stagionali significativi, mentre nel resto dell’anno ha flussi di accessi decisamente più bassi dei picchi stagionali. Alla scalabilità verticale della fine degli anni 90 si è sostituita l’idea di scalabilità orizzontale, ovvero l’uso di hardware poco costoso che si può dinamicamente aggiungere o rimuovere dal sistema distribuito quando serve.

La necessità di soddisfare un numero sempre maggiore di utenti e le diverse necessità applicative hanno portato a caratterizzare i sistemi NoSQL con proprietà diverse dalle proprietà ACID, rappresentate nell’acronimo BASE (Basic Available, Soft state, Eventual consistency), che afferma: i sistemi software NoSQL soddisfano una consistenza differita, garantendo che dopo qualche tempo, non specificato in maniera precisa, il sistema sarà consistente, mentre è garantito che sarà sempre disponibile.

Quasi contemporaneamente alla introduzione di questo nuovo insieme di caratteristiche, in occasione del Symposium on Principles of Distributed Computing tenuto nell’anno 2.000, Eric Brewer tenne un famoso keynote sulla sua esperienza nella realizzazione di database distribuiti. In quell’intervento Brewer enunciò quello che è comunemente chiamato CAP theorem. Il teorema afferma che in un sistema distribuito si possono garantire soltanto due delle seguenti tre caratteristiche:

 Consistenza dei dati,

 disponibilità dei dati (Availability) e

 tolleranza al partizionamento della rete Internet (cioè creazione di sottoreti non comunicanti tra loro) dovuto ad un guasto (Partition tolerance).

In base a questo teorema, ogni sistema di basi di dati distribuite deve “scegliere” due delle precedenti tre caratteristiche; ad esempio, i sistemi relazionali sono tutti AC, ovvero garantiscono la consistenza e la disponibilità, mentre non garantiscono il funzionamento del sistema nel caso di partizionamenti nella rete di server utilizzati. Definiti i termini generali che caratterizzano le architetture distribuite nei moderni sistemi distribuiti di basi di dati, nel seguito entriamo nel merito delle caratteristiche e funzionalità principali di tali architetture, mostrando successivamente alcuni esempi di soluzioni realizzate per i più popolari sistemi NoSQL distribuiti.

110

È possibile classificare le architetture di distribuzione dei dati in base al livello di condivisione delle risorse hardware che i vari sistemi propongono.

Nella Figura 10 sono schematizzate le tre tipologie di condivisione possibili. La prima modalità denominata shared memory (memoria condivisa) o shared everything prevede che ogni applicazione software o processo di elaborazione (P) condivida con gli altri sia la memoria centrale che i dischi dove sono memorizzati i dati in modo persistente. Questo tipo di distribuzione prevede che i processi debbano essere eseguiti sullo stesso elaboratore per poter condividere l’area di memoria; tale modalità consente la distribuzione del carico di interrogazioni e transazioni che vengono eseguite dai processi. Questi sistemi sono tipici nelle architetture che prevedono una scalabilità verticale: all’aumentare del carico applicativo si attivano sulla stessa macchina altri processi di elaborazione, fintantochè l’infrastruttura hardware garantisce prestazioni adeguate.

Figura 10 – Architetture di distribuzione dei dati

(tratta da https://pages.cs.wisc.edu/~zuyu/summaries/cs764/parallelDB)

La seconda modalità prevede di far condividere fra diversi elaboratori i dischi dove sono memorizzati i dati in maniera persistente. Questa architettura, implementata ad esempio da Oracle nella suite RAC (Real Application Cluster), porta ad una alta complessità nella gestione delle transazioni concorrenti appartenenti a più processi, per evitare la violazione della proprietà di isolamento delle transazioni. Inoltre, è necessaria una infrastruttura di rete ad alte prestazioni fra i dischi e i server di elaborazione, in quanto i tempi di trasmissione sulla rete Internet sono molto più lenti rispetto ai tempi di trasmissione su un canale che collega direttamente la memoria a dischi con la unità di calcolo.

L’ultima tipologia di condivisione denominata shared nothing (cioè, non è condivisa nessuna risorsa) è tipica delle soluzioni a scalabilità orizzontale. In questa architettura ogni server è indipendente dagli altri server e il coordinamento tra le transazioni non è gestito centralmente dal software di gestione, ma è demandato a livello della applicazione. Va notato che per i sistemi NoSQL, dove, come detto, i vincoli transazionali non sono stringenti come nelle soluzioni ACID, questa architettura è molto efficace, in quanto è possibile aumentare il numero di server coinvolti in maniera dinamica all’aumentare del carico applicativo.

111

Di seguito si riportano a titolo di esempio tre architetture dati di sistemi NoSQL largamente diffuse a testimonianza delle diverse soluzioni tecnologiche di gestione dei dati.

MongoDB, o come più comunemente noto, Mongo, è un database documentale orientato alla consistenza e alla gestione del partizionamento della rete; Mongo è uno dei database NoSQL più conosciuti e affermati. Il modello documentale ben si presta a numerosi ambiti applicativi, anche non in presenza di grandi volumi di dati. A partire dalla versione 4.0 di Mongo, rilasciata nell’estate del 2018, è presente anche il supporto alle transazioni ACID.

L’architettura di distribuzione dei dati di Mongo è basata su una architettura shared nothing, gestita con una soluzione cosiddetta master slave, che ora esemplifichiamo. Il dataset consistente in una collezione di documenti può essere distribuito in più frammenti, assegnati ciascuno a una diversa risorsa elaborativa, detta slave. Ogni risorsa slave gestisce il frammento come se fosse una collezione di documenti indipendente dalle altre.

Figura 11 – Architettura dati ed esecuzione delle operazioni in Mongo (tratta da https://docs.mongodb.com/manual/core/sharded-cluster-query-router/)

Nel caso di una interrogazione che coinvolge informazioni su più frammenti, il processo master, denominato MongoS, si occupa di ricevere le interrogazioni, distribuendo le stesse ai vari processi distribuiti, ognuno dei quali esegue l’interrogazione singolarmente, vedi Figura 11. I dataset locali di risposta alla interrogazione sono raccolte da MongoS che provvede a ricomporli e a produrli in output. I frammenti di dati possono inoltre essere duplicati su più nodi; nel caso in cui si voglia interrogare un unico frammento locale, è possibile scegliere se interrogare il master, seguendo la precedente sequenza di azioni, oppure la copia del frammento più vicina nella rete al richiedente, per aumentare le prestazioni a scapito di eventuali problemi di consistenza nei dati (ricordiamo che Mongo supporta le proprietà BASE delle transazioni). L’inserimento e la modifica dei dati (cioè le operazioni di scrittura) effettuate dalle transazioni avvengono unicamente a partire dal processo master.

112

Il sistema HBase è l’evoluzione open source (cioè software libero e gratuito) del sistema wide column sviluppato da Google; entrambi garantiscono la consistenza e il supporto al partizionamento della rete. Anche HBase utilizza una architettura master slave per la distribuzione dei dati.

Figura 12 – Architettura dati di Hbase

(tratta da http://www.larsgeorge.com/2009/10/hbase-architecture-101-storage.html(

Nella Figura 12 è mostrata l’architettura di Hbase. A parte una terminologia diversa, le funzionalità sono molto simili a quelle già presentate per MongoDB. Il client2 (lo slave, nella terminologia precedente) interroga il master, che ha accesso ai dati memorizzati in componenti chiamati HRegionServer attraverso Zookeeper, un componente open source che si occupa di gestire architetture dati distribuite. Ogni HRegionServer è un componente autonomo che contiene tutte le tipiche risorse e funzionalità di un sistema di gestione di basi di dati, cioè memoria centrale, file di log che memorizza tutte le operazioni elementari eseguite nella base di dati per garantire la atomicità, metodi di accesso ai dati su disco etc. In HBase i dati sono memorizzati su un file system distribuito denominato HDFS (Hadoop Distributed File Systems) che verrà illustrato nella prossima sezione.

Figura 13 – Spazio di indirizzamento in Cassandra

2 Assumiamo equivalenti le terminologie “client server” e ”master slave”, anche se realizzate nei prodotti dei fornitori con alcune differenze, che sono marginali negli argomenti svolti nel capitolo.

113

Una soluzione completamente diversa di distribuzione dei dati è proposta da Cassandra, sviluppato da Facebook. Pur essendo un database wide column come Hbase, Cassandra si caratterizza per garantire nella applicazione del CAP theorem la disponibilità e la tolleranza al partizionamento rispetto alla consistenza dei dati. Ciò non deve stupire, in quanto le applicazioni dei social network hanno l’esigenza di garantire un funzionamento continuo (“24x7”) a scapito, come abbiamo già osservato, della consistenza dei dati. L’architettura di distribuzione dei dati prevede di distribuire lo spazio degli indirizzi delle chiavi sulle memorie di n nodi, formando topologicamente un anello.

Nell’esempio in Figura 13, lo spazio di indirizzamento delle chiavi viene gestito attraverso una opportuna funzione h(ash), così chiamata perché fa corrispondere a ogni valore key della chiave un indirizzo h(key) in memoria che viene calcolato efficientemente per mezzo della funzione hash; lo spazio di indirizzamento è diviso su cinque nodi, la chiave “key1” è assegnata al nodo A mentre la chiave “key2” è assegnata al nodo C, ogni volta che un valore viene scritto si procede alla scrittura anche nei nodi successivi, creando in tal modo una replicazione dei valori su più nodi per garantire la disponibilità.