Paolo Missier II Semestre, 2002 Basi di Dati - Complementi Basi di Dati Distribuite

Basi di Dati distribuite - Paolo Missier– 2 Fonti di riferimento  Basi di Dati (Atzeni, Paraboschi, Torlone, )  Tamer-Ozsu, P. Valduriez, Principles of Distributed Database Systems

Basi di Dati distribuite - Paolo Missier– 3 Paradigmi per la distribuzione dati  Architetture Client-server: separazione del server DB dal client  Basi di Dati distribuite: diversi server DBMS utilizzati dalla stessa applicazione  Basi di Dati Parallele: incremento delle prestazione mediante parallelismo sia di storage devices che di processore  Basi di Dati Replicate: replicazione della stessa informazione su diversi servers per motivi di performance  Data warehouses: DBMS dedicati specificamente alla gestione di dati per il supporto alle decisioni

Basi di Dati distribuite - Paolo Missier– 4 OLAP e OLTP  Sistemi OLTP (On-Line Transaction Processing): –Ottimizzano il throughput di transazioni di lettura e scrittura in presenza di concorrenza: transazioni al secondo –Queries senza aggregazioni o con aggregazioni semplici –Es. Prenotazioni online, ricerche per chiave –Operano su schemi logici di struttura arbitraria  Sistemi OLAP (On-Line Transaction Processing): –Ottimizzati per l’analisi dati –Queries con aggregazioni contemporanee su piu’ dimensioni –Es.: totale posti prenotati aggregati per regione e per tipo di cliente, vs totale posti prenotati per periodo e per agenzia –Operano su data warehouses:  schemi logici e strutture dati ottimizzati per l’analisi  Volumi di dati O(2 30 B)

Basi di Dati distribuite - Paolo Missier– 5 Portabilita’ e interoperabilita’  Portabilita’ : capacita’di eseguire le stesse applicazioni DB su ambienti runtime diversi –Compile time –Facilitata dall’aderenza a standards (e.g.: SQL-2, SQL-3)  Interoperabilita’ : capacita’ di eseguire applicazioni che coinvolgono contemporaneamente sistemi diversi ed eterogenei –Run-time –Facilitata dalla standardizzazione dei protocolli di accesso ai dati: –Database Connectivity (ODBC) –X-Open Distributed Transaction Processing (DTP) –Normalmente limitata al livello di accesso  L’eterogeneita’ a livello di schema logico e/o concettuale richiede altri strumenti di standardizzazione!

Basi di Dati distribuite - Paolo Missier– 6 Modello client-server  Prevede due insiemi di processi, distribuiti in generale su piu’ host connessi in rete: –Processi client: richiedono servizi –Processi server: offrono servizi  Il modello client-server prevede la definizione di: –Interfacce di servizio implementate dal server –Protocolli di accesso ai servizi che consentono al client di raggiungere le interfacce –Es. : submit(query) fa parte dell’interfaccia del servizio. E’ poi necessario un protocollo per consentire al client di invocare la richiesta  Il cliente ha un ruolo attivo. Il server e’ esclusivamente reattivo (risponde alle richieste)  Relazione 1:N tra client e server: –Un client esegue poche richieste ad un processo server, e in sequenza –Un server accoglie richieste multiple in concorrenza tra processi client multipli

Basi di Dati distribuite - Paolo Missier– 7 Modello client-server per data management  Il modello client-server e’ comunemente adottato dalle architetture DBMS utilizzando processi server distribuiti su rete:  Le funzioni del server sono ben definite e limitate –Il server e’ dedicato alla gestione efficiente dei dati  Retrieval, update –Il client ottiene i dati ed esegue il processing nel proprio spazio di processo  Notare che l’uso di stored procedures consente l’esecuzione di computazioni sul server –Essenziale per garantire un throughput accettabile sul server  SQL offre un paradigma di programmazione ideale per la definizione dell’interfaccia di servizio –Le queries SQL sono formulate dal client e inviate al server per l’esecuzione –Il server ritorna risultati in un formato standardizzabile (vedi ODBC) –Quindi la standardizzazione sia delle query che dei risultati consente la portabilita’ delle applicazioni nelle due direzioni:  La stessa applicazione client puo’ utilizzare server diversi  Lo stesso server puo’ accettare richieste da client eterogenei

Basi di Dati distribuite - Paolo Missier– 8 Requisiti degli host per client e server  Client host: –Dedicato all’interazione utente –Supporta applicazioni diverse per il processing dell’informazione (e.g. spreadsheet)  Server host: –Main memory: deve contenere il buffer del DBMS e l’area temporanea eg di esecuzione queries –CPU: deve supportare processi server concorrenti  Buffer manager, recovery manager, query processor, ecc. –Disk memory: oltre ai dati applicativi, contiene i log e altre info necessarie per l’operazione del DBMS

Basi di Dati distribuite - Paolo Missier– 9 Multithreading  Modello comune a tutti i server concorrenti, non specifico dei DBMS!  Uno stesso processo e’ internamente suddiviso in threads di controllo –Threads: processi lightweight che condividono le risorse allocate al processo –I threads sono sincronizzati secondo lo stesso modello dei processi concorrenti (attraverso monitors, semafori, sezioni critiche) –Il processo server definisce la strategia di allocazione dei thread alle transazioni utente (e.g. un thread per transazione)  Il lifetime del DBMS concide con il tempo di esecuzione di un pool critico di processi server  Le richieste client in arrivo su una porta predefinita vengono accolte da un listener  un thread del server in attesa su una coda  Il listener (o dispatcher) controlla l’allocazione del pool di threads alle richieste –Server class: il numero di thread (e quindi l’impegno di memoria e processore) variano dinamicamente con il carico, fino ad un limite –Le richieste possono essere sincrone o asincrone…

Basi di Dati distribuite - Paolo Missier– 10 Architetture two-tier e multi-tier  La logica dell’applicazione client comprende normalmente funzionalita’ diverse: –Interazione utente –Interazione con il DBMS –Interazione con altre applicazioni –Computazione sui dati  Architettura Two-tier: il client esegue l’intero set di funzionalita’ del client: thick-client  Nel caso in cui parte della logica client e’ comune a piu’ applicazioni, la parte comune puo’ essere separata:  Architettura Three-tier: client, application server e DBMS server. Ad es.: –Client: Solo interazione utente (thin client). Es. Web browser –Application server: logica comune:  Interazione con il DBMS (l’AS e’ il vero DBMS client)  Interazione con altre applicazioni (nello stesso spazio AS o in altri spazi)  Computazione sui dati  AS ospitato su host di tipo enterprise Esempi: Architetture 3-tier

Basi di Dati distribuite - Paolo Missier– 11 Basi di Dati Distribuite  Distribuzione dei dati su server multipli  Frammentazione: –Porzioni diverse del DB sono allocate a server diversi  Replicazione: –Esistono copie multiple di porzioni del DB, allocate su server diversi  Trasparenza: –In che modo il DDBMS rende accessibili i diversi frammenti di dati? –Un DDBMS offre diversi gradi di trasparenza nell’accesso a dati distribuiti –Gestione di transazioni globali su piu’ server Sono possibili architetture diverse, funzionali a scopi diversi Analizziamo le alternative all’interno di questo “spazio delle architetture DBMS”

Basi di Dati distribuite - Paolo Missier– 12 Deployment di un DDBMS: scenario di esempio AP DP Nodo 1 Roma AP Nodo 3 Padova DP Nodo 2 Milano - Progettisti Roma - Dipartimenti Roma - Progetti Roma -Contratti universita’ -Dipendenti Padova -Progettisti Milano + Roma -Personale vendite -Dati di vendita - Dipartimenti Milano - Progetti Milano

Basi di Dati distribuite - Paolo Missier– 13 Livelli di trasparenza  Trasparenza: separazione della semantica di alto livello (eg queries SQL) da dettagli implementativi di piu’ basso livello –In che misura l’implementazione e’ nascosta al progettista e all’utente? –Livelli di trasparenza specifici del caso distribuito:  Network, fragmentation, replication transparency  Data Independence –Logical Data Independence: indipendenza dell’applicazione da perturbazioni dello schema logico  Un’applicazione che utilizza un frammento dello schema non subisce modifiche quando altri frammenti vengono modificati –Physical Data Independence: indipendenza dell’applicazione da da perturbazioni dello schema fisico  Eccezione: performance Nei DBMS centralizzati si cerca di garantire questi livelli

Basi di Dati distribuite - Paolo Missier– 14 Network (distribution) Transparency  La struttura dell’applicazione non dipende dalla conoscenza dell’infrastruttura di rete  Idealmente, non c’e’ differenza tra un DBMS centralizzato e uno distribuito  Location transparency: un’operazione sui dati e’ indipendente dalla localizzazione sia dei dati che del sistema sul quale l’operazione e’ eseguita  Naming transparency: il sistema e’ in grado di indirizzare associare ogni oggetto definito nel DDB tramite un nome unico a prescindere dalla propria collocazione  Es: –In questo caso, il nome unico dell’oggetto comprende la sua collocazione logica (ma non fisica)

Basi di Dati distribuite - Paolo Missier– 15 Replication Transparency  La replicazione migliora la performance –Consente di supportare applicazioni con requisiti operazionali diversi sugli stessi dati –Aumenta la localita’ dei dati utilizzati da ogni applicazione –Aumenta l’affidabilita’ complessiva  Spazio delle decisioni: –Quali frammenti replicare –Quante copie mantenere –Dove allocare le copie  Trasparenza: l’applicazione puo’ indirizzare copie specifiche o solo il dato logico?  Complicazioni architetturali: –Gestione della transazioni e updates di copie multiple

Basi di Dati distribuite - Paolo Missier– 16 Fragmentation Transparency  Frammenti: relazione  sotto-relazioni  Problema: una query definita su un’intera relazione va ora scomposta in piu’ query, una per ogni sotto-relazione –Global query  fragment queries  La strategia di query processing e’ basata sui frammenti piuttosto che sull’intera relazione

Basi di Dati distribuite - Paolo Missier– 17 Trasparenza: supporto del DBMS  Transparenza di frammentazione: –L’applicazione ignora l’esistenza di frammenti  Transparenza di allocazione: –L’applicazione e’ consapevole dei frammenti, ma ne ignora l’allocazione sui nodi  Transparenza di linguaggio: –L’applicazione deve specificare sia i frammenti che il loro nodo  In assenza di trasparenza: –Ogni DBMS riconosce il proprio ‘dialetto’ SQL –Sistemi eterogenei senza standard di interoperabilita’ in comune

Basi di Dati distribuite - Paolo Missier– 18 Trasparenza - esempio SUPPLIER (SNum,Name,City)  Due frammenti orizzontali: –SUPPLIER1 =  City=‘London’ SUPPLIER –SUPPLIER2 =  City=‘Manchester’ SUPPLIER  Schema di allocazione:

Basi di Dati distribuite - Paolo Missier– 19 Transparenza di frammentazione  L’applicazione ignora l’esistenza di frammenti:  Query: procedure Query1(:snum,:name); select Name into :name from Supplier where SNum = :snum; end procedure

Basi di Dati distribuite - Paolo Missier– 20 Transparenza di allocazione  L’applicazione deve indirizzare i frammenti ma senza specificare la loro allocazione  In caso di replica, l’applicazione non sceglie la replica da utilizzare (replication transparency)  Query: procedure Query2(:snum,:name); select Name into :name from Supplier1 where SNum = :snum; if :empty then select Name into :name from Supplier2 where SNum = :snum; end procedure;

Basi di Dati distribuite - Paolo Missier– 21 Transparenza di linguaggio  L’applicazione deve indirizzare sia i frammenti che la loro allocazione  Queries espresse a livelli piu’ alti di trasparenza vengono tradotte a questo livello dall’ottimizzatore di query distribuite  Query: procedure Query3(:snum,:name); select Name into :name from where SNum = :snum; if :empty then select Name into :name from where SNum = :snum; end procedure;

Basi di Dati distribuite - Paolo Missier– 22 Modelli architetturali per DDBMS  Un DDBMs e’ in generale una federazione di DBMS che collaborano nel fornire servizi di accesso ai dati con livelli di trasparenza definiti –Ci riferiamo ai diversi nodi del DDBMS  E’ possibile distinguere diverse architetture  Dimensioni ortogonali utili per la classificazione: –Distribuzione –Eterogeneita’ –Autonomia: di controllo nella gestione di ogni nodo

Basi di Dati distribuite - Paolo Missier– 23 Autonomia  …Di design: ogni nodo adotta un proprio modello dei dati e sistema di gestione delle transazioni  …Di comunicazione: ogni nodo sceglie la porzione di dati che intende condividere con altri nodi  …Di esecuzione: ogni nodo decide in che modo eseguire le transazioni che gli vengono sottoposte  Distinzioni tipiche su questa dimensione: –Tightly integrated DBMS  Dati logicamente centralizzati  Un unico data manager responsabile delle tansazioni applicative  I data managers non operano in modo autonomo –Semi-autonomous  Ogni data manager e’ autonomo ma partecipa a transazioni globali  Una parte dei dati e’ condivisa  Richiedono modifiche architetturali per poter fare parte della federazione –Totally autonomous  Ogni DBMS lavora in completa autonomia ed e’ inconsapevole dell’esistenza degli altri

Basi di Dati distribuite - Paolo Missier– 24 Eterogeneita’  Modello dei dati  Linguaggio di query  Gestione delle transazioni  Schema concettuale e schema logico  Distinzioni tipiche:  Federated DBMS: semi-autonomous, omogenei/eterogenei  DDBMS: tightly integrated, omogenei  MDBMS: totally autonomous, omogenei/eterogenei

Basi di Dati distribuite - Paolo Missier– 25 MDBS  Eterogeneita’ di schema –Ogni DB presenta uno schema indipendente dagli altri  Eterogeneita’ di accesso –E’ molto piu’ difficile offrire trasparenza di accesso  Assenza di transazioni globali –Un DBMS puo’ non partecipare a transazioni controllate esternamente

Basi di Dati distribuite - Paolo Missier– 26 Schemi  Local Internal Schema (LIS) –Livello fisico dell’organizzazione dati su un nodo  Global Conceptual Schema (GCS) –Livello logico globale su tutti i nodi  Local Conceptual Schema (LCS) –Descrive lo schema logico a livello di singolo nodo  Esternal Schema (ES) –Viste dello schema logico disponibile a diverse classi di applicazioni

Basi di Dati distribuite - Paolo Missier– 27 Architettura di riferimento ES1ES2ESn GCS LCS1LCS2LCSn LIS1LIS2LISn

Basi di Dati distribuite - Paolo Missier– 28 Architettura di dettaglio -- Componenti  User processor: –User interface handler: interprete comandi e formattatore risultati –Semantic data controller: controlli semantici sulla query (constraints check a livello di schema globale), autorizzazioni –Global query optimizer and decomposer  Determina la strategia di esecuzione  Traduce la query globale in sotot-query elementari usando i LCS e GD/D –Distributed execution monitor / transaction manager  Coordina l’esecuzione di transazioni globali con i TM sugli altri nodi  Data processor: –Local query optimizer –Local recovery manager –Run-time support processor: local buffer manager

Basi di Dati distribuite - Paolo Missier– 29 Architettura MDBS  Differenza fondamentale: definizione del GCS –Rappresenta solo una parte dei LCS –Il GCS integra i LCS oppure i LES –Il processo di integrazione procede bottom-up: gli schemi locali sono definiti a priori GES1GES2GESn GCS LCS1LES2 LCSn LIS1LIS2 LISn LES1LES2 LES1LES2

Basi di Dati distribuite - Paolo Missier– 30 Cosa cambia nei DDBMS?  Utente: –Fino a che punto la distribuzione e’ trasparente?  Progettista: –Come e’ possibile specificare queries e transazioni distribuite?  Architettura DBMS: –Quali estensioni richiede rispetto a quanto visto finora per un DBMS isolato?

Basi di Dati distribuite - Paolo Missier– 31 Vantaggi dei DDBMS: classi di utenti, affidabilita’  La partizione dei dati corrisponde spesso ad una partizione naturale delle applicazioni e degli utenti  Utenti locali vs utenti globali –Es. Un’organizzazione con sedi diverse distribuite geograficamente –Vale il principio che i dati risiedano vicono a dove vengono usati piu’ spesso –Ma sono globalmente raggiungibili  I DDBMS offrono maggiore flessibilita’, modularita’ e resistenza ai guasti –Distribuzione dei dati incrementale e progressiva: la configurazione si adatta alle esigenze delle applicazioni –Presenza di elementi di rete: maggiore fragilita’ –Ma: presenza di ridondanza: maggiore resistenza ai guasti dei singoli nodi (“fail soft”)

Basi di Dati distribuite - Paolo Missier– 32 Vantaggi di performance  Distribuendo un DB su nodi diversi, ogni nodo supporta un DB di dimensioni piu’ ridotte –Piu’ semplice da gestire e ottimizzare rispetto alle applicazioni locali –Ogni nodo puo’ essere ottimizzato indipendentemente dagli altri –Traffico totale (transazioni /sec) distribuito sui nodi –Parallelismo tra transazioni locali che fanno parte di una stessa transazione distribuita

Basi di Dati distribuite - Paolo Missier– 33 Indipendenza locale / cooperazione tra server  Ogni server mantiene la capacita’ di supportare applicazioni in modo indipendente –Le interazioni con altri server e applicazioni remote rappresenta un carico supplementare sul sistema  Traffico di rete in questa configurazione: –Queries provenienti dalle applicazioni –Risultati provenienti dal server –  frammenti di dati. Eg.: per eseguire joins tra tabelle su nodi diversi  Ottimizzazione: l’elemento critico e’ la rete  Vogliamo distribuire i dati in modo che: –La maggior parte delle transazioni sia locale, o eviti spostamento di dati tra nodi

Basi di Dati distribuite - Paolo Missier– 34 Funzionalita’ specifiche dei DDBMS  Trasmissione sia di queries che di frammenti di DB tra i nodi  Catalogo DB: deve gestire la mappa globale del DB –Frammentazione –Replicazione  Query processor: il query plan include sub-queries locali. Il query plan dipende dalla locazione dei frammenti coinvolti  Replicazione: –quale replica conviene utilizzare? –Strategie di sincronizzazione delle repliche  Strategie di recovery di singoli nodi, gestione dei guasti ai link tra i nodi

Basi di Dati distribuite - Paolo Missier– 35 Frammentazione e allocazione dei frammenti  Data una relazione R, si definiscono due tipi di frammenti di R:  Frammentazione orizzontale: –Partizione di R in n relazioni (frammenti) {R 1,…R n } tali che: –Schema(Ri)= schema(R) per tutti gli i; –Ogni R i contiene un sottoinsieme dei records di R –Normalmente definito da una selezione, i.e. R i =  Ci (R) –Completa: R 1  R 2  …  R n = R  Frammentazione verticale: –Partizione di R in n relazioni (frammenti) {R 1,…R n } tali che: –Schema(R) = L = (A 1,…A m ), Schema(R i ) = L i = (A i1, …,A ik ) –L 1  L 2  …  L n = L –L 1  L 2 = pk(R) per ogni i  j

Basi di Dati distribuite - Paolo Missier– 36 Esempio di frammentazione  R = EMPLOYEE (Empnum, Name, Deptnum, Salary, Taxes )  Frammentazione orizzontale: –EMPLOYEE1 =  Empnum<=3 EMPLOYEE –EMPLOYEE2 =  Empnum>3 EMPLOYEE  La ricostruzione richiede l’unione: –EMPLOYEE = EMPLOYEE1 U EMPLOYEE2  Frammentazione verticale: –EMPLOYEE1 =  EmpNum,Name EMPLOYEE –EMPLOYEE2 =  EmpNum,DeptName,Salary,Tax EMPLOYEE  La ricostruzione richiede un equi-join sulla chiave in comune (natural join). –EMPLOYEE = EMPLOYEE1 join EMPLOYEE2

Basi di Dati distribuite - Paolo Missier– 37 Tabella non frammentata

Basi di Dati distribuite - Paolo Missier– 38 Tabella frammentata orizzontalmente

Basi di Dati distribuite - Paolo Missier– 39 Tabella frammentata verticalmente

Basi di Dati distribuite - Paolo Missier– 40 Schemi di allocazione dei frammenti  Ogni frammento e’ allocato su un nodo diverso (e su file diversi)  Quindi, la relazione esiste solo in modo virtuale –Non materializzata su un unico nodo  Lo schema di allocazione descrive il mapping: –Frammento  nodo  Mapping non-ridondante: –esiste una sola copia di ogni frammento su un unico nodo  Mapping ridondante: –Almeno un frammento e’ replicato su piu’ di un nodo

Basi di Dati distribuite - Paolo Missier– 41 Query processing  In un contesto di dati centralizzati, le strategie di esecuzione delle queries sono esprimibili tramite estensioni di algebra relazionale  In un DDBMS, l’algebra relazionale non e’ piu’ sufficiente. Una strategia di esecuzione deve comprendere anche: –Il trasferimento di frammenti tra nodi; –La scelta del sito migliore dove processare i dati  Queste nuove variabili rendono ulterioriormente complessa l’ottimizzazione di query distribuite

Basi di Dati distribuite - Paolo Missier– 42 Distributed query processing – esempio - 1 Schema: E(eno, ename, title) G(eno, jno, resp, dur) Query: “trovare nomi dei dipendenti che sono manager di progetti” AR:  ename (E >< eno (  resp=“manager” (G))) Frammentazione orizzontale: E 1 =  eno  ‘E3’ (E)nodo 1 E 2 =  eno > ‘E3’ (E)nodo 2 G 1 =  eno  ‘E3’ (G)nodo 3 G 2 =  eno > ‘E3’ (G)nodo 4 Risultato: nodo 5

Basi di Dati distribuite - Paolo Missier– Allocazione dei frammenti E 1 =  eno  ‘E3’ (E) E 2 =  eno > ‘E3’ (E) G 1 =  eno  ‘E3’ (G) G 2 =  eno > ‘E3’ (G)  ename (E >< eno(  resp=“manager” (G)))

Basi di Dati distribuite - Paolo Missier– Strategia A G’ 1 =  resp=“manager’ (G 1 )G’ 2 =  resp=“manager’ (G 2 ) E’ 1 = E 1 >< eno G’ 1 E’ 2 = E 2 >< eno G’ 2 Result = E’ 1  E’ 2 Sito 1 Sito 2 Sito 3 Sito 4 Sito 5 G’ 1 G’ 2 E’ 1 E’ 2

Basi di Dati distribuite - Paolo Missier– Strategia A – migrazione frammenti E 1 =  eno  ‘E3’ (E) E 2 =  eno > ‘E3’ (E) G 1 =  eno  ‘E3’ (G) G 2 =  eno > ‘E3’ (G)  ename (E >< eno(  resp=“manager” (G))) G’ 1 G’ 2 E’ 1 E’ 2

Basi di Dati distribuite - Paolo Missier– Strategia B Result = (E 1  E 2 ) >< ENO  resp=“manager’ (G 1  G 2 ) Sito 5 G1G1 Sito 1 G2G2 Sito 2 G3G3 Sito 1 G4G4

Basi di Dati distribuite - Paolo Missier– 47 6 – Confronto di costi tra le due strategie  Modelli di costo (semplificato): –Accesso a un record: 1 –Trasferimento di un record: 10 –|E| = 400, |G| = 1000, |  resp=“manager’ (G 1 )| = |  resp=“manager’ (G 2 )| = 10 –Accesso diretto a E via ENO, G via RESP Costo strategia A: 1.Calcolo G’ 1 e G’ 2  Trasferimento G’ 1 e G’ 2  20 x 10 = Calcolo E’ 2 : join (nested-loop)  ( ) x 2 4.Trasferimento E’ 1, E’ 2 : 20 x 10 = 200  Tot.: 460 Costo strategia B: 1.Trasferimento E 1, E 2 sul nodo 5: 400 x 10 2.Trasferimento G 1, G 2 sul nodo 5: 1000 x 10 3.Calcolo G’ (selezione): 1000 (no indice) 4.Join G, E: 20 x 400 = 8000 (no indici)  Tot.: 23000

Basi di Dati distribuite - Paolo Missier– 48 Obiettivi del query processing distribuito  Parametri critici: –Costo totale = somma dei costi delle operazioni + costi di comunicazione –Response time (la computazione puo’ essere parallela)  Elementi di ottimizzazione: –Topologia della rete/banda disponibile:  (costo di comunicazione) / (costo di I/O locale) = ? –Joins o semijoins?  Joins: maggiore volume di dati trasferiti  Semijoins: maggior numero di messaggi tra nodi

Basi di Dati distribuite - Paolo Missier– 49 Fasi del query processor  Query decompsition –Opera sul GCS –Non considera la distribuzione –Produce un query tree – non ottimizzato  Data localization –Considera la distribuzione dei frammenti –Produce una query che opera sui frammenti – non ottimizzata  Global query optimization –Strategia di esecuzione: operatori di A.R. + operatori di comunicazione (send/receive tra nodi) –Obiettivo: trovare l’ordinamento “migliore” delle operazioni definite dalla fragment query –Utilizza le statistiche sui frammenti  Local query optimization –Ogni nodo riceve una fragment query e la ottimizza in modo indipendente

Basi di Dati distribuite - Paolo Missier– 50 Costo totale e response time Consideriamo solo i costi di comunicazione Costo comunicazione = C MSG * #msgs + C TR * #bytes C MSG = costo fisso di spedizione / ricezione messaggio (setup) C TR = costo (fisso rispetto alla topologia!) di trasmissione dati Response time (solo comm) = C MSG * seq_#msgs + C TR * seq_#bytes dove seq_#msgs e’ il massimo numero di messaggi che devono avvenire in modo sequenziale. Cioe’ i costi delle operazioni in parallelo non si sommano

Basi di Dati distribuite - Paolo Missier– 51 Esempio: costi di comunicazione  Costo di trasferimento di x unita’ da 1 a 3 e di y unita’ da 2 a 3: Costo comunicazione = 2 C MSG + C TR * (x + y) Response time = max(C MSG + C TR * x, C MSG + C TR * y), dato che x e y vengono trasferiti in parallelo Minimizzazione response time: piu’ parallelismo  aumento costo totale (maggiore numero di trasmissioni e processing locale) Minimizzazione costo totale: aumento del throughput (con peggioramento del response time in generale) Nodo 1 Nodo 2 Nodo 3 X unita’ Y unita’

Basi di Dati distribuite - Paolo Missier– 52 Strategie di ordinamento dei joins  Problema: dato un join tra n frammenti distribuiti, in quale ordine conviene eseguirlo?  Caso di n=2 frammenti: ovviamente conviene trasferire il frammento piu’ piccolo –Occorre stimare la cardinalita’ dei frammenti  Cosa accade nel caso n>2? –E’ necessario stimare le dimensioni dei risultati intermedi  usando la selettivita’ di ciascn join –Il problema e’ combinatorio R S Se size(R) < size(S) Se size(R) > size(S)

Basi di Dati distribuite - Paolo Missier– 53 Esempio: ordinamenti alternativi dei joins E J G ENOJNO Nodo 1 Nodo 2 Nodo 3 1.E  nodo 22 calcola E’ = E join G E’  nodo 33 calcola R = E’ join J 2.G  nodo 11 calcola E’ = E join G E’  nodo 33 calcola R = E’ join J 3.G  nodo 33 calcola G’ = G join J G’  nodo 11 calcola R = G’ join E 4.J  nodo 22 calcola J’ = J join G J’  nodo 11 calcola R = J’ join E 5.E  nodo 2 J  nodo 22 calcola R = E join J join G Info necessarie per la scelta della strategia: - size(E), size(G), size(J) - size(E joinG), size(G join J) - Inoltre, alcuni trasferimenti possono avvenire in parallelo Assumendo il prodotto delle cadinalita’ come size dei join, si puo’ usare per la strategie l’ordinamento delle relazioni in base alle loro cardinalita’

Basi di Dati distribuite - Paolo Missier– 54 Join e semijoins  Se R, S sono allocate su nodi diversi, R join A S puo’ essere calcolato utilizzando semijoins. Valgono infatti le seguenti equivalenze: R join A S  (R semijoin A S) join A S R join A S  R join A (S semijoin A R) R join A S  (R semijoin A S) join A (S semijoin A R) Ognuna da’ luogo ad una diversa strategia. La scelta tra le strategie richiede la stima dei loro costi L’uso del semijoin e’ conveniente se il costo del suo calcolo e del trasferimento del risultato e’ inferiore al costo del trasferimento dell’intera relazione e del costo del join intero

Basi di Dati distribuite - Paolo Missier– 55 Esempio: uso dei semijoins  Calcoliamo i costi di trasmissione nei due casi: R join A S (R semijoin A S) join A S assumendo size(R) < size(S), R su nodo 1, S su nodo 2 Operazioni necessarie nel caso di semijoin: 1.  A (S)  nodo 1 2.Nodo 1 calcola R’ = R semijoin A S 3.R’  nodo 2 4.Nodo 2 calcola R’ join S Costo del semijoin = C TR * size(  A (S)) + C TR * size(R semijoin A S) Costo join = C TR * size(R) Quindi il semijoin conviene se size(  A (S)) + size(R semijoin A S) < size(R) Cioe’ quando JSF(R,S, R.A=S.A)) = |R join A S| / |R| e’ piccolo

Basi di Dati distribuite - Paolo Missier– 56 Confronto tra joins e semijoins  Semijoin: piu’ operazioni, ma su operandi di dimensioni piu’ piccole EG J1: join 3:join 2:G 1:E 2: semijoin 1: join 1:  ENO 1:E 1:semijoin 3:join 3:J 3:  JNO 3:J Considerazioni: L’uso dei semijoin: conviene se gli attributi di join sono piccoli rispetto alla size dell’intero frammento comporta un doppio accesso ad uno dei due frammenti partecipanti Nota: I join delle relazioni intermedie non sfruttano gli indici sui frammenti base Il semijoin in generale conviene quindi quando il costo di comunicazione e’ dominante

Basi di Dati distribuite - Paolo Missier– 57 Ottimizzazioni basate sulla semantica  Utilizzando le condizioni di frammentazione delle relazioni –Dipendente dal dominio dei dati –Approccio poco flessibile procedure Query4(:snum,:name,:city); case :city of "London": select Name into :name from Supplier1 where SNum = :snum; "Manchester": select Name into :name from Supplier2 where SNum = :snum; end procedure;

Basi di Dati distribuite - Paolo Missier– 58 DDBMS e transazioni - classificazione  Remote requests: transazioni read-only –Numero arbitrario di query SQL –Dirette ad un unico server remoto  Remote transactions: transazioni read-write –Numero arbitrario di operazioni SQL (select, insert, delete, update) –Dirette ad un unico server remoto –Ogni transazione scrive su un unico server  Distributed transactions : –Numero arbitrario di operazioni SQL (select, insert, delete, update) –Dirette ad un numero arbitrario di servers –Ogni operazione e’ diretta ad un unico server –Le transazioni possono modificare piu’ di un DB –Richiede il protocollo di two-phase commit  Distributed requests sono transazioni arbitrarie, nelle quali ogni operazione SQL si puo’ riferire a qualunque server –Richiede un ottimizzatore distribuito

Basi di Dati distribuite - Paolo Missier– 59 Esempio di transazione distribuita ACCOUNT (AccNum,Name,Total): Total <  frammento ACCOUNT1 Total >=  frammento ACCOUNT2 begin transaction update Account1 set Total = Total where AccNum = 3154; update Account2 set Total = Total where AccNum = 14878; commit work; end transaction  Nota: deve comunque valere la proprieta’ di atomicita’ rispetto alle due updates

Basi di Dati distribuite - Paolo Missier– 60 DDBMS e proprieta’ ACID  La distribuzione non ha conseguenze su consistenza e durabilita’ –Consistenza: non dipende dalla distribuzione, perche’ i vincoli descrivono solo proprieta’ logiche dello schema (indipendenti dall’allocazione) –Durability: garantita localmente da ogni sistema  Invece, e’ necessario rivedere alcuni componenti dell’architettura: –Ottimizzatore –Concurrency control (isolamento) –Reliability control, recovery manager (atomicita’)

Basi di Dati distribuite - Paolo Missier– 61 DDBMS e Concurrency Control  In questo caso, una transazione t i si scompone in sotto- transazioni t ij. La transazione t ij viene eseguita sul nodo j: t 1 : r 11 (x) w 11 (x) r 12 (y) w 12 (y) t 2 : r 22 (y) w 22 (y) r 21 (x) w 21 (x)  Ogni sotto-transazione viene schedulata in modo indipendente dai server di ciascun nodo  La schedule globale dipende quindi dalle schedules locali su ogni nodo  La proprieta’ di serializzabilita’ globale estende quella di conflict-serializability gia’ vista: –Il grafo dei conflitti delle transazioni distribuite e’ l’unione dei grafi delle schedules locali –La schedule globale e’ serializzabile sse il grafo e’ aciclico

Basi di Dati distribuite - Paolo Missier– 62 Serializzabilita’ globale - 1  Osservazione: la serializzabilita’ locale di ogni schedule non garantisce la sua serializzabilita’ globale. Esempio: S 1 : r 11 (x) w 11 (x) r 21 (x) w 21 (x) S 2 : r 22 (y) w 22 (y) r 12 (y) w 12 (y)  S 1 e S 2 sono schedules locali, ciascuna e’ seriale  Il grafo dei conflitti ha un ciclo: –Sul nodo 1, t 1 precede t 2 ed e’ in conflitto con t 2 –Sul nodo 2, t 2 precede t 1 ed e’ in conflitto con t 1

Basi di Dati distribuite - Paolo Missier– 63 Serializzabilita’ globale - 2  Enunciamo le proprieta’ che garantiscono l’esistenza di una (unica) schedule seriale globale sui nodi di un DDBMS –Che sia equivalente a tutte le schedules locali S i su ogni nodo  Uso di Two-phase locking e di Two-phase commit da parte dello scheduler di ogni nodo: –Ogni scheduler usa 2PL –Ogni scheduler effettua il commit solo dopo che tutte le sotto- transazioni hanno acquisito le loro risorse  le schedules risultanti sono globalmente conflict-serializable  Questa proprieta’ e’ verificata utilizzando il protocollo 2-phase commit (descritto piu’ avanti)  Uso di timestamps unici: –Per ogni scheduler che usa controllo di concorrenza basato su timestamp: –Se ogni transazione distribuita utilizza timestamps unici per tutte le richieste a tali schedulers, allora –Le schedules risultanti sono globalmente seriali  Secondo l’ordine imposto dai timestamp

Basi di Dati distribuite - Paolo Missier– 64 Estensione di 2PL al caso distribuito  L’algoritmo 2PL si estende facilmente al caso distribuito  Opzione “Centralized 2PL”: –Delega ad un unico nodo il lock management di tutti i locks –Quindi un solo nodo ha un lock manager attivo –Il TM di ogni sito comunica con questo LM piuttosto che con quello locale –Problema: il nodo dell’unico lock manager diventa un bottleneck  Opzione “Primary Copy / Distributed 2PL”: –Diversi nodi hanno lock managers attivi, ognuno gestisce una partizione dei lock complessivi –Il TM comunica le richieste di lock ai LM corrispondenti alle risorse –Evita il bottleneck –Complicazione: e’ necessario determinare il lock manager che gestisce ciascuna risorsa. E’ un problema di directory globale

Basi di Dati distribuite - Paolo Missier– 65 Estensione di concurrency control basato su timestamps  Gli algoritmi basati su timestamps descritti per il caso centralizzato funzionano ancora  Complicazione: e’ necessario sincronizzare i timestamps definiti su ciascun nodo!  Idea: evitare la sincronizzazione totale su un unico “timestamp server” –E’ costosa –Non e’ necessaria

Basi di Dati distribuite - Paolo Missier– 66 Timestamps globali: metodo di Lamport  Problema generale: definire la precedenza tra eventi in un sistema distribuito  Un timestamps e’ composto di due parti: –Il nodo sul quale l’evento avviene (ordinamento dei nodi) –L’ordine temporale dell’evento su quel nodo, ottenuto da un counter locale al nodo, che viene incrementato ad ogni evento  Ad ogni scambio di messaggi tra nodi, i timestamps si sincronizzano: –Il nodo n 1 genera un evento, il nodo n 2 lo riceve –n 2 deve avere un timestamp maggiore di quello dell’evento ricevuto da n 1 –Quindi il counter locale di n 2 deve essere incrementato a quello dell’evento di n1

Basi di Dati distribuite - Paolo Missier– 67 Esempio di assegnazione di timestamps  [vedi testo, fig. 10.6]

Basi di Dati distribuite - Paolo Missier– 68 Deadlock distribuito  Causato da un’attesa circolare tra due o piu’ nodi  Gestito comunemente nei DDBMS tramite time-out  Risoluzione dei deadlock: –Protocollo asincrono e distribuito –Implementato nella versione distribuita di DB2

Basi di Dati distribuite - Paolo Missier– 69 Deadlock distribuito - definizione  Assumiamo che le sotto-transazioni siano attivate in modo sincrono (tramite RPC bloccante): t 11 attiva t 12.  Questo puo’ dare origine a due tipi di attesa: –Due sotto-transazioni della stessa transazione sono in attesa su nodi diversi:  Ognuna attende la terminazione dell’altra  Se t 11 attiva t 12, allora prima di procedere attende la terminazione di t 12 –Due sotto-transazioni diverse sono in attesa sullo stesso nodo perche’ ognuna ha un lock su un dato richiesto dall’altra  Se t 11 ha un lock su un dato richiesto da t 21, t 21 attende la terminazione di t 11

Basi di Dati distribuite - Paolo Missier– 70 Condizioni di attesa  E’ possibile caratterizzare le condizioni di attesa su ciascun nodo tramite condizioni di precedenza:  EXT: esecuzione su un nodo remoto  Su DBMS1: EXT < t 21 < t 11 < EXT  Su DBMS2: EXT < t 12 < t 22 < EXT  La sequenza di attesa generale e’ della forma: EXT < t i < t j < EXT

Basi di Dati distribuite - Paolo Missier– 71 Algoritmo di risoluzione del deadlock distribuito  Attivato periodicamente sui diversi nodi del DDBMS: –Integra le nuove sequenze di attesa con le condizioni di attesa locale descritte dal lock manager –Analizza le condizioni di attesa sul proprio nodo e gestisce i deadlock locali –Comunica le sequenze di attesa ad altre istanze dello stesso algoritmo  E’ possibile che lo stesso deadlock venga riscoperto piu’ volte. Per evitare il problema, l’algoritmo invia le sequenze di attesa: –‘in avanti, verso il nodo che ha ricevuto la RPC –Solamente quando i > j dove i e j sono gli identificatori delle transazioni

Basi di Dati distribuite - Paolo Missier– 72 Gestione dei guasti nei DDBMS  Un sistema distribuito e’ soggetto oltre a guasti locali, anche a perdita di messaggi su rete e partizionamento della rete (isolamento dei nodi)  Guasti nei nodi: possono essere soft o hard – gia’ discussi  Perdita di messaggi: lasciano l’esecuzione di un protocollo in una situazione di indecisione –Ogni messaggio del protocollo e’ seguito da un ack –In caso di perdita del messaggio oppure dell’ack, si genera una situazione di incertezza: non e’ possibile decidere se il messaggio e’ stato ricevuto  Partizionamento della rete –Una transazione distribuita puo’ essere attiva contemporaneamente su piu’ sottoreti temporaneamente isolate

Basi di Dati distribuite - Paolo Missier– 73 Protocollo two-phase commit  I protocolli di commit consentono ad una transazione di giungere ad una decisione di abort/commit su ciascuno dei nodi che partecipano ad una transazione  Idea: la decisione di commit/abort tra due o piu’ partecipanti e’ coordinata e certificata da un ulteriore partecipante –I servers sono chiamati resource managers (RM) –Il coordinatore e’ chiamato transaction manager (TM)  Il protocollo si basa sullo scambio di messaggi tra TM e RM, i quali mantengono ognuno il proprio log. Il TM puo’ utilizzare: –Meccanismi di broadcast –Comunicazione seriale e individuale con ogni RMs a turno

Basi di Dati distribuite - Paolo Missier– 74 2PC versione base – nessun guasto  [ vedi fig – P of DDBMS ]  Nota 1: 2PC e’ bloccante  Nota 2: –e’ possibile definire un protocollo di recovery non bloccante in caso di guasto ad un singolo nodo –E’ stato dimostrato che non e’ invece possibile definire un protocollo di recovery non bloccante in caso di guasto a nodi multipli

Basi di Dati distribuite - Paolo Missier– 75 Nuovi records di log -- TM  Prepare record: contiene l’identita’ di tutti i RM (nodi + processi)  global commit o global abort record: descrive la decisione globale. La decisione del TM diventa esecutiva quando il TM scrive nel proprio log il record global commit o global abort  complete record: scritto alla fine del protocollo

Basi di Dati distribuite - Paolo Missier– 76 Nuovi records di log -- RM  ready record: disponibilita’ irrevocabile del RM a partecipare alla fase di commit –Assume che il RM sia “recoverable”, i.e., mantiene i locks su tutte le risorse che devono essere scritte –Contiene anche l’identificatore del TM –Inoltre, come nel caso centralizzato vengono scritti anche i records begin, insert, delete, e update  Un RM che non partecipa al 2PC puo’ unilateralmente abortire una transazione sul proprio nodo

Basi di Dati distribuite - Paolo Missier– 77 Prima fase di 2PC  TM scrive prepare nel suo log e invia un messaggio prepare a tutti i RM. Setta un timeout per indicare il massimo intervallo di tempo di attesa per le risposte  I RM che sono recoverable scrivono ready nel loro log record e inviano un messaggio ready al TM  I RM che non sono recoverable inviano un messaggio not- ready e terminano il protocollo  I TM raccolgono i messaggi di risposta dai RM: –Se tutti i RMs rispondono positivamente, scrive global commit nel suo log –Se riceve almeno un messaggio not-ready o scatta il timeout, scrive global abort nel suo log

Basi di Dati distribuite - Paolo Missier– 78 Seconda fase di 2PC  Il TM trasmette la decisione globale ai RM e setta un nuovo timeout  I RMs che sono ready ricevono il messaggio, scrivono commit o abort nel loro log, e inviano un ack al TM. Poi eseguono il loro commit o abort locale  Il TM raccoglie tutti i messaggi ack messages dai RMs. Se scatta il time-out, setta un nuovo time-out e ripete la trasmissione a tutti i RMs dai quali non ha ancora ricevuto un ack  Quando tutti gli acks sono arrivati, il TM scrive complete nel suo log

Basi di Dati distribuite - Paolo Missier– 79 Paradigmi di comunicazione tra TM e RMs  Centralizzato: –La comunicazione avviene solo tra TM e ogni RM –Nessuna comunicazione tra RMs  Lineare: –I RMs comunicano tra loro secondo un ordine prestabilito –Il TM e’ il primo nell’ordine –Utile solo per reti senza possibilita’ di broadcast  Distribuito: –Nella prima fase, il TM comunica con I RMs –I RMs inviano le loro decisioni a tutti gli altri partecipanti –Ogni RM decide in base ai voti che “ascolta” dagli altri –Non occorre la seconda fase di 2PC

Basi di Dati distribuite - Paolo Missier– 80 2PC: in caso di guasto…  Un RM nello stato ready perde la sua autonomia e attende la decisione del TM  Un guasto nel TM lascia il RM in uno stato di incertezza. Le risorse allocate alla transazione restano bloccate  L’intervallo tra la scrittura di ready nel log dei RMs la scrittura di commit o abort e’ detta finestra di incertezza –2PC riduce al minimo questo intervallo di tempo, che esiste comunque  In seguito a guasti, TM o RMs utilizzano protocolli di recovery  Il loro stato finale dipende dalla decisione globale del TM

Basi di Dati distribuite - Paolo Missier– 81 Timeout del TM  Timeout nello stato WAIT: –Il TM attende la risposta dei RMs –Puo’ solo decidere global-abort  Timeout nello stato COMMIT o ABORT: –Il TM non puo’ sapere se le procedure di commit/abort sono state completate dai recovery managers di ogni nodo –Il TM continua a inviare lo stesso messaggio global-commit oppure global-abort

Basi di Dati distribuite - Paolo Missier– 82 Timeout dei RMs  Timeout nello stato INITIAL: –Il RM attende il messaggio prepare –Il TM deve essere caduto nello stato INITIAL –Il RM puo’ fare un abort unilaterale  Timeout nello stato READY: –In questo stato, il RM ha votato per il commit; –Attende la decisione del TM –Non e’ in grado di prendere una decisione unilaterale –Resta bloccato in attesa di ulteriori informazioni  Se I RMs sono in grado di comunicare tra loro, e’ possibile sbloccare la situazione in assenza del TM chiedendo agli altri RMs di aiutarlo a prendere una decisione –[omessi dettagli sui casi possibili…]

Basi di Dati distribuite - Paolo Missier– 83 Recovery del TM  Quando l’ultimo record del log e’ prepare, il guasto del TM puo’ avere bloccato alcuni RMs. Ci sono due opzioni di recovery: –Decidere global abort, e procedere con la seconda fase di 2PC –Ripetere la prima fase, cercando di giungere a un commit  Quando l’ultimo record nel log e’ global-commit o global- abort, alcuni RMs potrebbero non essere stati informati, e altri possono essere bloccati  Il TM deve ripetere la seconda fase

Basi di Dati distribuite - Paolo Missier– 84 Recovery dei RM  Utilizza la sequenza di warm restart  Se l’ultimo record nel log e’: –Abort: undo della transazione –Commit: redo –Ready: il RM si blocca perche’ non conosce la decisione del TM  Durante il warm restart, gli ID delle transazioni in dubbio sono inserite nel ready set. Per ognuna di queste transazioni, si deve attendere la decisione del TM (vedi precedente)

Basi di Dati distribuite - Paolo Missier– 85 Perdita di messaggi e partizionamento della rete  Il TM non e’ in grado di distinguere tra perdita di messaggi prepare o ready  In entrambi i casi, la decisione globale e’ abort in seguito a timeout nella prima fase  Anche la perdita di messaggi ack o di decisioni da parte dei RMs non sono distinguibili  In entrambi i casi, la seconda fase viene ripetuta in seguito a timeout nella seconda fase  Un partizionamento della rete non causa problemi ulteriori, dato che una transazione puo’ avere successo solo se il TM e tutti i RM appartengono alla stessa partizione

Basi di Dati distribuite - Paolo Missier– 86 Ottimizzazione: read-only  Quando un RM sa che la propria transazione non contiene operazioni di scrittura: –Risponde read-only al messaggio di prepare e termina l’esecuzione del protocollo  Il TM ignora i partecipanti read-only nella seconda fase

Basi di Dati distribuite - Paolo Missier– 87 Ottimizzazione: presumed abort / commit  Obiettivi: –ridurre il numero di messaggi trasmessi tra coordinatore e partecipanti –Ridurre il numero di scritture nei log  Regola: –Quando il TM riceve una richiesta di recovery da parte di un RM che non sa come procedere in seguito a un guasto, il TM decide sempre per il global abort  Quindi, il TM puo’ abbandonare la transazione subito dopo avere deciso per abort –Non si aspetta risposta dai RMs –Non occorre fare una force dei record di prepare e global abort perche’ il comportamento di default in assenza di record di log e’ identico a quello di abort  Quindi gli unici record da scrivere sono ready, global commit e commit

Basi di Dati distribuite - Paolo Missier– 88 Interoperabilita’  Il problema principale nello sviluppo di applicazioni eterogenee per DDBS e’ l’interoperabilita’ a livello di sistema  Ignoriamo l’eterogeneita’ di schemi e semantica  E’ necessario introdurre funzioni di –Adattamento e Conversione di formati /protocolli  A livello di protocollo, l’interoperabilita’ e’ garantita da standards quali FTP, SMTP/MIME, ecc.  Nell’area dei DBMS, introduciamo standard di interoperabilita’ per –Accesso alle funzioni del server  interfacce tipo ODBC –Coordinazione di transazioni su piu’ nodi  protocollo DTP

Basi di Dati distribuite - Paolo Missier– 89 Interfaccia di accesso al DB: ODBC  API Microsoft, nata nel 1991  Orientata all’accesso a sistemi relazionali  Supporta una versione ristretta di SQL –Core set di istruzioni  Modello basato sull’uso di driver del server –Implementato come libreria di accesso disponibile al client –Il driver maschera l’eterogeneita’ a livello di DBMS, OS, e protocollo di rete –Ex.: un driver puo’ essere definito per la configurazione Sybase, + Windows NT + Novell  ODBC non supporta il protocollo 2PC

Basi di Dati distribuite - Paolo Missier– 90 Componenti di ODBC  L’applicazione sottopone queries SQL all’interfaccia  Il driver manager (Microsoft) carica il driver specifico per il DBMS target + OS + rete  Il driver implementa l’interfaccia ODBC e funge da client verso il DBMS, eventualmente effettuando traduzioni di sintassi  Il DB server e’ noto come data source. Riceve richieste da ODBC e ritorna i risultati come a qualunque client

Basi di Dati distribuite - Paolo Missier– 91 X-Open distributed transaction processing (DTP)  Un protocollo per l’interoperabilita’ tra DBMS diversi a livello di transazioni distribuite  Attori: –Client –TM: Transaction Manager –RMs: Resource Managers. Sono i partecipanti alla transazione  Il protocollo prevede due interfacce: –TM-interface: tra Client e TM –XA-interface: tra TM e ogni RM  Un DBMS che aderisce al protocollo deve supportare l’interfaccia XA (perche’ il DBMS e’ un RM)  Il Transaction Manager (TM) e’ di norma un componente fornito da middleware transazionale, ad es.:  Encina (Transarc)  Tuxedo (BEA Systems)

Basi di Dati distribuite - Paolo Missier– 92 Caratteristiche di X-Open DTP  I RM sono passivi. Rispondono a RPCs originate dal TM  Il protocollo e’ 2PC con presumed abort e ottimizzazioni read-only  Il protocollo supporta decisioni euristiche –In presenza di guasti, consente il proseguimento di una transazione sotto il controllo dell’operatore –Quando un RM e’ bloccato a causa di un guasto al TM, un operatore puo’ imporre una decisione euristica (normalmente abort), consentendo il rilascio delle risorse –Quando decisioni euristiche provocano perdita di atomicita’, il protocollo garantisce che i processi cliente vengono informati –La risoluzione di inconsistenze dovute a decisioni euristiche sbagliate e’ affidato all’applicazione

Basi di Dati distribuite - Paolo Missier– 93 TM Interface  tm_init e tm_exit: iniziano e terminano una connessione client-TM  tm_open e tm_term : aprono e chiudono una sessione con il TM  tm_begin : inizia una transazione  tm_commit : richiede un global commit

Basi di Dati distribuite - Paolo Missier– 94 XA interface  xa_open e xa_close : aprono e chiudono una sessione tra il TM e un dato RM  xa_start e xa_end: attivano e completano una transazione  xa_precom : richiede un pre-commit ad un RM; il RM risponde affermativamente solo se si trova in uno stato recoverable  xa_commit e xa_abort : comunicano la decisione globale del TM sulla transazione  xa_recover : inizia la procedura di recovery dopo il fallimento di un processo TM o RM. Secondo il protocollo 2PC, il RM consulta il suo log e costruisce tre insiemi di transazioni: –Transazioni in doubt –Transazioni decise da heuristic commit –Transazioni decise da heuristic abort  xa_forget consente ad un RM di abbandonare transazioni decise in modo euristico

Basi di Dati distribuite - Paolo Missier– 95 Cooperazione tra sistemi pre-esistenti  Per cooperazione si intende la capacita’ per una applicazione di utilizzare servizi applicativi resi disponibili da altri sistemi, eventualmente gestiti da altre organizzazioni  La necessita’ di cooperare nasce da ragioni diverse –Richiesta di integrazione di componenti sviluppati separatamente –Merger di organizzazioni con sistemi informativi diversi…  L’integrazione tra DBs e’ complessa –Limitata nella pratica a integrazione semplice di schemi –Il modello ideale di un DB fortemente integrato che supporta transparenza totale e’ difficile da realizzare in pratica

Basi di Dati distribuite - Paolo Missier– 96 Cooperazione sui dati e tra processi  Distinguiamo due tipi di cooperazione: –Centrata sui processi: Ogni sistema puo’ offrire ad altri sistemi servizi utilizzando varie infrastrutture di comunicazione  Scambio di messaggi, documenti, dati  Innesco di attivita’ –I dati restano privati –Centrata sui dati, i cui i sistemi sono distribuiti, eterogenei e autonomi, e accessibili da remoto secondo accordi di cooperazione e protocolli standard  Nel seguito, consideriamo solo cooperazione centrata sui dati

Basi di Dati distribuite - Paolo Missier– 97 Cooperazione basata sui dati - caratteristiche  Livello di trasparenza  Compessita’ delle operazioni distribuite –Misurano il grado di coordinazione necessario per effettuare operazioni su DB cooperativi  Il livello di currency indica in che misura i dati acceduti sono aggiornati  In base a questi criteri, e’ possibile distinguere tre architetture per la cooperazione centrata sui dati

Basi di Dati distribuite - Paolo Missier– MultiDatabases  Massima autonomia (sistema dedicato ad applicazioni e utenti locali)  Ciascun sistema e’ acceduto tramite moduli chiamati mediatori. Ogni mediatore rivela al global manager una porzione del DB da esportare  Il global manager e’ responsabile dell’integrazione  In generale, i mediatori offrono solo accesso read-only ai dati locali  Caratteristiche: –Presentano una vista integrata all’utente –Forniscono un alto livello di trasparenza –Garantiscono buona curreny perche’ le sorgenti dati sono accedute direttamente

Basi di Dati distribuite - Paolo Missier– Sistemi basati su replicazione  Garantiscono accesso read only a copie secondarie dei dati descritti dalle viste esterne  I dati possono essere trasferiti su Data Warehouses –Cosidette “viste materializzate”  Caratteristiche: –Presentano una alto livello di integrazione e trasparenza, ma un grado minore di currency

Basi di Dati distribuite - Paolo Missier– – Sistemi basati su accesso esterno ai dati  L’integrazione e’ a carico dell’applicazione  Vedi esempio –DB esterno –DB locale –DW, definito su tre fonti di informazione  Caratteristiche: –Basso grado di trasparenza e integrazione –La currency dipende dalle esigenze specifiche

Basi di Dati distribuite - Paolo Missier– 101 Parallelismo  Sviluppata negli anni ’90 in concomitanza con la diffusione di architetture multiprocessore –Seguono il fallimento delle cosidette database machines negli anni ‘80  DBMS paralleli supportati da diverse architetture (shared- all / shared-nothing)  Motivazione (ovvia): uno scan completo di un DB di grandi dimensioni puo’ essere frazionato in n scans, su ognuna di n partizioni (fisiche) del DB  Se le partizioni risiedono su n dischi diversi gestiti da n processori diversi, il response time sara’ circa 1/n del tempo richiesto da uno scan sequenziale

Basi di Dati distribuite - Paolo Missier– 102 Parallelismo inter-query  Consiste nell’esecuzione parallela di piu’ queries –Il carico imposto da un DBMS e’ caratterizzato tipicamente da transazioni semplici e frequenti  Ordine di migliaia di transazioni /secondo –Il parallelismo si basa sul multiplexing dei servers e sull’allocazione “ottimale” di richieste ai diversi server  Da parte di un processo dispatcher –Utile per sistemi OLTP

Basi di Dati distribuite - Paolo Missier– 103 Parallelismo intra-query  Consiste nell’esecuzione parallela di sotto-query a partire da una query globale –Il carico sul DBMS e’ caratterizzato da poche queries complesse  Decomposte in sotto-queries parziali –Normalmente le queries vengono eseguite in sequenza, utilizzando ciascuna l’intero sistema multi-processore per ognuna –Utile per sistemi OLAP

Basi di Dati distribuite - Paolo Missier– 104 Parallelismo e frammentazione  Esempio: ACCOUNT (AccNum, Name, Balance) TRANSACTION (AccNum,Date,SerialNumber,TransactionType,Amount) Schema frammentato in modo orizzontale in base a intervalli di AccNum

Basi di Dati distribuite - Paolo Missier– 105 Tipica query OLTP parallelizzabile  Con parallelismo inter-query: procedure Query5(:acc-num, :total); select Balance into :total from Account where AccNum = :acc-num; end procedure;  Diretta ad un nodo specifico, in base al valore di :acc-num

Basi di Dati distribuite - Paolo Missier– 106 Tipica query OLAP parallelizzabile  Con parallelismo intra-query: procedure Query6(); select AccNum, sum(Amount) from Account join Transaction on Account.AccNum = Transaction.AccNum where Date >= and Date < group by AccNum having sum(Amount) > ; end procedure;  Ogni frammento contribuisce alcuni gruppi  Ciascun gruppo calcolato in parallelo  Richiede unione finale dei risultati parziali

Basi di Dati distribuite - Paolo Missier– 107 Metriche per il parallelismo: Speed-up e scale-up  La curva di speed-up caratterizza solamente il parallelismo inter-query –Misura l’incremento di throughput (in tps -transactions per second), rispetto all’incremento nel numero dei processori –In una situazione ideale, il throughput cresce in modo quasi lineare con il numero di processori  La curva di scale-up caratterizza sia il parallelismo inter- query che intra-query –Misura il costo medio di una transazione rispetto all’incremento nel numero dei processori –In una situazione ideale, il costo medio rimane pressoche’ costante all’aumentare dei processori –Il sistema “scala bene”

Basi di Dati distribuite - Paolo Missier– 108 Benchmarks delle transazioni  Test specifici per misurare l’efficienza di DBMS (eventualmente paralleli)  Descrive il sistema in termini di curve di speed-up e scale-up calcolate in condizioni di esecuzione standard  Standardizzte dal TPC (Transaction Processing Performance Council) –Un comitato di circa trenta suppliers di sistemi DBMS e transazionali  Sono definiti tre benchmarks (TPC-A, TPC-B and TPC-C) rispetticamente per applicazioni OLTP, miste, e OLAP  Applicabili a archietture mainframe-based, client-server, o parallele  Parametri utilizzati nei benchmarks: –Codice del tipo di transazione –Dimensione del database –Metodo utilizzato per generare i dati –Distribuzione degli arrivi della transazione (in generale, Poisson) –Tecniche per misurare e fare l’auditing del benchmark

Basi di Dati distribuite - Paolo Missier– 109 DB replicati  Supportata da prodotti di data replication –Obiettivo: mantenere la consistenza tra le copie –Funzionano in modo trasparente rispetto alle applicazioni che operano sul DBMS  In generale, esiste una copia principale e diverse copie secondarie –Le updates sono propagate in modo asincrono –Senza supporto 2PC  Propagazione incrementale: basata sulle modifiche ai dati, inviate dalla copia principale alle copie secondarie  L’uso della replicazione rende il sistema piu’ resistente ai guasti –In caso di indisponibilita’ della copia principale, e’ possibile usare una delle copie

Basi di Dati distribuite - Paolo Missier– 110 Architettura per data replication  L’architettura ha due siti identici. Ogni sito gestisce l’intero DB; una meta’ contiene la copia principale, l’altra meta’ e’ la copia secondaria  Tutte le transazioni sono inviate alla copia principale e ridirette alla copia secondaria  Ogni “punto di accesso” al sistema e’ connesso ad ambedue i siti  In caso di guasto che coinvolge solamente un sito, il sistema e’ capace di commutare rapidamente tutte le transazioni veso l’altro sito, che deve essere in grado di supportare l’intero carico (fail- soft)  Una volta risolto il problema, il replication manager fa un restore dei dati in modo trasparente e quindi pone ambedue i siti in modalita’ normale

Basi di Dati distribuite - Paolo Missier– 111 Architettura - descrizione  Applicazione creata da Tandem verso la meta’ degli anni ’80  Tandem aveva una decina di fabbriche sparse per il mondo  Ogni fabbrica responsabile della produzione di una parte specifica dell’architettura di un computer  Le tabelle erano frammentate in modo corrispondente alla distribuzione fisica dei componenti e allocate ai nodi in modo ridondante: –Main copy: sul nodo responsabile del processo produttivo dei componenti descrtti in quel frammento –Secondary copies: replicate a tutti gli altri nodi  Il replication manager entrava in funzione periodicamente, propagando le modifiche ad un nodo in modo asincrono a tutte le altre copie

Basi di Dati distribuite - Paolo Missier– 112 Funzioni avanzate dei replication managers  Replicazione simmetrica: le modifiche possono essere originate da ogni copia –Configurazione peer-to-peer –In assenza di concurrency control, e’ possibile introdurre conflitti tra le copie –E’ possibile determinare i conflitti in modo automatico, e definire strategie di risoluzione diverse per diversi tipi di dati  Replicazione non-connessa: si ha con sistemi mobili, nei quali e’ comune che la comunicazione tra i nodi si interrompa –Es.: un venditore si connette con il server per scaricare le disponibilita’ del magazzino e per caricare nuovi ordini –Il venditore e’ normalmente sconnesso dal sever. Le sue transazioni operano su copie (del magazzino) –La copia viene “riconciliata” con il main periodicamente