SISTEMI DISTRIBUITI prof. S.Pizzutilo Motore di riempimento DB (generatore dati per simulazione) Studente: Alessandro Balestrucci 617937 Corso di Laurea: Informatica Magistrale Dipartimento di Informatica Università degli Studi di Bari – A.Moro Introduzione – problematica di interesse L’esigenza di dover sempre più spesso interagire con database di grandi dimensioni ci porta spesso a dover scrivere funzioni (o trigger) che ci facilitano il raggiungimento dei nostri obbiettivi di business. Ma se queste funzioni che implementiamo, vanno a modificare (update… set…), anche in modo irreversibile (delete) sul DB su cui operiamo, potremmo intercorrere in problemi gravi; si pensi a dati molto sensibili (db bancari, azionari, medicali) Obbiettivi di progetto n Limitare l’operatività diretta su DB di business per operazioni di modifica e cancellazione n Realizzazione di un motore che astragga la struttura del DB su cui vogliamo operare, e che permetta l’inserimento di tuple simulate, anche da diversi client. n Invece di una copia (spesso si tratta di DB troppo grandi), si generino dati nuovi e casuali, ma sempre coerenti con la struttura del DB originale n Rendere la generazione un processo distribuito, dove diversi client cooperano tra loro al fine di costruire files contenenti le queries generative. Aspetti di interesse Per quanto concerne a questo corso di studi, si vuole mostrare le proprietà di questo software, e in particolare si illustrerà: n Tipo di architettura di sistema n Strumento SW per la comunicazione n Gestione della Concorrenza fra processi n Server Multithreading n Distributività e Cooperazione del sistema Architettura del sistema (client – server) Il sistema che ho progettato e successivamente implementato, possiede un architettura client-server. Dove i diversi client effettuano richieste che possono o meno modificare la risorse condivisa presente sul server oppure ottenere un servizio/oggetto Vantaggio: al server viene demandata tutta la responsabilità di gestire la risorsa: Svantaggio: crush del server. Client side La comunicazione con il server è prevista esclusivamente per 2 scopi/servizi: n Verifica esistenza (in altri client) della Chiave Primaria n Richiesta di un elemento da attribuire al vincolo di Chiave esterna (take element) Server side Il server è il possessore e gestore della risorsa condivisa tra i vari client; e dualmente a quanto detto sul client viene interrogato per: n eseguire una ricerca su tale risorsa n Aggiornamento incrementale della risorsa n Restituzione degli esiti della ricerca n Restituzione di un elemento della risorsa Strumento utilizzato per la comunicazione (socket) Lo strumento per la comunicazione più adeguato ai fini del mio progetto, ho ritenuto essere la SOCKET con modalità STREAMING, permettendomi così di poter usufruire di una comunicazione sincrona tra client e server, stabile e full duplex. Rappresentazione di un indirizzo secondo l’Internet Protocol (IP) Inizializzazione socket per connessione con protocollo TCP (Ip address del server e il port di fruizione del servizio) Port è un astrazione software con la quale si associa un servizio offerto Utilizzata dal SERVER per ascoltare eventuali richieste che giungono dai client, sulla PORT specificata Attraverso il metodo ACCEPT, si restituisce una socket con la quale avviene la comunicazione lato server. (Socket to Socket) Gestione della concorrenza (problema) Il problema della gestione della concorrenza è stato un punto cruciale nello sviluppo di questo sistema; le domande che mi posi furono: n E se invece che produrre i dati da solo, volessi farmi aiutare da altri computer? n Cosa succede se più client si connettono contemporaneamente? n Cosa succede se più client producono lo stesso valore? n Cosa succede se più client vogliono estrarre un valore? Risorsa condivisa Nel mio sistema i diversi client si contendono, durante il procedimento di generazione, una risorsa. Dizionario (HashTable) di corrispondenze nomeCampoChiave (primaria) e array degli oggetti (elementi veri e propri prodotti dai vari client), saranno i valori di FK per altre tabelle [key] dbCoord = DBAccess.getNome()+“-”+tabella.getNome()+"."+ pk.getNome(); Multithreading (server) Multithreading (server) – sicurezza 1/2 Multithreading (server) – sicurezza 2/2 [β] Sezione critica n Esistenza del Valore generato per la chiave primaria n Esistenza del Campo Chiave Primaria in Dizionario Synchronized (funzionamento) n La parola riservata synchronized consente una accurata gestione dei metodi. n Garantisce un accesso sincronizzato ad eventuali risorse gestite da tali metodi, per mezzo di un lock. n Quando un THREAD sta utilizzando un oggetto per mezzo di un metodo synchronized, tale oggetto viene bloccato (locked) per evitare altri accessi concorrenti. n In pratica tale parola chiave, racchiude il concetto di Monitor, strumento che ci consente di garantire la mutua esclusione sulla risorsa condivisa; in grado di bloccare e risvegliare threads. Distributività e Cooperazione Connessione DB n Server IP: ubicazione fisica del DB di Prova da riempire (IP o Logic name) n Name of DB: nome del Database n PORT: porta servizio DBMS n User_role & Password: credenziali di accesso n Ram DB Server (IP): indirizzo del Server Estrazione struttura DB – ADT Database n n Inizializzazione Struttura Astratta DB Estrazione caratteristiche struttura DB – Caricamento dizionario DataType del DBMS – Estrazione delle tabelle dal DB attraverso i metaData – Costruzione dei tipi astratti delle tabelle, con il settaggio di tutte le colonne e delle loro proprietà (nome, tipo, not null, precisione, lung stringa, ecc) n Aggiunta vincoli intra ed inter relazionali per tutte le tabelle, e settaggio dei rispettivi campi e delle classi vincolo (FK) – Estrazione del campo chiave primaria (metaData) – Estrazione del campo chiave esterna (metaData), – Attribuzione ai rispettivi campi della struttura tabella di questi vincoli – Per ogni chiave esterna si specifica sia la tabella referenziata che il campo – Settaggio dei campi che esportano le chiavi esterne Procedura prioritaria di ordinamento tabelle n Estraggo l’array contenente le tabelle già settate n Priorità principale a tutte le tabelle senza FK n Priorità secondaria alle tabelle le cui FK referenziano unicamente alle tabelle e ai campi, di cui prima, n E così via Vincoli sui campi (opzionali) Algoritmo di generazione - CORE n n n n Passaggio di parametri al metodo di generazione della query (tabella, keyServer, Sokstream) Si distingue il caso in cui la chiave primaria sia composta da uno o più campi Per ciascun campo/colonna si distingue se sia una Chiave primaria, una chiave esterna o semplicemente un campo senza vincoli CASO CHIAVE PRIMARIA: si genera elemento RANDOM a seconda del tipo e – si interroga il server, attendendo una sua risposta. – eventualmente produce un altro valore e si ripete. n n n CASO CHIAVE ESTERNA: non avviene alcuna generazione ma un interrogazione al server, al quale si chiede di restituire un elemento della risorsa condivisa usando come chiave il campo chiave primaria della tabella a cui fa riferimento CASO CAMPO NON VINCOLATO: si genera un elemento RANDOM a seconda del tipo (Data Type) che possiede I valori degli elementi generati sono prodotti in due possibili modi: – RANDOM, coerentemente a datatype e alle proprietà del campo nel DB – VINCOLATA, ma sempre in modo RANDOM, utilizzando dei parametri di limitazione in merito alla generazione » MEMORIA LOCALE, in caso di estrazione da File, questo viene conservato nello stack. n n Si costruisce la tupla in modo incrementale, concatenando i valori.TOSTRING alla query parziale. Terminati i campi e costruita la stringa di query il processo di generazione termina e si procede al TEST della tupla Test tupla, output files e FTP Upload n n Test tupla FTP Upload n Output Files Work in progress (β) n Elaborazione misure di sicurezza in relazione alle prestazioni del Server (accennato nel mutithreading) n Trasferimento al server della procedura di ordinamento delle tabelle, per ogni DB su cui vogliono operari i client n Miglioramenti nella procedura di Test tuple n Costruzione dell’applicazione MASTER per la generazione del file “simulazioneDati.sql” n Interfacciamento con più DBMS n Espansione formati (xml, json, ecc..) GRAZIE PER L’ATTENZIONE