DBMS vs DSMS

In questi ultimi anni si sono sviluppate molte applicazioni data-intensive [13] in cui il dato deve essere gestito in maniera differente rispetto alla normale gestione prevista dai tradizionali DBMS. La prima grande differenza risiede nel fatto che in queste applicazioni si devono gestire stream di dati continui anzich`e dati ’stati-ci’. Uno stream di dati `e una sequenza di oggetti (tuple) real-time, continui e ordinati dal tempo di arrivo o dal timestamp la cui dimensione totale `e poten-zialmente infinita. Date queste caratteristiche, le query non possono essere val-utare sull’intero dataset ma solo su una certa finestra temporale. Generalmente nei DBMS i dati sono ’permanenti’ con poche operazioni di inserimento/cancel-lazione/aggiornamento e le query su di essi sono molto complesse ed eseguite ad-hoc (one-shot ) sull’intero dataset. In questa nuova classe di applicazione in-vece i dati sono ’transienti’, ovvero le operazioni di inserimento e aggiornamento

su di essi sono molto frequenti, e le query richieste sono continue nel tempo ed eseguite su un sottoinsieme dell’intero dataset. Questi aspetti aprono un nuovo problema nel campo della ricerca.

Figura 2.1: Principio di funzionamento di un DBMS Le principali differenze sono riportate nella tabella 2.1.

Un esempio di queste applicazioni sono l’analisi finanziaria, il monitoraggio delle reti, la sicurezza, le sensor network, l’analisi delle richieste web, ecc. In queste applicazioni risulta estremamente inefficiente inserire i dati in arrivo in un nor-male DBMS ed eseguire delle normali query su di essi. Questo perch`e i nor-mali DBMS non sono stati progettati per gestire stream di dati e non offrono in maniera diretta delle funzionalit`a per gestire query continue. Inoltre, per garantire le performance nell’esecuzione delle query sugli stream di dati, devono essere previsti meccanismi di approximation (possibilit`a di fornire risposte

ap-Figura 2.2: Principio di funzionamento di un DSMS

prossimate) e adaptivity (cambiamento dinamico del query plan al cambiare delle caratteristiche dello stream in input), aspetti che sono completamente opposti alle caratteristiche dei DBMS tradizionali che prevedono query plan stabili e risposte precise.

Le query approssimate vengono utilizzate quando per ottenere risposte precise `e richiesto troppo tempo e quindi la risposta perde di importanza. Spesso si preferisce ottenere risposte meno precise ma fornite in un tempo pi`u rapido e queste tipologia di query sono spesso utilizzate in contesti hard real-time. L’adaptivity `e richiesto in quanto i dati arrivano online e il sistema non ha al-cun controllo su di essi, quindi le caratteristiche dei dati possono cambiare e di conseguenza mantenere un query plan statico pu`o risultare inefficiente. Questa tecnica di ottimizzazione `e divisa generalmente in due step. Il primo si occupa di effettuare a runtime delle statistiche, come ad esempio il tasso di arrivo dei dati, la selettivit`a degli operatori attuali, ecc. Il secondo step `e cercare una sostituzione al query plan attuale con uno pi`u efficiente, mantenendo la stessa semantica della query.

Il DSMS deve inoltre poter gestire l’esecuzione di pi`u query contemporanea-mente (shared execution) in maniera scalabile ed efficiente, per cui devono essere previsti meccanismi e politiche per l’accesso condiviso ai dati e ottimizzazione di query concorrenti. Ottimizzare delle query concorrenti significa evitare di eseguire pi`u volte lo stesso calcolo sugli stessi dati, memorizzando ad esempio

Tabella 2.1: DBMS versus DSMS Data Base MS Data Stream MS

- Relazioni persistenti - Stream transienti (online analysis) - Query one-shot molto complesse - Query continue piuttosto semplici

(CQs)

- Accesso prevalentemente random - Accesso prevalentemente sequen-ziale

- Spazio sul disco ’illimitato’ - Memoria primaria limitata - Importanza del dato presente - Importanza dei dati storici - Nessun servizio real-time - Requisiti hard real-time

- Operazioni di update poco frequenti - Frequenze di arrivo anche nell’ordine di pi`u Gigabytes

- Dati precisi e corretti - Possibilit`a di dati danneggiati o mancanti

- Query plan statico determinato dal query processor

- Cambiamenti impredicibili nello stream di dati in arrivo e quindi necessit`a di query plan dinamici - Query con risposte esatte - Necessit`a di fornire risposte

ap-prossimate in breve tempo - Umano Attivo, Database Passivo

(HADP)

- Database Attivo, Umano Passivo (DAHP)

- Query sequenziali - Pi`u query eseguite contemporanea-mente

dei risultati intermedi (chiamati synopsis) che possono essere riutilizzati da altri operatori di altre query, in modo da ottenere il risultato finale pi`u rapidamente evitando di rieseguire pi`u volte gli stessi calcoli.

I normali DBMS possono essere visti come un modello HADP (Human Active, Database Passive), ovvero modelli in cui il database `e un repository ’passivo’ di informazioni su cui l’operatore esegue delle query e transazioni. Inoltre i trig-ger e gli alerters sono di minore importanza rispetto ai dati; il risultato pi`u evidente di questa assunzione `e che nessun database oggi disponibile risulta scal-abile quando vengono definiti un grande numero di trigger, ossia superata una certa soglia di trigger definiti, il sistema degrada rapidamente le sue prestazioni. Nei sistemi in cui i dati sono a flusso, le funzionalit`a sono nella maggior parte dei casi basate proprio su trigger. I DSMS sono orientati secondo una filosofia DAHP (Database Active, Human Passive), ovvero modelli in cui il database non acquisisce i dati da transazioni umane ma in automatico da sorgenti esterne. Gli

utenti non eseguono delle query sui dati ma vengono notificati in automatico dal sistema in caso di necessit`a.