Basi di dati distribuite

Distribuzione dei dati. Esistono vari paradigmi per la suddivisione dei dati:

• Architettura client-server: separazione tra client e server della base di dati (client che richiedono servizi e server che offrono servizi)
• Basi di dati distribuite: la stessa applicazione utilizza diversi database server . le basi di dati distribuite richiedono di riesaminare
  • come l’utente può specificare le interrogazioni
  • come la tecnologia server può essere estesa ad un contesto distribuito

Nelle basi di dati distribuite gli utenti devono sapere dove i dati sono memorizzati, per ovvi motivi di efficienza. Inoltre è impensabile che ci possa essere una atomicità nelle transazioni distribuite.

Le basi di dati distribuite inoltre rispondono a reali esigenze applicative, infatti le imprese sono strutturalmente distribuite, ed una gestione distribuita dei dati permette di distribuire il controllo e l'elaborazione dei dati.
Offrono una maggiore flessibilità, modularità e resistenza ai guasti. (Nonostante più complesso è un sistema più si guasta un sistema distribuito reagisce ai guasti con un calo di prestazione anziché un totale failure).

In una base di dati distribuita ogni server ha la capacità di gestire le applicazioni in modo indipendente. Una base di dati distribuita dovrebbe minimizzare le interazioni e la necessità di trasmettere dati attraverso la rete. La distribuzione dei dati dovrebbe essere pianificata in modo tale che le applicazioni possano operare in modo indipendente su un singolo server.

• Basi di dati parallele: diversi supporti di memorizzazione e processori utilizzati in parallelo per migliorare le prestazioni . Viene utilizzato per migliorare la gestione delle query (parallelismo fra le interrogazioni) o per migliorare la singola query (parallelismo all'interno di una singola interrogazione)
• Basi di dati replicate: dati che rappresentano logicamente la stessa informazione sono memorizzati fisicamente su diversi server. Vengono utilizzate per massimizzare:
  • disponibilità dei dati;
  • affidabilità dei dati.

Classificazione delle applicazioni distribuite. Le applicazioni distribuite possono essere classificate in base ai DBMS coinvolti:

• basi di dati distribuite omogenee: tutti i server hanno lo stesso DBMS
• basi di dati distribuite eterogenee: i server hanno DBMS diversi

oppure rispetto alla rete:

• possono utilizzare una rete locale LAN (local area network)
• possono utilizzare una rete WAN (wide area network)

Teorema CAP

Il teorema CAP, noto anche come teorema di Brewer, afferma che è impossibile per un sistema informatico distribuito fornire simultaneamente tutte e tre le seguenti garanzie:

• Coerenza (tutti i nodi vedano gli stessi dati nello stesso momento)
• Disponibilità (la garanzia che ogni richiesta riceva una risposta su ciò che è riuscito o fallito)
• Tolleranza di partizione (il sistema continua a funzionare nonostante arbitrarie perdite di messaggi)

Secondo il teorema, un sistema distribuito è in grado di soddisfare al massimo due di queste garanzie allo stesso tempo, ma non tutte e tre.

Confronto con sistemi centralizzati

Vantaggi sistemi distrubuiti:

• Maggior suddivisione del lavoro
• Nessuna dipendenza da un sistema centrale
• Maggior controllo
• Maggior adeguatezza software
• Maggiore scalabilità
• Eliminazione del single point of failure

Svantaggi sistemi distribuiti:

• Minor controllo centralizzato
• Manca una visione completa
• Propagazione delle modifiche dei dati è difficile
• Manuntenzione sistemi diversi
• Modifiche non generali e note per tutti
• Gestioni situazioni diverse

Vantaggi sistemi centralizzati:

• Controllo centralizzato dei dati
• Visione di insieme centrale
• Veloce recupero dei dati

Svantaggi sistemi centralizzati:

• Non funzionano più tutti i sistemi se si guasta il centrale
• Maggiore potenza di calcolo
• Devo prevedere la gestione di tutti i problemi (piccole/grandi realtà)

Frammentazione dei dati

Data una relazione R, la sua frammentazione consiste nel determinare dei frammenti Ri di R applicando a R operazioni algebriche

• frammentazione orizzontale: i frammenti Ri sono gruppi di tuple che hanno lo stesso schema di R (ottenibili come selezione su R) i frammenti orizzontali sono generalmente disgiunti.
• frammentazione verticale: ogni frammento Ri ha come schema un sottoschema dello schema di R (ottenibile come proiezione su R) i frammenti verticali devono includere la chiave primaria.

Una frammentazione è corretta se è:

• completa: ogni dato in R deve essere presente in uno dei frammenti Ri
• ricostruibile: il contenuto di R deve essere ricostruibile a partire da quello dei suoi frammenti la frammentazione è una tecnica di organizzazione dei dati che permette una distribuzione e un’elaborazione efficiente

Ogni frammento Ri corrisponde ad un diverso file fisico ed è allocato su un diverso server quindi la relazione è un’entità virtuale (come una vista) mentre i frammenti sono effettivamente memorizzati lo schema di allocazione descrive il mapping da relazioni o frammenti al server su cui sono memorizzati. Tale mapping può essere:

• non ridondante: quando ogni frammento o relazione è memorizzato su un singolo server
• ridondante: quando almeno un frammento o relazione è memorizzato su più di un server (in questo caso si parla anche di replica)

Trasparenza nei sistemi distribuiti

Nei sistemi distribuiti ci sono tre livelli di trasparenza significativi: trasparenza di frammentazione, di allocazione e di linguaggi. Inoltre un sistema distribuito può non essere trasparente.

Trasparenza di frammentazione. il programmatore non si deve
preoccupare del fatto che la base di dati sia distribuita
o frammenta, infatti il programmatore scrive le interrogazioni come se il db sia centralizzato

SELECT Nome FROM Impiegati WHERE Imp=10;
INSERT INTO Impiegati (Nome) VALUES ('Luigi')
UPDATE Impiegati SET Nome = 'Marco' WHERE Imp = 10;

Trasparenza di allocazione. il programmatore deve conoscere la
struttura dei frammenti, ma non deve indicare la loro
collocazione. In caso di replicazione, il programmatore non deve
indicare quale copia viene acceduta (trasparenza di
replicazione)

SELECT Nome FROM Impiegati1 WHERE Imp=10;
--if(!result)
SELECT Nome FROM Impiegati2 WHERE Imp=10;
--if(!result)
SELECT Nome FROM Impiegati3 WHERE Imp=10;
--...
INSERT INTO Impiegati1 (Nome) VALUES ('Luigi');
UPDATE Impiegati1 SET Nome = 'Marco' WHERE Imp = 10;
--if(!result)
UPDATE Impiegati2 SET Nome = 'Marco' WHERE Imp = 10;
--if(!result)
UPDATE Impiegati3 SET Nome = 'Marco' WHERE Imp = 10;
--...

Trasparenza di linguaggio. il programmatore deve indicare nell’interrogazione sia la struttura dei frammenti che la loro collocazione.

SELECT Nome FROM Impiegati@DB1 WHERE Imp=10;
--if(!result)
SELECT Nome FROM Impiegati@DB2 WHERE Imp=10;
--if(!result)
SELECT Nome FROM Impiegati@DB3 WHERE Imp=10;
--...
INSERT INTO Impiegati (Nome) VALUES ('Luigi');
UPDATE Impiegati@DB1 SET Nome = 'Marco' WHERE Imp = 10;
--if(!result)
UPDATE Impiegati@DB2 SET Nome = 'Marco' WHERE Imp = 10;
--if(!result)
UPDATE Impiegati@DB3 SET Nome = 'Marco' WHERE Imp = 10;
--...

Transazioni nei sistemi distribuiti

Si possono classificare in:

• richieste remote: transazioni read-only costituite da un numero arbitrario di interrogazioni SQL, rivolte ad un singolo DBMS remoto (che può solo essere interrogato)
• transazioni remote: transazioni costituite da un numero arbitrario di comandi SQL (select, insert, delete, update), rivolti ad un singolo DBMS remoto (ogni transazione scrive su un DBMS)
• transazioni distribuite: transazioni costituite da un numero arbitrario di comandi SQL (select, insert, delete, update), rivolti ad un numero arbitrario di DBMS remoti (ogni transazione può scrivere su più DBMS, ma ogni comando si riferisce ad un DBMS)
• richieste distribuite: transazioni costituite da un numero arbitrario di comandi SQL (select, insert, delete, update), in cui ogni comando SQL può essere rivolto ad ogni DBMS remoto

Proprietà ACID e sistemi distribuiti. la distribuzione dei dati non influenza la proprietà di consistenza (Consistency) e persistenza (Durability) delle transazioni

Mentre le altre due proprietà (Isolation e Atomicity) vengono gestite tramite commit a più fasi (2 o 4) e tramite l'utilizzo di lock per la protezione dei blocchi critici

Le query vengono ottimizzate da un ottimizzatore: Esso è necessaria quando un DBMS riceve una richiesta distribuita il DBMS interrogato è responsabile dell’ottimizzazione globale. L'otimizzatore decide come suddividere l’interrogazione in sottointerrogazioni, ciascuna rivolta ad uno specifico DBMS e costruisce un piano di esecuzione distribuito, che consiste nell’esecuzione coordinata di vari programmi in vari DBMS e nello scambio di dati tra di DBMS. Viene utilizzato il metodo di lamport per gestire alcune informazioni sui blocchi critici.