Elementi essenziali

Un database distribuito può essere infatti denito come a collection of mul- tiple, logically interrelated databases distributed over a computer network [27], e il software che ne permette la gestione e la rende trasparente rispetto agli utenti viene chiamato distributed database management system (distri- buted DBMS): in questa denizione si pone l'attenzione sul fatto che esso si componga di un insieme di database sicamente distribuiti su diversi dispo- sitivi, i cui dati sono inter-relazionati dal punto di vista logico ed hanno una struttura. É inoltre utile notare come vi sia dierenza tra un database distri- buito e uno decentralizzato, sempre costituito da una collezione di database collocati su diversi dispositivi che però non hanno accesso alla rete: anche se all'apparenza può apparire che i dati provengano da un unico database, non vi è in realtà condivisione di informazioni; per questo da un punto di vista logico un database distribuito fa più riferimento al concetto di un unico database geogracamente distribuito piuttosto che ad un insieme di database indipendenti.

A seconda delle caratteristiche dei DBMS che gestiscono le varie istanze che compongono il database distribuito, eseguite autonomamente, esso può essere considerato:

ˆ omogeneo, se in tutti i nodi viene eseguito lo stesso DBMS; in questa situazione solitamente si utilizza lo stesso schema per tutte le istanze,

zioni reali presentano casi eterogenei, in cui va quindi realizzata un'integra- zione che consenta l'utilizzo trasparente delle risorse messe a disposizione.

Inoltre si può fare una distinzione anche fra database distribuiti sincroni e asincroni: nei primi tutti i dati sparsi per i vari nodi della rete vengono tenuti costantemente aggiornati, mentre negli altri c'è solitamente un ritardo fra modica di un'informazione e la relativa diusione a tutti gli altri nodi. Nei database di tipo sincrono l'utente dovrebbe ottenere la stessa risposta in- terrogando istanze dierenti, in quanto se in rete viene modicata una copia di un dato, in linea di principio essa si dovrebbe riettere immediatamente a tutte le altre, oppure fallire: per questo motivo essi possono risultare lenti e insoddisfacenti dal punto di vista del tempo impiegato per rispondere alle richieste degli utenti, anche se assicurano integrità e minimizzano la com- plessità di dover conoscere dove sono localizzate le istanze più aggiornate di un dato. Per quanto riguarda quelli asincroni invece si tollera una tempo- ranea probabile inconsistenza, per esempio nei momenti che intercorrono tra una modica e la sua propagazione, ma essi presentano di solito un miglior tempo di risposta, dato che le operazioni sono eseguite localmente e solo in un secondo momento sincronizzate, anche se si deve arontare il complesso compito di garantire il giusto livello di consistenza e integrità fra i vari nodi. Distribuzione

I principali metodi con i quali i dati vengono distribuiti all'interno di un database distribuito possono essere sintetizzati in:

ˆ replica, che concerne la distribuzione di copie, parziali o complete, del database in vari nodi del sistema;

ˆ frammentazione, a cui ci si riferisce anche col termine partitioning, che concerne la divisione di dei dati in frammenti che vengono distribui- ti; i due tipi di partitioning solitamente considerati sono orizzontale e verticale.

Mantenere dierenti repliche, o copie, di un database può avere diver- si scopi fra cui l'aumento dell'adabilità o delle performance in termini di tempo di risposta, ma la caratteristica di principale interesse nel contesto di questa tesi è l'aumento della disponibilità: tramite l'utilizzo di repliche infat- ti alcune operazioni possono essere eettuate localmente ad un nodo senza la necessità che la connettività di rete sia garantita, con l'assunzione che quando sarà nuovamente disponibile queste verranno sincronizzate nel siste- ma. Oltre a ridurre il traco di rete, in quanto gli aggiornamenti vengono di solito resi noti in maniera asincroni tramite schedulazione di appositi task, questa peculiarità risulta importante nel contesto di applicazioni mobile, in cui la copertura di rete non è sempre garantita.

Comportando alcuni svantaggi tra cui requisiti in termini di spazio di me- moria sui dispositivi e complessità nella gestione e nel mantenimento della consistenza e dell'integrità dei dati, i meccanismi di replica devono essere usa- ti dopo un'attenta analisi delle caratteristiche del caso considerato: scenari in cui la maggior parte delle richieste sono read-only e i dati sono relativamen- te statici, in cui non vi sia necessità di aggiornare in real time le modiche avvenute su un altro nodo sono quindi indicati per il loro utilizzo.

Per quanto riguarda il partizionamento di un database, si può fare die- renza tra orizzontale e verticale a seconda di come avviene la frammentazione del dato da distribuire: se ad essere distribuite sono intere righe di una rela- zione si parla di partizionamento orizzontale, se invece ad esserlo sono varie colonne si parla di partizionamento verticale, nel quale poi la relazione va in qualche modo ricostruita, ad esempio con l'uso di indici creati ad hoc. Distributed Concurrency Control

Il controllo della concorrenza in un database distribuito concerne la sincroniz- zazione degli accessi ad esso in modo da garantirne proprietà come l'integrità: dal momento che rappresenta uno dei problemi più complessi da arontare in questo contesto, è anche uno dei più studiati.

La maggiore dierenza rispetto al caso di un database centralizzato è che il focus è spostato sulla consistenza del sistema nella sua globalità inteso come l'insieme di copie o frammenti sparsi per i nodi della rete: i due metodi generali per arontare il problema si basano su strategie ottimistiche, che permettono di eseguire le richieste per vericarne poi la validità alla ne, oppure pessimistiche, che le bloccano prima che possano essere eseguite, in linea con la descrizione fornita in 5.1.

In genere entrambi questi meccanismi possono fare riferimento a pri- mitive di locking, per garantire mutua esclusione nell'accesso ai dati o di timestamping, per avere un modo di ordinare le operazioni.

ˆ replica, visto che demandando la gestione della replica al database distribuito l'utente potrebbe non essere consapevole dell'esistenza di repliche, avendo di fatto la sensazione che i dati siano unici.

Un altro importante vantaggio proviene dal fatto che, essendo distribuito fa vari nodi della rete, anche la reliability dell'intero sistema ne risulta au- mentata, andando ad eliminare potenziali single point of failure: nel caso in cui un nodo dovesse essere non raggiungibile per un qualsiasi motivo, il siste- ma continuerebbe a fornire il proprio servizio, al più abbassando il proprio livello di performance.

Inoltre, anche performance come il tempo di risposta possono essere mi- gliorate grazie al concetto di località dei dati, che vengono posizionati più vicini ai punti in cui vengono maggiormente usati e al supporto verso una sca- labilità orizzontale in cui altri nodi possono essere aggiunti al sistema per far fronte ad un numero maggiore di richieste; inne essi supportano anche più agevolmente l'espansione dei sistemi, permettendo l'aggiunta di componenti. A fronte di queste peculiarità vanno considerati anche i possibili svantaggi che si possono riscontrare utilizzando tali database, che comprendono spesso un maggiore costo e complessità del software da utilizzare, in quanto deve fare fronte ad un ambiente distribuito, overhead in termini di computazione e rete utilizzata dovuto alle interazioni per la gestione della distribuzione dei dati e soprattutto grande complessità dei meccanismi per garantire integrità e consistenza all'interno del sistema.