Basi di dati distribuite: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
→‎Basi di dati replicate: aggiunto sym/asym
Correzioni con wikEd
Riga 1:
{{Risorsa|tipo=lezione|materia1=Basi di dati 2|avanzamento=100%}}
 
I sistemi a database distribuiti rappresentano una grande sfida per i progettisti di DBMS, in particolare per garantire le proprietà acide e la prevenzione di deadlock.
 
Possiamo classificare i sistemi distribuiti in due classi:
 
* Sistemi omogenei: più macchine che contengono la base di dati ma tutte con lo stesso DBMS. E' il caso dei database all'interno della stessa organizzazione.
* Sistemi eterogenei: più macchine con DBMS diversi. E' il caso (più complicato) di dati che si interfacciano con organizzazioni diverse, che utilizzano a loro volta DBMS differenti.
 
== Paradigma Client-Server ==
 
Il paradigma client-server è uno dei metodi più usati per eseguire operazioni sulle basi di dati. La gestione dei dati è a carico del server che forniscono servizi ai client che li hanno invocati. I client formulano le query e presentano i dati all'applicazione che ne fa richiesta. Normalmente il server è un servizio '''reattivo''' cioè effettua operazioni sulla base di dati solamente quando un client ne fa richiesta.
 
Line 14 ⟶ 17:
 
== Tecniche di distribuzione ==
 
La tecnica di come distribuire la base di dati (cioè come dividere i dati su differenti macchine fisiche o aree geografiche) può essere scelta essenzialmente in due modi: verticale o orizzontale.
 
Sia <math>T</math> un'entità della base di dati e <math>F_i</math> un suo frammento, allora la tecnica di distribuzione della base di dati deve garantire:
 
* '''Completezza''': ogni elemento (dato) di <math>T</math> deve essere presente in almeno un frammento <math>F_i</math>;
* '''Ricostruibilità''': presi tutti i frammenti <math>F_i</math> deve essere sempre possibile ricostruire la tabella iniziale <math>T</math>
 
=== Frammentazione orizzontale ===
 
Nella frammentazione orizzontale ogni frammento consiste in una sequenza di tuple di una relazione, mantenendo l'intero schema della relazione in ogni frammento. Solitamente in questo caso dati non vengono replicati, così è possibile ricostruire la base di dati semplicemente unendo i vari frammenti.
 
==== Esempio ====
 
Si consideri la relazione:
 
Line 40 ⟶ 48:
 
<math>
\text{ControCorrente}_3 = \sigma_{filiale=3} \text{ControCorrente}
</math>
 
Line 57 ⟶ 65:
 
<math>
\text{Transazione}_i = \text{Transazione} \ltimes \text{ControCorrente}_i
</math>
 
Line 63 ⟶ 71:
 
==== Join distribuito ====
 
L'operazione JOIN su basi di dati distribuite è la più onerosa e complessa da gestire. Condizione necessaria affinchè il JOIN distribuito sia possibile è che ogni macchina operi sul proprio set di frammenti. Questa condizione è limitativa, si pensi ad esempio un caso in cui un correntista abbiamo più di un conto corrente, che viene distribuito in frammenti diversi. Inoltre spesso effettuare operazioni tra DBMS diversi complica ulteriormente le cose (vedere sezione sui livelli di trasparenza).
 
=== Frammentazione verticale ===
 
Nella frammentazione verticale le relazioni vengono divise per insiemi di attributi. In questo caso è necessario replicare la chiave primaria in ogni frammento, così da permettere la ricostruzione attraverso una JOIN.
 
== Livelli di trasparenza ==
 
I livelli di trasparenza sono parametri che definiscono quanto il programmatore che scrive query per una base di dati distribuita su differenti DBMS può astrarre il suo codice. Questo è dovuto alle differenti tecniche di approccio alla frammentazione, query, ecc. dei vari DBMS.
 
Possiamo identificare quattro principali livelli di trasparenza:
 
# Trasparenza di '''frammentazione''': il programmatore non conosce (nè gli interessa) come e quando la base di dati è frammentata e distribuita;
# Trasparenza di '''allocazione''': il programmatore conosce la struttura dei frammenti, ma non l'allocazione fisica dei dati;
Line 78 ⟶ 90:
 
== Database distribuiti oggi ==
 
Ad oggi esistono ancora molti '''legacy systems''', operanti su [[w:mainframe|mainframes]] con semplici terminali a interfaccia di testo. Nella buona parte di casi, questi sistemi sono sprovvisti di codici sorgente e documentazione, rendendo complesso passare a una base di dati distribuita. Inoltre spesso questi ''vecchi'' sistemi (alcuni degli anni 70'<ref>[http://www.computerweekly.com/news/2240212567/Big-banks-legacy-IT-systems-could-kill-them Big banks' legacy IT systems could kill them]</ref>) sono ancora utilizzati in grandi applicazioni, come banche, servizi finanziari, compagnie aree, ecc., rendendo il passaggio ancora più difficoltoso.
 
Line 83 ⟶ 96:
 
== Controllo di concorrenza distributo ==
 
Si rende necessario adottare tecniche per garantire il controllo di concorrenza anche in ambito distribuito. Fortunatamente le proprietà CID rimangono valide anche in ambito distribuito:
 
* Consistenza: se ogni sottotransazione preserva l'integrità locale, anche i dati globali saranno coerenti e consistenti;
* Isolamento: se ogni sottotransazione è ''2PL'' o ''TS'' allora la transazione è globalmente serializzabile;
Line 91 ⟶ 106:
 
=== Protocollo di commit 2PC ===
 
I server della rete vengono classificati in:
 
* '''Transaction Manager (TM)''', un solo server che si occupa di coordinare il protocollo. L'estensione dei record di log per questo server comprende:
** ''prepare'': indica quali nodi della rete partecipano al protocollo
Line 101 ⟶ 118:
 
Esempio di comunicazione avvenuta con successo:
 
# ''TM''->''RMs'': ''prepare''
# ''RMs''->''TM'': ''ready''
Line 108 ⟶ 126:
 
==== Reazione ai guasti ====
 
Il protocollo deve essere in grado di rispondere a diversi guasti, tra cui:
 
* '''Perdita di un RM''': protocollo di ripresa a caldo, dipende dall'ultimo stato presente nel log degli RM (se è abort, sarà effettuata un'operazione di UNDO, altrimenti se è commit REDO). Se il log di un RM non contiene informazioni (è nello stato di ready) dovrà chiedere al TM cosa fare;
* '''Perdita del TM''': se il TM non ha ancora inviato le azioni globali, un ''global abort'' viene effettuato. Altrimenti il ''TM'' reinvierà tutti i messaggi globali.
Line 114 ⟶ 134:
 
== Parallelismo ==
 
Dagli anni '90 la forte diffusione di macchine general-purpose, ha portato ad avere sistemi con architettura multiprocessore ma non specifici per basi di dati. Le operazioni sulle base di dati possono essere eseguite in modo parallelo con una buona efficienza e scalabilità.
 
Line 119 ⟶ 140:
 
Per parallellizzare una base di dati, vengono utilizzate principalmente due tecniche:
 
* '''inter-query parallelism''': le query vengono distribuite (in modo atomico) tra le unità elaborative. Questa tecnica è usata quando alla base di dati vengono richieste spesso piccole ma numerose query;
* '''intra-query parallelism''': ogni query è suddivisa in più parti e distribuita tra le unità elaborative. Ovviamente questa tecnica è adatta a query molto lunghe, come quelle per l'analisi dei dati.
 
La memoria (di massa e volatile) può essere gestita in modo condiviso (''shared memory'') oppure a memoria separate (''shared nothing''), con eventualmente l'uso di una [[w:Storage Area Network|SAN]].
 
== Basi di dati replicate ==
 
In molte applicazioni distribuite i dati vengono duplicati in più server o datacenter, per diversi motivi:
 
* efficienza: un server può accedere alla sua copia locale anzichè doverla richiedere a un altro server;
* affidabilità: se la copia principale viene corrotta, un'altra copia può essere usata come backup;
Line 133 ⟶ 157:
 
== Note ==
 
<references />