TelegraphCQ

Il sistema TelegraphCQ `e nato all’inizio del 2000 ed `e il risultato di una at-tivit`a di ricerca ed implementazione della Berkeley University [22]. Il sistema TelegraphCQ viene definito dai suoi progettisti come un sistema per l’esecuzione di query continuamente adattative su un dataflow ad utilizzo delle applicazioni finali. L’interesse ´e sempre la gestione di un grande numero di continuous query che operano su un numero altrettanto grande di data streams. Un aspetto inter-essante da prendere in considerazione `e che, nonostante il gruppo della Berke-ley abbia ampio accesso al codice sorgente di BerkeBerke-leyDB, abbia scelto un altro DBMS Open Source, PostgreSQL, da cui partire per implementare TelegraphCQ. I progettisti di TelegraphCQ fanno notare un aspetto fondamentale che dif-ferenzia i sistemi DBMS tradizionali da quelli a stream. Nei sistemi tradizionali, infatti, `e possibile operare l’orchestrazione dei dati e l’ottimizzazione delle query perch´e `e il sistema stesso che con operazioni di pull preleva i dati, ad esempio, da un disco. Nei sistemi a flusso, invece, i dati arrivano continuamente al sis-tema con un pattern di tipo push, il che cambia drasticamente sia le modalit`a di gestione e memorizzazione dei dati che le modalit`a di calcolo delle query. Una delle prime versioni del sistema TelegraphCQ ad essere stata implementata, ave-va un’architettura ottimizzata per supportare dati web fortemente annidati. Era sostanzialmente un sistema che non poneva l’accento sul supporto efficiente di query concorrenti quanto piuttosto sul supporto fortemente interattivo di query formulate da un singolo operatore. Una delle estensioni proposte dalla Berkeley University per Telegraph ´e CACQ. Il sistema CACG `e un modulo sperimentale sviluppato alla Berkeley University e serve come dimostrazione che i concetti ideati dal gruppo di Berkeley relativamente all’esecuzione di query continue su dati a flusso fossero effettivamente realizzabili. I componenti di cui `e composto il sistema sono:

• Eddie: Componente specializzato in complesse attivit`a di routing adatta-tivi delle tuple provenienti dagli stream.

• SteM : Dedicato a bufferizzare, indicizzare, fare join ed eventualmente eliminare le tuple instradate da componenti Eddie.

Il sistema Telegraph, pur supportando l’esecuzione contemporanea di pi´u query su un dato numero di stream, non prende in considerazione i seguenti importanti parametri per un sistema DSMS (Data Stream Management System): • Processa soltanto i dati che possono essere contenuti in memoria centrale. • Non analizza le prolematiche di scheduling distribuito e gestione delle risorse per query con piccole condivisioni di dati o addirittura senza con-divisioni di dati.

• Non utilizza il concetto di QoS per permettere al sistema di adattarsi ad ambienti con risorse limitate.

• Non considera la possibilit`a di variare il grado di adattivit`a del sistema per reagire ai sovraccarichi e migliorare la flessibilit`a.

Dopo avere fatto queste esperienze il gruppo della Berkeley ha completamente riprogettato il sistema Telegraph per ottenere TelegraphCQ. L’architettura del sistema presenta una metafora a moduli, ognuno dei quali appartiene ad una certa classe e risolve un particolare problema.

I moduli si dividono sostanzialmente in tre grandi categorie:

• Ingresso e Caching: Questa tipologia di moduli sono responsabili dell’in-terfacciamento con i data source esterni. Molti dei moduli preesistenti sono dei tradizionali wrapper verso l’HTML, l’XML oppure proxy verso le reti peer-to-peer. Altri sono moduli per leggere dati contenuti nel file system, altri ancora per utilizzare dati memorizzati in data base locali o remoti. Alcune implementazioni di moduli possono implementare una cache di dati per evitare i delay introdotti dalla rete.

• Esecuzione di Query: Nel sistema TelegraphCQ le query sono eseguite facendo arrivare le tuple ai moduli di query. Questi moduli sono messi in cascata e sono versioni non-bloccanti dei classici operatori relazionali quali:

Figura 2.10: Architettura TelegraphCQ. – Join.

– Selezione. – Proiezione.

– Raggruppamento ed aggregazione. – Eliminazione dei duplicati (Distinct).

TelegraphCQ utilizza anche operatori chiamati SteM (State Module, mod-ulo a stato). Uno SteM ´e un repository temporaneo di tuple. ´E capace di memorizzare tuple generate durante l’esecuzione di query e supporta le seguenti operazioni:

– Inserimento (build ). – Ricerca (probe).

– Cancellazione (Eviction).

• Routing Adattativo: Il sistema TelegraphCQ non si basa sui query plan tradizionali, che sono essenzialmente statici. Costruisce, invece, un query plan che contiene moduli di routing adattativo, che sono capaci di ottimiz-zare il piano della query in modo continuo durante l’esecuzione. I moduli di tipo Eddie decidono in modo adattativo come instradare i dati ad altri

operatori prendendo decisioni tupla-per-tupla. I moduli di tipo Juggle implementano operazioni di ordinamento al volo dei dati (tuple) in base al timestamp oppure al contenuto. I moduli di tipo Flux instradano le tuple fra le macchine di un cluster per supportare il parallelismo, il bilanciamento del carico e la tolleranza ai guasti.

Per quanto riguarda la semantica delle query, il sistema supporta countinuous queries calcolate su insiemi di tabelle e data streams. Per riuscire a gestire flussi di dati illimitati, alcuni operatori possono essere eseguiti soltanto su finestre di dati di dimensione finita. Ogni finestra ´e caratterizzata da una posizione iniziale ed una finale che servono a specificare quali tuple sono presenti nella finestra corrente. Al fine di supportare un gran numero di applicazioni, TelegraphCQ mette a disposizione dell’operatore un complesso sistema di gestione delle finestre capace di operare sia su dati che sono gi´a arrivati che su quelli che ancora devono arrivare dallo stream:

• Landmark queries: Il puntatore di coda rimane fisso mentre quello di punta si sposta in avanti all’arrivo delle nuove tuple dallo stream.

• Sliding queries: Le query a scorrimento fanno spostare contemporanea-mente i limiti della finestra appena sono disponibili nuovi dati dallo stream. • Loop WindowIs: Questo particolare costrutto permette agli operatori di personalizzare la gestione delle finestre all’interno delle query. Si usa insieme al costrutto for-loop.

In particolare, una funzionalit`a interessante di TelegraphCQ `e la possibilit`a di gestire contemporaneamente pi`u notazioni temporali, sia logiche (ad esempio l’ordine di arrivo delle tuple) che fisiche (ad esempio il timestamp). Il tempo `e visto come un ordinamento non totale ma parziale ed il sistema offre primitive per passare da un sistema temporale all’altro tramite un’apposita algebra che estende gli operatori relazionali standard.