Basi di Dati Distribuite

Transcript

1 Basi di Dati Distribuite P. Atzeni, S. Ceri, S. Paraboschi, R. Torlone (McGraw-Hill Italia) Basi di dati: architetture linee di evoluzione - seconda edizione Capitolo 3 Appunti dalle lezioni SQL come DDL Sistemi informativi e basi di dati La Progettazione Concettuale SQL come DML Il modello relazionale La Progettazione Logica SQL come DCL Utilizzo di un DBMS Reale La Progettazione Fisica Strumenti CASE Forme normali Programmazione Transazioni e tecnologie di supporto Basi di dati direzionali Basi di dati distribuite DB Distribuiti 1

2 DB Distribuiti Un DB distribuito è una collezione di dati: Logicamente appartenenti allo stesso sistema. I dati hanno cioè caratteristiche tali che li legano insieme cosicché un DB distribuito è diverso da un insieme di DB centralizzati. Sono distribuiti su più server collegati in rete. DB Distribuiti 2 Motivazioni Natura intrinsecamente distribuita delle organizzazioni Evoluzione degli elaboratori Aumento della capacità' elaborativa Riduzione di prezzo Evoluzione della tecnologia dei DBMS Standard di interoperabilità Evoluzione delle reti DB Distribuiti 3

3 DB Distribuiti: Classificazione Se su tutti i server è usato lo stesso DBMS si parla di DB omogenei. Se i DBMS sono diversi si parla di DB eterogenei. E anche importante sapere se i vari server sono collegati da una LAN o da una WAN. DB Distribuiti 4 Frammentazione dei dati Posso frammentare lo schema Posso frammentare la tabella Frammentazione orizzontale I frammenti sono insiemi di tuple con lo stesso schema. La relazione originale si ottiene con l unione. Frammentazione verticale I vari frammenti hanno uno schema ottenuto come sottoinsieme dello schema della relazione di partenza. La relazione originale si ottiene con un join. La frammentazione deve essere garantire completezza e ricostruibilità. DB Distribuiti 5

4 Allocazione dei dati Ogni frammento è realizzato tramite una o più tabella in un db allocato su un certo server. Allocazione non ridondante ogni frammento o relazione viene allocato su un solo server. ridondante alcuni frammenti o relazioni sono allocati su più server. DB Distribuiti 6 Livelli di Trasparenza Trasparenza di Frammentazione Interagiamo con il db distribuito come se fosse centralizzato. Non ci dobbiamo preoccupare né della eventuale frammentazione né delle allocazioni. Trasparenza di Allocazione Dobbiamo conoscere come sono frammentati i dati ma dobbiamo indicarne la allocazione. Se il sistema è ad allocazione ridondante non dobbiamo indicare a quale replica ci riferiamo per l accesso (trasparenza di replicazione) DB Distribuiti 7

5 Livelli di Trasparenza Trasparenza di Linguaggio Dobbiamo indicare sia i frammenti sia la loro allocazione ma non dobbiamo preoccuparci dei vari dialetti SQL usati dai vari sistemi. Assenza di trasparenza Il sistema è eterogeneo e i dialetti SQL sono diversi e noi dobbiamo specificare le varie query opportunamente. DB Distribuiti 8 Livelli di Trasparenza: Esempio Fornitore Fornitore1 Fornitore2 server@milano.it (Oracle) server1@roma.it (SQLServer) server2@roma.it (SQLServer) Problema: Selezionare il nome di un fornitore dato il suo numero DB Distribuiti 9

6 Livelli di Trasparenza: Esempio Trasparenza di frammentazione select nome from fornitore where numero = 125 DB Distribuiti 10 Livelli di Trasparenza: Esempio Trasparenza di allocazione select nome from fornitore1 where numero = 125 Se non lo trovo select nome from fornitore2 where numero = 125 DB Distribuiti 11

7 Livelli di Trasparenza: Esempio Trasparenza di linguaggio select nome into from where numero = 125 Se non lo trovo select nome from fornitore2@server1.roma.it where numero = 123 Assenza di trasparenza Bisogna tenere conto dei dialetti SQL nella formulazione delle query DB Distribuiti 12 Transazioni e DB Distribuiti Richieste remote Operazioni di sola lettura indirizzate ad un solo DBMS Transazioni remote Insieme arbitrario di comandi SQL indirizzate ad un solo DBMS Transazioni distribuite (2PC) Indirizzate a più DBMS, ma ogni comando SQL fa riferimento a dati gestiti da un solo DBMS. Richieste distribuite (2PC + Ottimizzazione Distribuita) Transazioni arbitrarie, in cui il singolo comando SQL può fare riferimento anche a dati gestiti da più DBMS DB Distribuiti 13

8 Acidità delle Transazioni Ragioneremo sulle transazioni distribuite Consistenza Limiti tecnologici impongono che i vincoli imposti siano solo locali. Persistenza e Atomicity I meccanismi utilizzati per il caso centralizzato restano validi (con qualche aggiunta per l atomicità) DB Distribuiti 14 Acidità delle Transazioni Isolation e Atomicity Se ogni sistema usa il 2PL stretto la scheduling globale è serializzabile Problema del deadlock distribuito Se ogni sistema usa il metodo dei timestamps, ed essi sono assegnati in maniera globale alle sottotransazioni,lo scheduling globale è serializzabile. DB Distribuiti 15

9 Commit a 2 fasi (2PC) I server vengono denominati: Resource Manager (RM); Transaction Manager (TM). L analogia più calzante è quella di un matrimonio con i promessi sposi (i RMs) ed un celebrante (TM). DB Distribuiti 16 Commit a 2 fasi (2PC) Il celebrante chiede ai partecipanti se vogliono sposarsi (cioè se vogliono concludere positivamente la transazione). Se tutti i partecipanti sono d accordo, il matrimonio si fa. Se almeno uno dei partecipanti non è d accordo il matrimonio si annulla. DB Distribuiti 17

10 Durability Ogni DBMS ha ovviamente la capacità di gestire applicazioni in modo autonomo. Un progetto accurato della distribuzione dovrebbe garantire che la maggior parte possibile delle applicazioni operino localmente. Nel caso di transazioni di stribuite sono possibili diversi malfunzionamenti; Caduta del TM; Caduta di uno di RM; Caduta della Rete. Nuovi record nei log. DB Distribuiti 18 Nuovi record nel log del TM Record di prepare Il TM scrive sul proprio log l identificativo dei processi RM partecipanti. Record global commit / global abort Si riporta la decisione presa relativamente alla transazione in esame. Record di complete Il protocollo è stato portato a termine. DB Distribuiti 19

11 Nuovi record nel log del RM Ai record classici si aggiunge il record di ready Se accetto: Indica l irrevocabile decisione di partecipare al commit globale. Deve essere scritto quando si è in uno stato stabile (risorse bloccate) e rispettando la WAL e la commit precedenza per il proprio log. Una volta scritto questo record, l RM perde ogni autonomia decisionale. Se rifiuto: Poi vediamo DB Distribuiti 20 2PC in assenza di guasti Rapide scritture su log e scambi di messaggi prepare global decision complete TM prepare msg ready ready msg decision msg finestra di incertezza local decision ack msg RM DB Distribuiti 21

12 Cosa accade se. Qualche RM decide l abort della transazione Anziché mandare un messaggio di ready, manda un messaggio di not-ready. Il processo che gestisce l RM termina dopo l abort DB Distribuiti 22 Cosa accade se. Qualche RM non manda la decisione locale Allo scadere del time-out si opta per global abort DB Distribuiti 23

13 Cosa accade se. Un partecipante cade prima il record ready Non ci sono modifiche sostanziali rispetto al caso centralizzato. La transazione va disfatta perché la transazione globale è andata in global abort. DB Distribuiti 24 Cosa accade se. Un partecipante cade dopo il record ready L RM deve conoscere la decisione globale. L RM interroga il TM oppure il TM ri-invia la decisione ad intervalli regolari DB Distribuiti 25

14 Cosa accade se. Cade il TM e l ultimo record è prepare Problema: il messaggio di prepare è arrivato a tutti, a nessuno o a qualcuno? Alla ripresa del TM si può decidere per un global abort e svolgendo la seconda parte del protocollo. E anche possibile cercare di ripetere la prima fase. DB Distribuiti 26 Cosa accade se. Cade il TM e l ultimo record è global decision Quanti RM siano stati avvertiti della decisione? Bisogna ripetere la seconda riavvertendo tutti gli RM. DB Distribuiti 27

15 Osservazione La possibile ripetizione della seconda fase (scadenza del timeout normalmente o recovery del TM o dell RM) fa sì che che l RM possa ricevere il messaggio di global decision più volte. L RM ignora i messaggi successivi ma deve sempre mandare l ack per consentire la chiusura del protocollo. DB Distribuiti 28 Cosa accade se. Si perde il prepare msg o qualche ready msg Situazioni indistinguibili dal punto di vista del TM) Scatta il timeout sulla prima fase e si decide un global abort. DB Distribuiti 29

16 Cosa accade se. Si perde il global decision msg o qualche ack Situazioni indistinguibili dal punto di vista del TM) Scatta il timeout sulla seconda fase e questa viene ripetuta. DB Distribuiti 30 DB replicati COPIA PRIMARIA COPIA SECONDARIA propagazione modifiche L affidabilità L autonomia DB Distribuiti 31

17 DB replicati COPIA 1 COPIA 2 modifiche modifiche DB Distribuiti 32 DB replicati Trasmissione asincrona COPIA 1 COPIA 2 propagazione transazione master transazione di allineamento DB Distribuiti 33

18 DB replicati Transazione asincrona COPIA 1 COPIA 2 transazione master DB Distribuiti 34 DB replicati Allineamento periodico COPIA 1 COPIA 2 INTERO CONTENUTO COPIA 1 DELLA COPIA 1 COPIA 2 DELTA-PLUS DELTA-MINUS DB Distribuiti 35