Seminario sulle Architetture Distribuite per le basi di dati. Presentato durante il Corso di DataBase presso l'Università degli Studi di Catania - Corso di Laurea in Informatica (Facoltà di Scienze Matematiche, Fisiche e Naturali) (Copyleft) Andrea Cannella 2010

2. Seminario di Basi di Dati

3. 1 Giugno 2010

4. Walter & Sara

6. Perché siete qui?

8. Esercizi

10. Architettura Client-Server

11. Basi di dati distribuite

12. Tecnologia delle basi di dati distribuite

13. Commit a 2 fasi

14. Parallelismo

15. Basi di dati replicate

16. MySQL Cluster

18. OLAP: On Line Analytical Transaction Processing. Sono sistemi ottimizzati per analizzare i dati. Presuppongono di poter esportare i dati OLTP e importarli nei data warehouse (magazzini di dati)

20. Il parallelismo può essere sfruttato sia per funzioni OLAP che OLTP.

21. Replicazione dei dati : costruisce copie dei dati esportandole nei vari nodi in modo da averne maggiore disponibilità.

23. Interoperabilità: capacità di far interagire fra loro sistemi eterogenei. Dipende dagli standard relativi ai protocolli di accesso ai dati (ODBC e X-Open DTP)

25. Diffusa Basata sul modello Client-Server

26. Architettura Client-Server Client Client Client LAN DB Coda ingresso Coda uscita Database Server Processo Server

28. Suddivisione conveniente Architettura three tier: presenta un server applicativo Il client diventa thin client

30. Eterogenea

31. Basi di dati distribuite Tipo di DBMS Rete LAN Rete WAN Omogeneo Applicazioni gestionali e finanziarie Sistemi di prenotazione e applicazioni finanziarie Eterogeneo Applicazioni gestionali interfunzionali Sistemi di prenotazione integrati, sistemi interbancari

34. Ri è il risultato di una proiezione su R

36. Ricostruibilità: dobbiamo poter ricostruire R a partire dai vari Ri

39. Eseguire la frammentazione verticale sulla tabella dell'esercizio precedente

40. Impiegato1 = π Id, Nome (Impiegato)

41. Impiegato2 = π Id, Cognome, DepN, Salario (Impiegato)

42. La ricostruzione sarà uguale alla Join delle frammentazioni e quindi:

43. Impiegato = Impiegato1 |><| Impiegato2

46. Non ridondante : ciascun frammento o relazione è allocato esattamente su un server.

48. Trasparenza di allocazione : il programmatore conosce la struttura dei frammenti ma non deve indicarne l'allocazione.

49. Trasparenza di linguaggio : il programmatore deve conoscere struttura e allocazione, ma potrà usare un solo linguaggio per interrogare il DB.

50. Assenza di trasparenza: sistema eterogeneo.

52. Transazioni remote : transazioni ( select, insert, delete, update ) indirizzate a un solo DBMS remoto

53. Transazioni distribuite : transazioni rivolte a più DBMS dove ogni comando SQL fa riferimento ai dati di un solo DBMS

54. Richieste distribuite : transazioni arbitrarie dove ogni query può far riferimento a dati su qualunque DBMS

56. Persistenza : ciascun sistema garantisce la persistenza anche in presenza di guasti tramite backup locali

58. Il DBMS è responsabile dell'ottimizzazione globale

59. Le operazioni avvengono in un ordine stabilito

62. In un sistema distribuito una transazione ti può eseguire varie sotto-transazioni tij (j rappresenta il nodo)

66. se ciascuno scheduler della base di dati distribuita usa su ciascun nodo il metodo di locking a due fasi e svolge l’azione di commit in modo atomico in un istante in cui le sotto-transazioni ai vari nodi detengono tutte le risorse, gli schedule risultanti sono globalmente serializzabili rispetto ai conflitti

67. se un insieme di sotto-transazioni distribuite acquisisce un unico timestamp e lo usa nelle sue richieste a tutti gli scheduler che usano il controllo di concorrenza basato su timestamp, gli schedule risultanti sono globalmente seriali in base all’ordinamento indotto dai timestamp.

69. I timestamp sono formati da due gruppi di cifre. Il meno significativo rappresenta il nodo, il più significativo l'evento;

70. I timestamp si sincronizzano quando i nodi si scambiano messaggi. L'evento ricezione deve avere un timestamp successivo a quello di invio.

72. Due sotto-transazioni della stessa transazione si attendono

73. Due sotto-transazioni di transazioni differenti si bloccano a vicenda

75. L'atomicità delle transazioni è garantita se tutti i nodi che partecipano a una transazione giungono alla medesima decisione sulla transazione (commit o abort).

77. Perdita di un messaggio

81. Il protocollo è resistente ai guasti perché RM e TM scrivono nuovi record nei loro log

82. Walter & Sara

85. Global commit o global abort che determinano l'esito della transazione

87. Ready indica la disponibilità a partecipare al protocollo di commit a 2 fasi

89. Gli RM quando arriva il prepare scrivono il record di ready sul proprio log e lo trasmettono al TM. Se l'RM non era pronto a causa di un guasto invia un messaggio di not-ready e termina il protocollo.

90. Il TM colleziona le risposte degli RM. Se erano tutti ready scrive global committ, altrimenti global abort

92. Gli RM che sono in uno stato di ready attendono il messaggio del TM. Quando arriva scrivono commit o abort nel proprio log. Inviano quindi al TM il messaggio di ack.

96. Caduta del coordinatore

97. Perdita di messaggi e partizionamenti della rete

99. Se l'ultimo record scritto nel log è un commit, le azioni vanno rifatte

101. Ripetizione seconda fase protocollo

102. Richiesta esplicita di effettuare la recovery (X-Open)

106. Se l'ultimo record è un commit la caduta non ha effetti sulla transazione

108. La perdita un un messaggio di decisione o di un ack non sono distinguibili per cui scatta un timeout nella seconda fase e viene ripetuta

109. Un partizionamento non provoca problemi in quanto la transazione avrà successo soltanto se TM e RM appartengono alla stessa partizione durante le fasi critiche del protocollo

111. Il commit a 2 fasi è abbbastanza oneroso. Abbiamo inoltre assunto che le scritture nel log fossero sincrone per garantirne la persistenza.

115. Bisogna scrivere in modo sincrono solo ready e commit per gli RM e global commit nel TM

118. Al messaggio di prepare ciascun partecipante sola lettura avvisa il TM che lo ignorerà nella seconda fase del protocollo.

122. L'atomicità può essere persa qualora venga partizionata la rete e si scelgano 2 o più partecipanti.

126. Architettura composta da un client, vari RM e un TM

127. Interfaccia client-TM: TM interface

128. Interfaccia TM-RM: XA interface

130. Parallelismo intra-query: quando si eseguono parti della stessa query in parallelo. I DBMS sono tipicamente caratterizzati da query complesse. È utile in sistemi OLAP

133. Mirrored disk

135. MySQL Cluster è un DataBase ad alte prestazioni clusterizzato e affidabile.

136. MySQL Cluster MySql Cluster è un RDBMS ACID-Compliant , ad alta affidabilità e alte prestazioni, costruito usando l’architettura shared-nothing e una interfaccia SQL standard. Il sistema consta di nodi (processi), distribuiti su macchine diverse, anche dislocate geograficamente, per assicurare la continuità del servizio anche nel caso in cui un nodo o la rete siano compromessi. MySql Cluster usa uno storage engine , che provvede alla memorizzazione dei dati sui nodi, abilitando l’accesso attraverso query SQL standard. Usa il protocollo di commit a 2 fasi

138. i dati all’interno di un data node sono replicati, in modo che il sistema possa tollerare fallimenti di nodo: altri nodi contengono le stesse informazioni;

139. i nodi di management possono essere spenti e poi riaccesi senza conseguenze sulle attività degli altri nodi.