Architetture Distribuite <ul><li>Andrea Cannella
Seminario di Basi di Dati
1 Giugno 2010 </li></ul>
Walter & Sara
Aspettative <ul><li>Cosa vi aspettate da questo seminario?
Perché siete qui?
Cosa faremo? </li><ul><li>Teoria
Esercizi </li></ul></ul>
Sommario <ul><li>Introduzione
Architettura Client-Server
Basi di dati distribuite
Tecnologia delle basi di dati distribuite
Commit a 2 fasi
Parallelismo
Basi di dati replicate
MySQL Cluster </li></ul>
Introduzione <ul><li>OLTP:  On Line Transaction Processing. Sono sistemi dimensionati per gestire centinaia o migliaia di ...
OLAP:  On Line Analytical Transaction Processing. Sono sistemi ottimizzati per analizzare i dati. Presuppongono di poter e...
Introduzione <ul><li>I server supportano funzioni OLAP e OLTP.
Il parallelismo può essere sfruttato sia per funzioni OLAP che OLTP.
Replicazione dei dati : costruisce copie dei dati esportandole nei vari nodi in modo da averne maggiore disponibilità. </l...
Introduzione <ul><li>Obiettivi </li><ul><li>Portabilità: trasportare il programma su sistemi diversi. Dipende dagli standa...
Interoperabilità: capacità di far interagire fra loro sistemi eterogenei. Dipende dagli standard relativi ai protocolli di...
Architettura Client-Server <ul><li>Semplice
Diffusa </li></ul>Basata sul modello Client-Server
Architettura Client-Server Client Client Client LAN DB Coda ingresso Coda uscita Database Server Processo Server
Architetture Client-Server <ul>Perché scegliere questo tipo di architettura? <ul><li>Funzioni di client e server ben ident...
Suddivisione conveniente </li></ul></ul>Architettura three tier: presenta un  server applicativo Il client diventa  thin c...
Basi di dati distribuite <ul><li>Transazioni che coinvolgono più di un server </li><ul><li>Il database è dislocato su più ...
Eterogenea </li></ul></ul>
Basi di dati distribuite Tipo di DBMS Rete LAN Rete WAN Omogeneo Applicazioni gestionali e finanziarie Sistemi di prenotaz...
Basi di dati distribuite <ul><li>Frammentazione dei dati </li><ul><li>Orizzontale </li><ul><li>Ogni tupla Ri mantiene lo s...
Ri risultato di una  selezione  su R </li></ul><li>Verticale </li><ul><li>Lo schema di Ri è un sottoinsieme di R
Ri è il risultato di una  proiezione  su R </li></ul></ul></ul>
Basi di dati distribuite <ul><li>Correttezza della frammentazione: </li><ul><li>Completezza: ogni dato di R deve essere pr...
Ricostruibilità: dobbiamo poter ricostruire R a partire dai vari Ri </li></ul></ul>
Basi di dati distribuite <ul><li>Esercizio </li></ul>Si consideri la tabella: Impiegato (ID, Nome, Cognome, DepN, Salario)...
Basi di dati distribuite <ul><li>Esercizio
Eseguire la frammentazione verticale sulla tabella dell'esercizio precedente
Impiegato1 = π  Id, Nome  (Impiegato)
Impiegato2 = π  Id, Cognome, DepN, Salario  (Impiegato)
La ricostruzione sarà uguale alla Join delle frammentazioni e quindi:
Impiegato = Impiegato1  |><| Impiegato2 </li></ul>
Basi di dati distribuite <ul><li>Frammentazione e allocazione dei dati
Lo  schema di allocazione  contiene il  mapping  dai frammenti ai server </li><ul><li>Ridondante : frammenti o relazioni a...
Non ridondante : ciascun frammento o relazione è allocato esattamente su un server. </li></ul></ul>
Upcoming SlideShare
Loading in …5
×

Seminario Basi di Dati - Architetture Distribuite - Università degli Studi di Catania

1,052 views

Published on

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,052
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Seminario Basi di Dati - Architetture Distribuite - Università degli Studi di Catania

  1. 1. Architetture Distribuite <ul><li>Andrea Cannella
  2. 2. Seminario di Basi di Dati
  3. 3. 1 Giugno 2010 </li></ul>
  4. 4. Walter & Sara
  5. 5. Aspettative <ul><li>Cosa vi aspettate da questo seminario?
  6. 6. Perché siete qui?
  7. 7. Cosa faremo? </li><ul><li>Teoria
  8. 8. Esercizi </li></ul></ul>
  9. 9. Sommario <ul><li>Introduzione
  10. 10. Architettura Client-Server
  11. 11. Basi di dati distribuite
  12. 12. Tecnologia delle basi di dati distribuite
  13. 13. Commit a 2 fasi
  14. 14. Parallelismo
  15. 15. Basi di dati replicate
  16. 16. MySQL Cluster </li></ul>
  17. 17. Introduzione <ul><li>OLTP: On Line Transaction Processing. Sono sistemi dimensionati per gestire centinaia o migliaia di transazioni al secondo provenienti dai client. Gestiscono la modifica in tempo reale.
  18. 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) </li></ul>
  19. 19. Introduzione <ul><li>I server supportano funzioni OLAP e OLTP.
  20. 20. Il parallelismo può essere sfruttato sia per funzioni OLAP che OLTP.
  21. 21. Replicazione dei dati : costruisce copie dei dati esportandole nei vari nodi in modo da averne maggiore disponibilità. </li></ul>
  22. 22. Introduzione <ul><li>Obiettivi </li><ul><li>Portabilità: trasportare il programma su sistemi diversi. Dipende dagli standard relativi ai linguaggi (SQL).
  23. 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) </li></ul></ul>
  24. 24. Architettura Client-Server <ul><li>Semplice
  25. 25. Diffusa </li></ul>Basata sul modello Client-Server
  26. 26. Architettura Client-Server Client Client Client LAN DB Coda ingresso Coda uscita Database Server Processo Server
  27. 27. Architetture Client-Server <ul>Perché scegliere questo tipo di architettura? <ul><li>Funzioni di client e server ben identificate
  28. 28. Suddivisione conveniente </li></ul></ul>Architettura three tier: presenta un server applicativo Il client diventa thin client
  29. 29. Basi di dati distribuite <ul><li>Transazioni che coinvolgono più di un server </li><ul><li>Il database è dislocato su più computer </li></ul><li>Base di dati: </li><ul><li>Omogenea
  30. 30. Eterogenea </li></ul></ul>
  31. 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
  32. 32. Basi di dati distribuite <ul><li>Frammentazione dei dati </li><ul><li>Orizzontale </li><ul><li>Ogni tupla Ri mantiene lo stesso schema di R
  33. 33. Ri risultato di una selezione su R </li></ul><li>Verticale </li><ul><li>Lo schema di Ri è un sottoinsieme di R
  34. 34. Ri è il risultato di una proiezione su R </li></ul></ul></ul>
  35. 35. Basi di dati distribuite <ul><li>Correttezza della frammentazione: </li><ul><li>Completezza: ogni dato di R deve essere presente in qualche suo frammento Ri
  36. 36. Ricostruibilità: dobbiamo poter ricostruire R a partire dai vari Ri </li></ul></ul>
  37. 37. Basi di dati distribuite <ul><li>Esercizio </li></ul>Si consideri la tabella: Impiegato (ID, Nome, Cognome, DepN, Salario) Eseguire la frammentazione orizzontale della tabella. Impiegato1 = σ ID<3 Impiegato Impiegato2 = σ ID ≥ 3 Impiegato La ricostruzione sarà uguale all'unione dei due frammenti, quindi Impiegato = Impiegato1 U Impiegato2
  38. 38. Basi di dati distribuite <ul><li>Esercizio
  39. 39. Eseguire la frammentazione verticale sulla tabella dell'esercizio precedente
  40. 40. Impiegato1 = π Id, Nome (Impiegato)
  41. 41. Impiegato2 = π Id, Cognome, DepN, Salario (Impiegato)
  42. 42. La ricostruzione sarà uguale alla Join delle frammentazioni e quindi:
  43. 43. Impiegato = Impiegato1 |><| Impiegato2 </li></ul>
  44. 44. Basi di dati distribuite <ul><li>Frammentazione e allocazione dei dati
  45. 45. Lo schema di allocazione contiene il mapping dai frammenti ai server </li><ul><li>Ridondante : frammenti o relazioni allocati su più server;
  46. 46. Non ridondante : ciascun frammento o relazione è allocato esattamente su un server. </li></ul></ul>
  47. 47. Basi di dati distribuite <ul><li>Livelli di trasparenza </li><ul><li>Trasparenza di frammentazione : il programmatore non si deve preoccupare del fatto che la base di dati sia distribuita.
  48. 48. Trasparenza di allocazione : il programmatore conosce la struttura dei frammenti ma non deve indicarne l'allocazione.
  49. 49. Trasparenza di linguaggio : il programmatore deve conoscere struttura e allocazione, ma potrà usare un solo linguaggio per interrogare il DB.
  50. 50. Assenza di trasparenza: sistema eterogeneo. </li></ul></ul>
  51. 51. Basi di dati distribuite <ul><li>Classificazione delle transazioni </li><ul><li>Richieste remote : transazioni in sola lettura (solo select ) indirizzate a un solo DBMS remoto
  52. 52. Transazioni remote : transazioni ( select, insert, delete, update ) indirizzate a un solo DBMS remoto
  53. 53. Transazioni distribuite : transazioni rivolte a più DBMS dove ogni comando SQL fa riferimento ai dati di un solo DBMS
  54. 54. Richieste distribuite : transazioni arbitrarie dove ogni query può far riferimento a dati su qualunque DBMS </li></ul></ul>
  55. 55. Tecnologia delle basi di dati distribuite <ul><li>La distribuzione dei dati non influisce su due proprietà acide delle transazioni: </li><ul><li>Consistenza : non dipende dalla distribuzione in quanto i vincoli descrivono soltanto proprietà locali a un DBMS
  56. 56. Persistenza : ciascun sistema garantisce la persistenza anche in presenza di guasti tramite backup locali </li></ul></ul>
  57. 57. Tecnologia delle basi di dati distribuite <ul><li>Ottimizzazione delle interrogazioni </li><ul><li>Avviene solo se l'utente sottomette a un DBMS una richiesta distributia.
  58. 58. Il DBMS è responsabile dell'ottimizzazione globale
  59. 59. Le operazioni avvengono in un ordine stabilito
  60. 60. Il costo viene calcolato come: </li><ul><li>C tot =C I/O × n I/O +C cpu × n cpu +C tr × n tr </li></ul></ul></ul>
  61. 61. Tecnologia delle basi di dati distribuite <ul><li>Controllo di concorrenza
  62. 62. In un sistema distribuito una transazione ti può eseguire varie sotto-transazioni tij (j rappresenta il nodo)
  63. 63. Esempio: </li><ul><li>t 1 r 11 (x)w 11 (x)r 12 (y)w 12 (y)
  64. 64. t 2 r 22 (y )w 22 (y )r 21 (x )w 21 (x ) </li></ul><li>La serializzabilità locale presso gli scheduler non è garanzia per la serializzabilità globale. </li></ul>
  65. 65. Tecnologia delle basi di dati distribuite <ul><li>Serializzabilità globale
  66. 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. 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. </li></ul>
  68. 68. Tecnologia delle basi di dati distribuite <ul><li>Metodo di Lamport per assegnare i timestamp </li><ul><li>I timestamp devono riflettere le relazioni di precedenza;
  69. 69. I timestamp sono formati da due gruppi di cifre. Il meno significativo rappresenta il nodo, il più significativo l'evento;
  70. 70. I timestamp si sincronizzano quando i nodi si scambiano messaggi. L'evento ricezione deve avere un timestamp successivo a quello di invio. </li></ul></ul>
  71. 71. Tecnologia delle basi di dati distribuite <ul><li>Rilevazione distribuita dei deadlock </li><ul><li>Più complessa perchè: </li><ul><li>Attesa circolare su più nodi </li></ul></ul><li>Algoritmo </li><ul><li>Una transazione fa riferimento a sotto-transazioni
  72. 72. Due sotto-transazioni della stessa transazione si attendono
  73. 73. Due sotto-transazioni di transazioni differenti si bloccano a vicenda </li></ul></ul>
  74. 74. Tecnologia delle basi di dati distribuite <ul><li>Atomicità di transazioni distribuite
  75. 75. L'atomicità delle transazioni è garantita se tutti i nodi che partecipano a una transazione giungono alla medesima decisione sulla transazione (commit o abort).
  76. 76. Cause di guasto molteplici: </li><ul><li>Caduta di un nodo
  77. 77. Perdita di un messaggio
  78. 78. Partizionamento della rete </li></ul><li>Uso dei messaggi di ack (acknowledgement) </li></ul>
  79. 79. Commit a 2 fasi <ul><li>Il protocollo di commit a 2 fasi ricorda il matrimonio: </li><ul><li>Decisione di 2 persone (server – Resource Manager - RM)
  80. 80. Ratificata da un'altra persona (Transaction Manager - TM) </li></ul><li>Il protocollo svolge un rapido scambio di messaggi tra TM e RM.
  81. 81. Il protocollo è resistente ai guasti perché RM e TM scrivono nuovi record nei loro log </li></ul>
  82. 82. Walter & Sara
  83. 83. Commit a 2 fasi <ul><li>Nuovi record nel log
  84. 84. TM </li><ul><li>Prepare contiene l'identità dei processi RM (le partecipazioni)
  85. 85. Global commit o global abort che determinano l'esito della transazione
  86. 86. Complete scritto alla conclusione </li></ul><li>RM </li><ul><li>Begin, insert, delete, update
  87. 87. Ready indica la disponibilità a partecipare al protocollo di commit a 2 fasi </li></ul></ul>
  88. 88. Commit a 2 fasi <ul><li>In assenza di guasti il protocollo consiste in una sequenza di scritture nel file di log e di scambi di messaggi tra RM e TM in modalità broadcast o seriale </li><ul><li>Il TM scrive il record di prepare nel proprio log e invia il messaggio di prepare agli RM. Imposta quindi un timeout che scatterà in caso di ritardo da parte degli RM
  89. 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. 90. Il TM colleziona le risposte degli RM. Se erano tutti ready scrive global committ, altrimenti global abort </li></ul></ul>
  91. 91. Commit a 2 fasi <ul><li>Seconda fase del protocollo </li><ul><li>Il TM trasmette la sua decisione global agli RM. Imposta quindi un timeout.
  92. 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.
  93. 93. Il TM colleziona tutti i messaggi di ack. Se arrivano tutti scrive complete, altrimenti scatta il timeout che ne imposta un altro fin quando non rispondono tutti gli RM </li></ul><li>Nella seconda fase tutti gli RM devono quindi rispondere </li></ul>
  94. 94. Commit a 2 fasi <ul><li>Protocolli di ripristino
  95. 95. Gli errori che possono causare la caduta del protocollo sono: </li><ul><li>Caduta di un partecipante
  96. 96. Caduta del coordinatore
  97. 97. Perdita di messaggi e partizionamenti della rete </li></ul></ul>
  98. 98. Commit a 2 fasi <ul><li>Caduta di un partecipante </li><ul><li>Comporta la perdita del contenuto del buffer. </li></ul><li>Protocollo di ripresa a caldo </li><ul><li>Se l'ultimo record scritto nel log descrive un azione o un abort, le azioni vanno disfatte
  99. 99. Se l'ultimo record scritto nel log è un commit, le azioni vanno rifatte
  100. 100. Caso dubbio: ready </li><ul><li>Richiesta esplicita dell'RM al TM (remote recovery)
  101. 101. Ripetizione seconda fase protocollo
  102. 102. Richiesta esplicita di effettuare la recovery (X-Open) </li></ul></ul></ul>
  103. 103. Commit a 2 fasi <ul><li>Caduta del coordinatore
  104. 104. Avviene durante la trasmissione di messaggi e comporta la loro eventuale perdita. Lo stato del TM può essere: </li><ul><li>Se l'ultimo record nel log è un prepare gli RM potrebbero essere in blocco, quindi: </li><ul><li>Il TM decide un global abort e poi svolge la seconda fase del protocollo
  105. 105. Il TM ripete anche la prima fase (sperando che gli RM siano in ready) e poi decidere un global commit </li></ul><li>Se l'ultimo record nel log è un global decision, potrebbe essersi verificato che alcuni RM siano stati avvisati della decisione e altri no, per cui bisogna ripetere la seconda fase del protocollo
  106. 106. Se l'ultimo record è un commit la caduta non ha effetti sulla transazione </li></ul></ul>
  107. 107. Commit a 2 fasi <ul><li>Perdita di messaggi e partizionamento della rete </li><ul><li>Il prepare o il successivo ready non sono distinguibili dal TM. In tal caso scatta un timeout nella prima fase e viene presa una decisione di global abort
  108. 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. 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 </li></ul></ul>
  110. 110. Commit a 2 fasi <ul><li>Ottimizzazione
  111. 111. Il commit a 2 fasi è abbbastanza oneroso. Abbiamo inoltre assunto che le scritture nel log fossero sincrone per garantirne la persistenza.
  112. 112. Tuttavia alcune varianti del protocollo permettono di di evitare la scrittura sincrona pur di garantire un meccanismo di scelta per default in caso di caduta del TM </li><ul><li>Protocollo di abort presunto </li></ul></ul>
  113. 113. Commit a 2 fasi <ul><li>Ottimizzazione
  114. 114. Protocollo di abort presunto si basa sulla regola: </li><ul><li>A ogni richiesta di remote recovery da un partecipante in dubbio sulla cui transazione il TM non abbia informazione, viene restituito un </li></ul><li>Vantaggi </li><ul><li>Si può evitare di scrivere con il force i record di prepare e global abort e anche il complete
  115. 115. Bisogna scrivere in modo sincrono solo ready e commit per gli RM e global commit nel TM </li></ul></ul>
  116. 116. Commit a 2 fasi <ul><li>Ottimizzazione
  117. 117. Ottimizzazione ”Sola Lettura” </li><ul><li>Se un partecipante scopre di aver svolto solo operazioni di lettura non deve influenzare l'esito finale della transazione (i partecipanti di cui si conosce a priori la partecipazione sola lettura vanno esclusi)
  118. 118. Al messaggio di prepare ciascun partecipante sola lettura avvisa il TM che lo ignorerà nella seconda fase del protocollo. </li></ul></ul>
  119. 119. Commit a 2 fasi <ul><li>Altri protocolli di commit </li><ul><li>Commit a 4 fasi </li><ul><li>È stato realizzato della Tandem per la gestione di basi di dati replicate al fine di ottenere elevata affidabilità. A tal proposito anche il TM viene replicato da un processo di backup. In ogni fase il TM prima informa il backup e poi gli RM. In questo modo nel caso in cui il TM cada può subentrare il backup, il quale a sua volta per prima cosa attiverà un proprio backup. </li></ul></ul></ul>
  120. 120. Commit a 2 fasi <ul><li>Altri protocolli di commit </li><ul><li>Commit a 3 fasi </li><ul><li>L'idea di base prevede l'aggiunta di una terza fase nel protocollo standard
  121. 121. Non è stato implementato in quanto presenta grosse falle che lo rendono impraticabile </li><ul><li>Allunga la fase di incertezza
  122. 122. L'atomicità può essere persa qualora venga partizionata la rete e si scelgano 2 o più partecipanti. </li></ul></ul></ul></ul>
  123. 123. Commit a 2 fasi <ul><li>Interoperabilità: X-Open DTP </li><ul><li>Interazione di sistemi DBMS eterogenei
  124. 124. Standard: </li><ul><li>ODBC (accesso senza commit) proposto da Microsoft nel 1991
  125. 125. X-Open DTP (standard relativo al protocollo di commit) </li><ul><li>Garantisce interoperabilità
  126. 126. Architettura composta da un client, vari RM e un TM
  127. 127. Interfaccia client-TM: TM interface
  128. 128. Interfaccia TM-RM: XA interface </li></ul></ul></ul></ul>
  129. 129. Parallelismo <ul><li>Viene introdotto nelle basi di dati con lo scopo di garantire prestazioni migliori. </li><ul><li>Parallelismo inter-query: quando si eseguono diverse query in parallelo. I DBMS sono tipicamente caratterizzati da query semplici. È utile in sistemi OLTP
  130. 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 </li></ul></ul>
  131. 131. Basi di dati replicate <ul><li>La replicazione è essenzionale per la realizzazione di applicazioni distribuite. Il servizio è garantito dai replicatori che consentono la copia di tabelle o sottoinsiemi di esse in un contesto distribuito. Il replicatore mantiene l'allineamento fra le copie </li></ul>
  132. 132. Un esempio: MySQL Cluster <ul><li>Il cluster può essere: </li><ul><li>Shared disk
  133. 133. Mirrored disk
  134. 134. Shared nothing </li></ul><li>MySQL Cluster è di tipo shared nothing
  135. 135. MySQL Cluster è un DataBase ad alte prestazioni clusterizzato e affidabile. </li></ul>
  136. 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
  137. 137. MySQL Cluster <ul><li>Caratteristiche che lo portano ad essereun sistema affidabile: </li><ul><li>se un data node è soggetto a un fallimento, le transazioni possono essere redirezionate ad un altro data node ;
  138. 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. 139. i nodi di management possono essere spenti e poi riaccesi senza conseguenze sulle attività degli altri nodi. </li></ul></ul>

×