Query continue

Le query sui data stream hanno molto in comune con le query dei tradizionali DBMS. Tuttavia, ci sono due principali differenze se si vogliono gestire efficien-temente i data stream. La prima differenza sta nel fatto che le tradizionali query dei DBMS sono one-time queries (o one-shot queries), ovvero vengono valutate ed eseguite una sola volta sull’intero data set e la risposta viene ritornata al-l’utente. Nei DSMS invece le query sono principalmente continuos queries (o persistent queries), ovvero vengono valutate ed eseguite continuamente sul data stream in arrivo. Ad ogni esecuzione della query continua vengono fornite nuove risposte sulla base dei dati che sono arrivati. Queste risposte possono essere memorizzate in opportuni storage oppure possono diventare a loro volta nuovi data stream che andranno in ingresso ad altre query.

predefinite sono query che possono essere specificate prima dell’arrivo dei dati e sono generalmente anche continue. Le query ad hoc sono invece sottomesse online quando i dati sono gi`a presenti e sono tipicamente one-shot. Le query ad hoc rendono pi`u difficile la gestione dei dati perch`e non essendo conosciute a priori `e difficile effettuare operazioni di ottimizzazione.

Le query continue possono essere a loro volta classificate in due categorie sulla base del trigger che le fanno eseguire:

• Change-Based : La query viene eseguita quando si verifica un cambiamento nei dati in arrivo.

• Timer-Based : La query viene eseguita ad intervalli di tempo regolari specificati dall’utente che sottomette la query.

In una query continua si pu`o anche eventualmente speficare una stop condition che specifica la condizioni necessarie per fermare la query. Le stop condition possono essere a loro volta time-based, se la condizione di stop `e specificata da un parametro temporale (es: ferma la query se sono passati pi`u di 5 giorni), o event-based, se la condizione di stop `e specificata dal verificarsi di un evento (es: ferma la query se il prezzo sale pi`u del 5% rispetto al suo valore originario). Formalmente una query continua pu`o essere specificata come una tripla

(Q, Tcq, Stop), in cui rispettivamente Q rappresenta la query da eseguire scritta in un linguaggio SQL-like, T_cq rappresenta il trigger che la fa eseguire e Stop rappresenta la stop condition. Il risultato della query Q sul data set S_i pu`o essere indicato con Q(S<sub>i</sub>). Il risultato di una query continua pu`o essere definito come la sequenza delle risposte {Q(S1), Q(S2), ..., Q(Sn)} ottenute eseguendo la query Q sui vari data set S_i, 1 ≤ i ≤ n, il cui trigger di Q(S_i) `e T_cq ∧ ¬Stop.

Le caratteristiche particolari del modello dei dati e delle query continue richiedono al data stream management system le seguenti caratteristiche:

• Il modello dei dati e la semantica delle query devono prevedere delle oper-azioni time-based (es: finestre temporali) e order-based.

• L’incapacit`a di poter memorizzare l’intero data set richiede alle query la possibilit`a di fornire risposte approssimate o incomplete interrogando delle strutture dati che contengono un ’riassunto’ di un certo data set. In letteratura queste strutture dati sono note come synopses o digests.

• Gli streaming query plans non devono usare degli operatori bloccanti [15] che consumano tutto l’input prima di fornire alcuna risposta.

• Dati i vincoli di performance e memoria primaria limitata non deve es-sere possibile, per una stessa query, accedere pi`u volte sugli stessi dati (backtracking). Gli algoritmi di interrogazione devono prevedere una sola passata sui dati.

• Le applicazioni che monitorizzano gli stream in real-time devono reagire velocemente a dati anomali o inusuali.

• Le query continue eseguite per lungo tempo possono incontrare cambia-menti nelle condizioni del sistema o dello stream di input e quindi de-vono essere previsti meccanismi di adattamento alle variazioni in modo da garantire bassi tempi di risposta.

• L’esecuzione condivisa di pi`u query deve essere sempre prevista in modo da garantire la scalabilit`a del sistema.

Per quanto riguarda i linguaggi di interrogazione vengono utilizzati varianti del linguaggio di interrogazione relazione SQL. Anche se la tipologia di dati e di applicazioni potrebbe portare ad una scelta progettuale verso un linguaggio nuovo di interrogazione, la scelta di estendere SQL `e sicuramente condivisibile in quanto rende la curva di apprendimento del nuovo linguaggio meno ripida. La soluzione migliore consiste nell’estendere il linguaggio SQL con una serie di operatori atti a permettere operazioni su ’finestre’ di dati provenienti da una sorgente. Solitamente, infatti, il flusso dei dati di una certa sorgente viene sud-diviso in finestre delimitate o temporalmente oppure da un numero predefinito di tuple. Una volta che una finestra `e disponibile, i trigger registrati dall’utente per quella sorgente vengono invocati e, quando le operazioni su quella finestra sono state tutte eseguite, le tuple in essa contenute vengono eliminate. Alcuni sistemi fanno eccezzione (come previsto nel DSMS di PEGASUS) in quanto non prevedono la cancellazioe dei dati ’consumati’. Questi sistemi memorizzano su memorie di massa i dati consumati e dedicano particolare attenzione all’analisi dei dati storici: l’approccio generalmente scelto `e quello di creare repository dis-tribuiti di tipo Warehouse per supportare efficientemente eventuali analisi OLAP da parte degli utenti del sistema.

e l’espressivit`a. L’efficienza `e assolutamente necessaria a causa della particolare natura dei dati generati dalle sorgenti. Essi sono infatti potenzialmente illimitati ed il loro arrivo imprevedibile a priori. Inoltre, l’efficienza `e necessaria non soltan-to in fase di arrivo ed elaborazione dei dati, ma anche in fase di interrogazione. Infine, poich´e le applicazioni che usano dati a flusso sono molto differenti fra loro, in generale `e molto pi`u significativo un sistema che riesca ad adattarsi alle particolari condizioni di esecuzione oppure alla natura dei dati. Qui entra in gioco l’altro parametro importante: l’espressivit`a. Grossa parte dell’espressivit`a di un sistema `e garantita dal linguaggio adottato per esprimere le interrogazioni (queries) e per elaborare i flussi di dati provenienti dalle sorgenti. Pi`u formal-mente potremmo definire l’espressivit`a di un sistema come la facilit`a per i suoi utenti di esprimere le interrogazioni. Pi`u un sistema `e espressivo e pi`u dovrebbe essere semplice esprimere la maggior parte delle queries.