Obiettivo della tesi Percorso

Presentazione sul tema: "Obiettivo della tesi Percorso"— Transcript della presentazione:

1

2 Obiettivo della tesi Percorso
Sviluppo di una applicazione software per verificare la correttezza di un modello di costo in ambito Data Warehouse si è fatto riferimento al modello di costo pubblicato da Engström et al. la Tesi è stata svolta presso l’Università di Exeter (UK) e l’Università di Skövde (Svezia) Percorso Il problema affrontato Gli elementi più significativi del modello di costo Applicazione software Esempi di risultati sperimentali

3 Il sistema considerato nel modello di costo
Data Warehouse Database Sorgente DB1 Database Sorgente DB2 Database Sorgente DBN .. Data Warehouse Il sistema considerato nel modello di costo Dati Database sorgente Tabella Data Warehouse Vista Delta Query Update Utenti Utenti

4 Il problema affrontato
nel Modello di costo nella Tesi Validazione Sperimentale: corrispondenza tra il comportamento di un sistema reale e le predizioni del modello Sistema reale + Strumenti per eseguire esperimenti Update

5 Il modello di costo (1) Caratterizzazione delle proprietà della sorgente

6 Misure tradizionali (esecuzione e comunicazione)
Il modello di costo (2) - Nuova metrica (qualitativa e quantitativa) Istante in cui la query è posta Z Risposta basata sullo stato 1 di S1 e 3 di S2 DW t S1 t 1 S2 t 1 2 3 Misura staleness (Z) Database sorgente Tempo di esecuzione Data Warehouse Tempo di esecuzione Tempo di comunicazione Misure tradizionali (esecuzione e comunicazione)

7 Applicazione software – Criteri guida
Per il linguaggio: portabilità, gestione della concorrenza, gestione connessioni a database; Per l’architettura funzionale: chiara separazione tra le classi che modellano il sistema e le classi che si occupano di controllare e misurare lo stesso; Per i benchmark: rilevanza delle grandezze osservate, scalabilità, chiarezza nell’esporre le caratteristiche dell’implementazione e nel presentare i risultati.

8 Applicazione software - Architettura
Saccess Interbase ACCESS Supdater thread Wquerier thread Database sorgente Emulazione del carico Row Table Nuovi tipi di dato Director Configuration Data generator Gui Waccess Wrapper thread Data warehouse Controllo e misurazione Entità del sistema Classi di benchmark

9 Applicazione software – Implementazione (1)
Caratteristiche della sorgente Tabella sorgente Tabella DAW Database Sorgente Trigger Aggiornamenti Update Insert Delete Numero dell’ultimo update inviato al DW Supdater Se non DAW Se DAW Wrapper confronto Wrapper Waccess Numero dell’ultimo update della sorgente che ha subito il commit Le proprietà CHAC e CHAW La proprietà DAW

10 Applicazione software – Implementazione (2)
Emulazione del carico di lavoro Caratterizzazione degli update Basata sull’analisi di Adelberg / Garcia-Molina: Update parziali Frequenza aperiodica Esecuzione immediata Distribuzione di Poisson

11 Applicazione software – Implementazione (3)
Emulazione del carico di lavoro Esplorazione di nuovi algoritmi per produrre il flusso di update Pre- scheduling Pro: flusso di update pronto all’inizio di un esperimento Contro: numero di update comunque limitato Run-time Pro: flusso illimitato Contro: attenzione ai ritardi introdotti Vincente: Algoritmo del Guide Attribute a run-time

12 Validazione e Verifica
garantita dal modello di costo considerato Verifica: svolta mediante controllo dei protocolli e del comportamento sotto carico

13 Verifica (1) I protocolli
Metodo: introduzione di un appropriato output di sistema Utilità: 1) Controllare la corretta sequenza di operazioni nell’eseguire le politiche di manutenzione 2) Verificare la effettiva indipendenza tra i processi concorrenti

14 Comportamento sotto carico
Verifica (2) Comportamento sotto carico Metodo: creazione di applicazioni esterne di supporto per il monitoraggio della dinamica del sistema Utilità: 1) Osservare la evoluzione del sistema nel tempo 2) Controllare le proprietà statistiche degli algoritmi (es: dimensione della tabella sorgente e distribuzione dei valori dei GA)

15 Ambiente di esecuzione
Benchmark Ambiente di esecuzione Piattaforma: Sun Ultra 5, Solaris 8, 128 MB, Interbase 6.0, Java 1.2, Codice bytecode 77 Kb Tuning dei parametri di basso livello del sistema operativo e del Dbms Ispezione della qualità dei risultati: si scartano i risultati ottenuti da esperimenti che non soddisfano i criteri di integrità definiti (es: overlapping update, overlapping query)

16 P2: Modifica totale (blu)
Benchmark Esempi (1) Legenda P1: Modifica Incrementale con DAW (violetto) P2: Modifica totale (blu) Staleness al variare della frequenza di polling in caso di aggiornamenti periodici del data warehouse. Le due politiche offrono prestazioni sempre più simili al diminuire della frequenza di aggiornamento del DW.

17 Risultati sperimentali Predizioni del modello di costo
Benchmark Esempi (2) Risultati sperimentali ( P1 blu, P2 violetto) Predizioni del modello di costo (P1 nero, P2 verde) Costo integrato (esecuzione e comunicazione) al variare della frequenza di polling. L’evidenza sperimentale è in pieno accordo con le predizioni del modello anche in caso di configurazioni dei parametri estreme.

18 CONCLUSIONI L’applicazione implementa tutti gli aspetti del modello di costo Ha superato tutti i test di verifica Gli esempi di benchmark hanno permesso di: 1) fornire conferma di taluni comportamenti del modello; 2) migliorare la nostra conoscenza sul suo comportamento; 3) evidenziare possibili punti di discussione per affinare il modello;

19 Sviluppi futuri Caso distribuito (Java RMI)
Estensione al caso multisorgente Considerazione di sorgenti non-relazionali (XML)