Basi di dati distribuite: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m Annullate le modifiche di 217.133.220.20 (discussione), riportata alla versione precedente di 79.49.30.171 |
|||
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. È il caso dei database all'interno della stessa organizzazione.
* Sistemi eterogenei: più macchine con DBMS diversi. È 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.
Si noti che il paradigma client-server non implica che il server e il client siano su macchine diverse connesse via rete, possono anche essere sulla stessa macchina e interagire mediante chiamate di sistema.
Ultimamente<ref>2007 - {{cita libro|titolo = Basi di dati - Architetture e linee di evoluzione|capitolo = 6|pagine = p. 199-201|editore = McGraw-Hill|anno = 2007}}</ref> si è diffusa la architettura '''three-tier''': client-server applicativo-server. Il server applicativo ha la funzione di gestire la logica in comune con tutti i client (che ora vengono chiamati '''thin-client''' per il ridotto numero di funzioni). Un esempio di ''thin-client'' sono i browser web, che utilizzano applicativi web per connettersi ai server web.
== Tecniche di distribuzione ==
Line 120 ⟶ 133:
* '''Problemi di rete''': se un messaggio viene perso o vi è una separazione della rete, si esauriranno i timeout in attesa dei riscontri e dei ''ready'' e un ''global abort'' sarà inviato dal TM. Il sistema è comunque in grado di eseguire transazioni che facciano parte della partizione del TM.
== 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à.
Un parametro importante per la misura del carico di lavoro ''transazionale'' è il '''tps''' (transactions per seconds), utile in particolare per i sistemi OLTP. Invece per i sistemi OLAP si preferisce valutare il carico di lavoro ''analitico'', il quale però può avere un significato diverso nei vari casi (non esiste un'unità di misura comune a tutti).
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;
* disponibilità: in caso di guasto a una sola parte del sistema, un'altra parte può fornire il servizio senza interruzioni se ha quella sezione di base di dati mancante.
Il problema di '''replicare i dati''' è principalmente il mantenere allineate tutte le copie attraverso la '''propagazione dei dati''', che può avvenire ''simmetricamente'' (ogni nodo può provvedere alla modifica della base di dati e informare gli altri nodi) o ''asimettricamente'' (un master effettua le modifiche e informa gli slave).
== Note ==
| |||