Tecniche di caching per migliorare l'ecienza dei sistemi P2P di Web Search. Laureando: Elia Gaglio (matricola n )

Transcript

1 Tecniche di caching per migliorare l'ecienza dei sistemi P2P di Web Search Laureando: Elia Gaglio (matricola n ) 19/10/2007

2 Indice 1 Introduzione 6 2 Tecniche di Web Searching Lo scenario del WWW oggi Strutture di indicizzazione per WSE Tecniche di ranking per WSE Modello vettoriale di ricerca Modello booleano di ricerca Modello probabilistico di ricerca Architetture emergenti per WSE distribuiti WSE distribuiti Gli approcci Term Partitioning e Document Partitioning Sistemi P2P - caratteristiche, pregi e difetti Sistemi P2P - caratteristiche architetturali P2P Web Searching P2P WSE: approccio Term Partitioning Come risolvere il problema dello sbilanciamento del carico Una stima degli indicatori di Searching Term Assignment Problem Possibili politiche di caching Distributed Cache Table (DCT) View Tree: una struttura dati eciente per il Web Caching Tecniche di ottimizzazione dell'intersezione di liste invertite Fagin's Algorithm (FA) Simple Algorithm (SA) Distributed Threshold Algorithm Filtri di Bloom Bloom Circle Threshold Algorithm La tecnica dei risultati incrementali

3 INDICE 2 5 P2P WSE: approccio Document Partitioning Possibili politiche di caching Two-Level Caching for Scalable Search Engines Weighted Caching Three-Level Caching for Scalable Search Engines DiCAS Caching Mechanism Distributed Caching based on Query Similarity MINERVA: un WSE P2P basato su Document Partitioning La struttura DHT di MINERVA Valutazione di una query multiterm in MINERVA Query routing in MINERVA Collection Selection in ambito P2P CORI Collection Selection Improving Collection Selection with Overlap Awareness Analisi delle correlazioni esistenti tra query term in MINERVA La fase di Peer Selection Tecniche di caching per il WSE MINERVA La struttura di MINERVA Esecuzione di una query multiterm in MINERVA Strategie di caching per WSE Il progetto Static Dynamic Cache Politiche di prefetching adattivo in Static Dynamic Cache Risultati e possibili sviluppi futuri del progetto Static Dynamic Cache Il progetto Admission Policies Una nuova tecnica di caching per MINERVA Sistema di caching SDC-P2P La cache locale di SDC-P2P La cache globale di SDC-P2P Cache Overlay Network Query Log Analysis per SDC-P2P Esecuzione di una query utente Esecuzione di una PeerList Request Cancellazione di dati nel sistema di caching Sistema di caching ADM-P2P La cache locale di ADM-P2P

4 INDICE La cache globale di ADM-P2P Admission Policies per ADM-P2P Valutazione e confronto dei due sistemi di caching Prove sperimentali Query Log Analysis Principi e fondamenti Query Log Analysis: un processo a 3 step Analisi del log di Excite Caratteristiche dei sistemi testati Sistema SDC-P2P-lq Sistema ADM-P2P-lq Sistema ADM-P2P-lq-gt-gq Sistema ADM-P2P-lq-lt-gq Sistema ADM-P2P-lq-lc-gq Dettagli implementativi Distribuzione delle entry hash tra i peer Valutazione delle prestazioni I test condotti Sistema SDC-P2P-lq VS. Sistema ADM-P2P-lq I risultati ottenuti Osservazioni sui risultati ottenuti Sistema SDC-P2P-lq VS. Sistema ADM-P2P-lq-gt-gq I risultati ottentuti Osservazioni sui risultati ottenuti Sistema SDC-P2P-lq VS. Sistema ADM-P2P-lq-lt-gq I risultati ottentuti Osservazioni sui risultati ottenuti Sistema SDC-P2P-lq VS. Sistema ADM-P2P-lq-lc-gq I risultati ottentuti Osservazioni sui risultati ottenuti ADM-P2P-lq-gt-gq VS. ADM-P2P-lq-lt-gq VS. ADM-P2Plq-lc-gq I risultati ottenuti Osservazioni sui risultati ottenuti Bilanciamento del carico tra i peer della rete Una soluzione per i sistemi di caching introdotti I test condotti

5 INDICE Sistema ADM-P2P-lq-lc-gq VS. Sistema ADM- P2P-lq-lc-gq con modulo di bilanciamento del carico Sistema SDC-P2P-lq VS. Sistema SDC-P2P-lq con modulo di bilanciamento del carico Conclusioni Obiettivi e risultati raggiunti Possibili sviluppi futuri

6 Abstract L'obiettivo di questa tesi è quello di studiare le caratteristiche dei WSE P2P, in particolare a riguardo delle strutture di Web Caching cooperativo che sono state presentate di recente. In questo modo è possibile avere una panoramica delle diverse soluzioni proposte, utile per la successiva progettazione di un eciente sistema di Web Caching per MINERVA, un WSE P2P basato sull'approccio document partitioning. A riguardo si sfrutteranno due strategie di caching che hanno fornito buone prestazioni nella realizzazione di una cache centralizzata, che intercetti le richieste in arrivo al WSE: Static Dynamic Cache e Admission Policies, il quale rappresenta una generalizzazione del primo approccio, che garantisce delle prestazioni migliori e una gestione apparentemente più semplice. Mediante l'utilizzo di un query log reale si è quindi realizzata una piattaforma di test distribuita e P2P, utile per individuare la struttura di caching ottimale (sia in termini architetturali, che di Web Log Analysis su cui si poggia). Inoltre è stato possibile eettuare uno studio di applicabilità dei due approcci in ambito P2P e trovare una congurazione di caching basata sulla politica Admission Policies che garantisca prestazioni migliori rispetto Static Dynamic Cache, in modo da confermare tale tendenza anche in uno scenario P2P. Oltre alla raccolta e alla stima degli indici prestazionali classici (hit ratio, numero messaggi scambiati tra le componenti, ecc.) si è anche deciso di considerare il problema del bilanciamento del carico tra i nodi della rete. La soluzione in merito proposta è basata sulla realizzazione di un modulo software completamente distribuito, basato su un protocollo di comunicazione che permetta a ciascun peer di rilevare una situazione di sbilanciamento del proprio carico. Una procedura adattiva, attuata in seguito alla rilevazione di una situazione di sbilanciamento, comporta l'invio di burst di query da un peer saturo verso altri peer più scarichi. Le prove sperimentali eettuate hanno dimostrato l'ecacia del modulo progettato e la sua applicabilità ad un sistema di caching basato sia sull'approccio SDC che su Admission Policies. 5

7 Capitolo 1 Introduzione Negli ultimi anni si è assistito ad una crescita esponenziale di Internet, che ha portato alla ribalta l'utilizzo dei motori di ricerca (Web Search Engine o WSE) come strumento per trovare in modo facile e preciso delle informazioni attraverso la rete. La progettazione di WSE ecienti è un'attività che abbraccia diversi settori dell'informatica, come l'high Performance Computing, il Data Mining, l'information Retrieval, ecc. e che ha come obiettivo la possibilità di soddisfare in modo esauriente le richieste informative degli utenti, cercando di ottimizzare le risorse a disposizione (sia in termini di banda, di messaggi scambiati tra nodi della rete e accessi ai dispositivi di I/O). Un esempio di tecnica che permette di migliorare l'ecienza dei WSE si basa sull'utilizzo di memorie cache, che possono fornire in modo immediato query result, riferimenti, ecc. utili per velocizzare i tempi di risposta e minimizzare l'occupazione di banda. Con una cache è possibile infatti limitare eventuali operazioni costose, come la ricerca attraverso gli indici disponibili, o un eccessivo scambio di messaggi attraverso i nodi coinvolti nella ricerca, rendendo quindi il WSE più scalabile e performante. Recentemente la ricerca si è indirizzata sullo sviluppo di tecniche di caching che sfruttano le query log analysis (le analisi dei query log dei WSE), con l'obiettivo di migliorare la qualità dei dati memorizzati e conseguentemente dell'intero sistema di caching implementato. I query log infatti memorizzano le informazioni sulla navigazione degli utenti, registrando le query formulate, oltre ad altre informazioni accessorie quali data ed ora della richiesta, sessione di provenienza, userid univoco assegnato a ciascun utente, ecc. Sfruttando delle tecniche di Data Mining è chiaro come si possa estrarre conoscenza dai query log, potendo derivare interessanti tendenze e pattern ricorrenti presenti all'interno. Ad esempio, mediante delle analisi sulle query maggiormente frequenti è possibile individuare quali siano le interrogazioni che verranno richieste con maggior probabilità dagli utenti nel futuro. Tali informazioni possono essere 6

8 CAPITOLO 1. INTRODUZIONE 7 utilizzate come base per ottimizzare la fase di popolazione delle memorie cache e per limitare i costi di ricerca per la risposta ad una query. Parallelamente allo sviluppo del Web si è assistito alla recente diusione del paradigma Peer to Peer (P2P) in Internet. Ciò è stato dovuto per lo più all'introduzione delle popolarissime applicazioni di le sharing e ai sistemi di telefonia P2P. L'idea di un approccio P2P si basa fondamentalmente su una rete di nodi paritari, denominati peer, che condividono risorse e cooperano per uno scopo preciso. La mancanza di componenti centralizzate e l'approccio collaborativo tra i nodi della rete sono i punti di forza dei sistemi P2P, tanto da far diventare tale architettura una tra le più popolari e in fase di sviluppo nel Web moderno. Tutti questi fattori hanno recentemente indirizzato la ricerca verso la progettazione di moderni WSE basati sull'approccio P2P, nei quali è presente una rete di peer che coopera e condivide i propri indici a disposizione, con l'obiettivo di migliorare le ricerche di le e documenti in rete. Non è da sorprendersi se l'approccio P2P stia diventando sempre più popolare nella costruzione dei WSE; ciò è plausibile per diversi motivi, tra i quali: 1. i dati presenti nel Web sono altamente distribuiti e risiedono in milioni di siti diversi; 2. una rete P2P risulta essere l'aggregazione di diverse entità cooperanti, le quali formano un sistema che possiede grosse potenzialità in termini di risorse ed ore la possibilità di eettuare analisi complesse sul data set disponibile; 3. l'approccio P2P si basa su un'idea di "uguaglianza" tra i peer della rete, dove non vi è nessuna componente centralizzata che gestisca eventuali computazioni o decisioni da eettuare, riducendo quindi le possibilità di colli di bottiglia o punti critici nella rete. Partendo da questi punti di forza sono stati recentemente proposti diversi WSE P2P. Un esempio viene da MINERVA, un prototipo di WSE P2P realizzato a livello accademico [2], [3], [4] e che si contraddistingue per i buoni risultati che fornisce in fase di searching. L'idea di fondo di MINERVA è di poter sfruttare in modo oculato le informazioni sulle correlazioni che intercorrono tra i query term, in modo da evitare dei processi di fattorizzazione della query, che portano ad ottenere dei risultati molto più scadenti e poco precisi. Ad esempio, se si formulasse una query come "Laurea Specialistica", un WSE standard userebbe un approccio classico di scomposizione della query e di ricerca dei peers potenzialmente più utili (best peer), per ciascun query term. La succesiva fase prevederebbe quindi un'intersezione delle diverse liste di peer individuate, al ne di

9 CAPITOLO 1. INTRODUZIONE 8 produrre una lista nale a cui inviare l'intera query. MINERVA invece ha come obiettivo principale quello di introdurre un approccio di Collection Selection in ambito P2P: sfruttando le informazioni sulla correlazione che intercorre tra i query term, ottenute mediante l'analisi dei query log, o sfruttando dizionari o thesauri, è possibile avere un metodo per indirizzare la query ad un numero ristretto di nodi, in grado di fornire la maggior parte dei risultati più rilevanti. In questo modo si fornirebbero perciò dei query result più precisi, rendendo il WSE maggiormente eciente e scalabile. Anche nel campo dei WSE P2P si studiano delle tecniche che permettano di migliorare l'ecienza di tali componenti Web. In particolare, la ricerca si è indirizzata sullo studio di tecniche che portino ad una minimizzazione delle risorse impiegate per le fasi di ricerca, introducendo delle soluzioni che permettano di migliorare le fasi di intersezione delle liste invertite accedute o sfruttando delle politiche di caching apposite. Proporio a riguardo del caching sono stati proposti diversi spunti di ricerca interessanti, nei quali si sfruttano tecniche e approcci dierenti, spaziando tra i settori dell'information Retrieval e del Data Mining. Infatti, anche in ambito P2P si utilizzano le tecniche di mining per estrarre conoscenza dai query log, sfruttando in seguito delle tecniche di gossiping o delle directory distribuite per scambiare le informazioni acquisite da tali analisi. All'interno del WSE MINERVA si utilizza una forma di caching, che prevede la memorizzazione di PeerList (ovvero di liste di riferimenti a peer della rete), che permettono di localizzare i peer potenzialmente utili a riguardo di una certa query o di un insieme di query term. Sfruttando queste liste si potranno infatti contattare quei peer che, con più alta probabilità, mantengono nel proprio indice i riferimenti ai documenti più rilevanti rispetto alla query, limitando perciò il numero di peer da contattare in fase di risposta. Questa forma di caching memorizza solamente puntatori a peer e si appoggia sull'utilizzo delle informazioni sulle correlazioni dei termini presenti. Sfruttando una directory distribuita con struttura DHT (Distributed Hash Table) è possibile infatti distribuire tali PeerList attraverso i diversi nodi presenti e fornire un metodo di ricerca di tali liste semplice e poco costoso. Una critica che può però essere mossa contro questa prima tecnica di caching per MINERVA deriva dal fatto che la memorizzazione di una PeerList non elimina i costi dovuti agli accessi agli indici dei peer riferiti. Infatti, una volta ottenuta tale lista, si dovrà inviare la query, o sottoinsiemi di query term ai peer puntati, i quali eettueranno delle ricerche nel proprio indice. Sarebbe perciò interessante poter aancare alla prima tecnica di caching per MINERVA un ulteriore livello di caching, che però preveda la memorizzazione dei risultati delle query, ovvero dei primi top k documenti che risultano rilevanti

10 CAPITOLO 1. INTRODUZIONE 9 rispetto alla query, secondo un certo sistema di ranking. In questo modo si eviterebbero le fasi di accesso agli indici dei peer, dato che in caso di hit si disporrebbe di una pagina di risultati da proporre immediatamente in output all'utente. Partendo da questa idea è stato perciò progettato un sistema di caching, composto dalle seguenti componenti: ˆ cache locale a ciascun peer, per poter rispondere in modo immediato alle query con risultati provenienti dall'indice del peer contattato; ˆ cache globale distribuita, che permetta la memorizzazione di query result globali, ovvero costruiti mediante gli indici di diversi peer della rete e quindi utile per fornire risultati maggiormente precisi ad una query i cui query result precedentemente proposti erano stati valutati con feedback negativo dall'utente; ˆ struttura DHT, che permetta di costruire un overlay network che connetta le diverse porzioni di cache globale e garantisca un meccanismo di localizzazione dei query result globali per una certa query. In questo modo si potrà costruire un sistema di caching che ottimizzi l'intero schema di esecuzione di una query in MINERVA, rendendo maggiormente ef- ciente il WSE. In modo più specico, dal sistema di caching proposto ci si aspetta che siano rispettate determinate caratteristiche, quali: ˆ minimizzazione degli accessi a DHT: in questo modo sarà possibile ridurre i costi per gli accessi a DHT e i conseguenti messaggi scambiati tra i peer coinvolti e la struttura DHT, diminuendo perciò le comunicazioni complessive. Verranno quindi introdotte delle apposite tecniche di popolazione del sistema di caching, con l'obiettivo di diminuire gli accessi a DHT; ˆ massimizzazione degli hit ratio complessivi; ˆ massimizzazione degli hit in cache locale: mediante apposite query log analysis si cercherà di aumentare i livelli di hit in cache locale, al ne di poter rispondere ad un numero elevato di query mediante la cache locale al peer, senza dover perciò accedere all'indice locale ed eventualmente alla cache globale distribuita; ˆ blanciamento del carico attraverso i peer della rete: si cercheranno di evitare scenari in cui vi siano peer con un numero eccessivo di query da eseguire. Perciò si studieranno delle apposite politiche di rilevazione e di bilanciamento del carico in ambito P2P, che permettano di risolvere tale problematica.

11 CAPITOLO 1. INTRODUZIONE 10 La realizzazione del sistema di caching per MINERVA ha previsto una prima fase di studio delle moderne tecniche che permettono di migliorare l'ecienza dei sistemi di Web Search distribuiti e P2P. Da tale fase del lavoro sono emersi due progetti di ricerca particolarmente interessanti, che introducono delle strategie di gestione di una cache centralizzata di query result, che intercetti le richieste in arrivo al WSE. L'obiettivo di entrambi i lavori è quello di ottenere prestazioni migliori rispetto un sistema di cache che sfrutti un approccio LRU (Least Recently Used) classico. Infatti, LRU utilizza solo statistiche dinamiche rispetto alla freschezza dei riferimenti, come base per attuare le politiche di sostituzione dei blocchi in cache. Entrambi i lavori di ricerca presuppongono perciò l'impiego delle query log analysis, come tecnica utile per la popolazione delle memorie cache. In particolare, il primo progetto, denominato Static Dynamic Cache (SDC), prevede la realizzazione di una cache suddivisa in due porzioni: una porzione statica read-only, usata per memorizzare le query più frequenti e una seconda porzione dinamica basata su una politica di replacement (che può essere LRU, LRU/2, ecc.) utile per la memorizzazione delle rimanenti query. Il secondo progetto (denominato Admission Policies) rappresenta invece una generalizzazione di SDC, nel quale è stata eettuata la costruzione di un sistema di caching completamente dinamico, che sfrutta uno stimatore per la gestione delle query da memorizzare. In questo modo si eviterà l'inserimento in cache di query poco frequenti, che possono portare ad una fase di pollution della cache e, al contrario di SDC, non si ha il vincolo di utilizzare una porzione statica per la memorizzazione delle query più frequenti. Le migliori prestazioni fornite e l'apparente gestione più semplice hanno portato, nelle prove condotte in [23], Admission Policies ad essere una soluzione più vantaggiosa di SDC. Riprendendo il sistema di caching proposto per MINERVA si è perciò deciso di puntare sulle strategie SDC e Admission Policies, realizzando diverse istanze del sistema di caching, che dieriscono per le query log analysis eettuate e per la strategia di caching impiegata. Gli obiettivi che si vogliono ottenere in questo modo sono molteplici: ˆ poter valutare l'ecacia del sistema di caching in ambito P2P; ˆ poter valutare l'applicabilità degli approcci SDC e ADM in ambito P2P, dato che nei lavori di ricerca [8] e [23] si utilizzavano tali strategie per gestire una cache posizionata in un server centralizzato, che interfacciava gli utenti e intercettasse le richieste al WSE in arrivo dagli utenti; ˆ valutare se le tendenze osservate nel lavoro [23], secondo le quali l'approccio Admission Policies è più conveniente di SDC, sono rispettate anche in ambito P2P;

12 CAPITOLO 1. INTRODUZIONE 11 ˆ costruire diverse istanze del sistema di caching, che sfruttino query log analysis dierenti, in modo da trovare la congurazione che fornisce le prestazioni migliori (in termini di hit ratio, numero messaggi scambiati, ecc.). L'obiettivo principale di questa tesi resta quello di studiare ulteriormente le politiche di caching per WSE P2P. Per testare la bontà delle tecniche di caching introdotte si costruirà una piattaforma di test distribuita e P2P, nella quale si utilizzerà un query log reale per riempire opportunamente le memorie cache (in modo da mantenere sempre le stesse condizioni iniziali per ciascuna prova eseguita) e per poter eettuare l'esecuzione di un usso di query, al ne di valutare le prestazioni del sistema trattato. Questo lavoro di tesi è organizzato come segue. Nei capitoli 2 e 3 verranno presentate le caratteristiche dei moderni WSE e dei sistemi P2P per Web Searching. In questo modo si fornirano le componenti fondamentali di un WSE, passando poi a valutare le caratteristiche delle reti P2P e dei WSE P2P. Nel capitolo 4 si illustreranno le caratteristiche salienti e le moderne tecniche di caching e di ottimizzazione delle fasi di ricerca per i WSE che seguono l'approccio term partitioning, mentre nel successivo capitolo 5 si farà lo stesso per i WSE basati sull'approccio document partitioning. Eettuando tale suddivisione si potranno introdurre i lavori recenti più interessanti, focalizzando l'attenzione sulle tecniche di caching come componente essenziale per la progettazione di WSE ecienti. Nel capitolo 6 si presenteranno in dettaglio le caratteristiche del WSE MIN- ERVA, per poi passare nel capitolo 7 a descrivere il nuovo sistema di caching progettato per tale WSE. Verranno perciò illustrate in dettaglio le diverse componenti coinvolte e si eettuerà una distinzione tra un primo sistema di caching basato su SDC e un secondo basato sull'approccio Admission Policies. Nel capitolo 8 si presenteranno le caratteristiche delle diverse istanze del sistema di caching progettato (suddivise in base all'approccio SDC o Admission Policies), descrivendo nel dettaglio le query log analysis utilizzate, in modo da rendere chiare le successive prove eettuate sulla piattaforma di test, illustrate nel capitolo 9. A riguardo, si proporanno gli obiettivi, i risultati e le conclusioni ottenute per ciascun test eseguito. Inoltre, si studierà in modo esplicito il problema del bilanciamento del carico, illustrando la soluzione proposta e riportando i test eseguiti in merito. Inne, nel capitolo 10 si concluderà il lavoro presentando gli obiettivi raggiunti e i possibili sviluppi futuri del lavoro realizzato.

13 Capitolo 2 Tecniche di Web Searching 2.1 Lo scenario del WWW oggi Negli ultimi anni si è assistito ad una crescita enorme delle dimensioni del Web. Dalle poche centinaia di web server disponibili nel 1994, oggi giorno si sono raggiunti valori pari a diversi miliardi e tale crescita sembra non destinata a fermarsi mai. Tenendo conto del fatto che ciascuna pagina web ha una dimensione media sull'ordine dei 10 KB, è facile capire come il web sia diventato un "raccoglitore di dati con dimensioni pari a qualche centinaio di terabyte. In questo scenario i motori di ricerca (Web Search Engine, o brevemente WSE) sono diventati uno strumento imprescindibile che permette la ricerca di documenti all'interno di Internet. In particolare, viste le dimensioni del data set su cui si lavora, risulta necessario disporre di motori di ricerca ecienti, in grado di trovare le risposte più vicine alle esigenze dell'utente che formula la query di ricerca. Partendo da queste idee, sono stati proposti nel corso degli ultimi anni moltissimi lavori di ricerca, i quali abbracciano dierenti settori dell'information Technology, quali l'information Retrieval, il Data Mining, l'high Performance Computing, ecc. 2.2 Strutture di indicizzazione per WSE Dato lo sviluppo dei WSE e dei documenti indicizzati nel Web, è necessario prevedere delle apposite tecniche di indicizzazione dei documenti disponibili. In questo modo si cerca di velocizzare le fasi di ricerca dei documenti, ottimizzando il processo di esecuzione di una query e di estrazione dei risultati utili per soddisfare l'interrogazione formulata dall'utente. Per organizzare l'informazione disponibile nei WSE si sfrutta una struttura dati denominata lista invertita, 12

14 CAPITOLO 2. TECNICHE DI WEB SEARCHING 13 che permette di gestire in modo eciente lo spazio e di ottimizzare le ricerche mediante la costruzione di un indice a liste invertite. Un indice a liste invertite è costituito da due componenti: il dizionario (lexicon) e un posting le, dove sono memorizzate le diverse posting list. Il dizionario contiene, per ogni termine presente nella collezione di documenti, un puntatore ad una posting list memorizzata nel posting le. Ciascuna posting list contiene, per ogni elemento, l'identicatore univoco del documento (DocID), oltre alla posizione nel documento di ogni occorrenza del termine. Inoltre è possibile memorizzare altri metadati, come la frequenza del termine nel documento. La fase di costruzione di un indice a liste invertite prevede un primo processo di analisi dei documenti disponibili, in modo da poter estrarre i termini presenti all'interno. In particolare, se il termine t è già presente nel dizionario, verrà aggiunto un nodo alla lista corrispondente nel posting le; nel caso in cui il termine t non sia già stato precedentemente trovato, viene inserito un riferimento a t nel dizionario e creato un nuovo nodo nel posting le. Una volta completata tale analisi sarà perciò possibile ordinare tutti i termini in modo lessicograco ed ottenere quindi un indice a liste invertite, avente la struttura riportata in gura 1: Figura 1: Struttura di un indice a liste invertite 2.3 Tecniche di ranking per WSE Proseguendo la panoramica nei WSE moderni, è interessante osservare come la progettazione di un motore di ricerca web sia un'attività che abbraccia di-

15 CAPITOLO 2. TECNICHE DI WEB SEARCHING 14 versi settori di ricerca nel campo dell'informatica. Ciò deriva dal fatto che l'insieme dei sotto-task da implementare nella fase di search, sfruttano tecniche e metodologie riconducibili a diverse aree dell'informatica moderna. Ad esempio, uno degli obiettivi più importanti da considerare nel momento in cui si progetta un motore di ricerca riguarda l'individuazione di un'eciente funzione di ranking, il cui obiettivo è quello di identicare i risultati più vicini al fabbisogno informativo dell'utente (i cosiddetti top rank result), dall'intera collezione di documenti disponibile. L'insieme delle politiche di ranking che sono state proposte nel corso degli anni si basano su regole e modelli tipiche del settore dell'information Retrieval (IR), tanto da considerare l'ir come il settore chiave per la costruzione di sistemi di ricerca web. Si può infatti pensare ad un WSE come ad un corrispettivo Web di un sistema di Information Retrieval. L'Information Retrieval è quella scienza che si occupa di rappresentare, memorizzare, organizzare e recuperare gruppi di informazioni presenti all'interno di un insieme di documenti. In particolare, ciascun utente è interessato all'individuazione di tutti e solo quei documenti che sono considerati rilevante rispetto una data richiesta informativa. Da qui è chiaro come il concetto di rilevanza sia la caratteristica chiave per un sistema di IR: un certo documento non può essere considerato buono o cattivo, bensì dovrà essere valutata la sua rilevanza rispetto la richiesta informativa dell'utente. Per poter costruire un sistema di retrieving eciente è necessario che ciascun documento indicizzato sia rappresentato da un insieme di termini che lo rappresentano. In pratica, le keywords associabili a ciascun documento sono dei surrogati del documento stesso e l'obiettivo di un sistema di Information Retrieval è quello di trovare delle informazioni signicative per un utente che eettua una ricerca mediante il sistema. Operando in un contesto web è inoltre necessario esprimere in modo strutturato la richiesta informativa, in modo che un WSE possa in seguito valutarla e costruire un insieme di risposte associabili. Per ottenere questo obiettivo si utilizzano le query utente, le quali permettono di modellare ciò che l'utente vuole ottenere quando interroga un WSE. Una componente fondamentale per un sistema di Information Retrieval (IR) è l'introduzione di un modello di ricerca, ovvero un modello che permetta di rappresentare i documenti, le query e le relazioni che intercorrono tra essi. I modelli di ricerca introdotti nel campo dell'ir stanno alla base anche dei moderni metodi di ranking utilizzati nei WSE. Infatti, per la valutazione del match di un insieme di documenti rispetto una certa query utente, si sfruttano usualmente i principi introdotti dai diversi modelli di ricerca. Nei prossimi paragra verrà proposta un'analisi delle caratteristiche dei tre principali modelli di ricerca, valutandone anche pregi e difetti correlati, al ne di valutare quali sono i candidati ad essere utilizzati nelle tecniche di ranking

16 CAPITOLO 2. TECNICHE DI WEB SEARCHING 15 dei moderni WSE Modello vettoriale di ricerca Assumendo che ciascuna query sia formata da un insieme di termini (detti query term), il modo più semplice per gestire la fase di ranking è basato su un confronto dei termini contenuti in un documento e nella query utente. Più formalmente, utilizzando un modello vettoriale di ricerca, i documenti sono modellati come "contenitori di parole" e una funzione di ranking assegna un punteggio a ciascun documento rispetto ad una query, basandosi sulla frequenza di ciascun query term nella pagina e nell'intera collezione, sulla lunghezza del documento e sul contesto in cui esso occorre (ad esempio, un query term presente nel titolo ha associato un alto peso). Più formalmente, è possibile pensare la collezione di documenti come una matrice le cui righe sono i documenti, le colonne sono i termini e un generico elemento Xij rappresenta una misura della rilevanza del termine j-esimo nel documento i-esimo. L'approccio più comune per la valutazione della rilevanza dei termini è chiamato (term frequency * inverse document frequency): mediante l'indicatore tf (term frequency) si tiene traccia di quanto un termine compare in un documento, mentre con la grandezza idf (inverse document frequency) si discrimina sulla base di quanto un termine appare in un'intera collezione di documenti (più appare, meno viene considerato rilevante). Secondo il modello vettoriale di ricerca è possibile anche inferire circa la somiglianza tra due documenti (presumibilmente un documento e la query). Infatti, è possibile introdurre un'apposita formula per la valutazione della distanza tra vettori (es. vettore a e vettore b), i quali permettono di rappresentare i pesi dei termini che descrivono i due documenti: D(a, b) = k ai bi 2 Inoltre è possibile sfruttare una formula che permetta di valutare la correlazione che intercorre tra due vettori (riprendendo la formula sopra, si utilizzano due generici vettori a e b), sfruttando il valore del coseno tra i loro angoli: ( k i:1 (ai bi)) S(a, b) = k ( i:1 ai2 bi 2 ) i:1 L'introduzione di un modello vettoriale di ricerca porta a diversi vantaggi, quali la possibilità di eettuare delle clusterizzazioni dei documenti, oltre alla possibilità di sfruttare la formula per il calcolo della similarità per ordinare i

17 CAPITOLO 2. TECNICHE DI WEB SEARCHING 16 risultati proposti, rispetto il grado di similarità con la query formulata. Proprio quest'ultima caratteristica permette di sfruttare le caratteristiche del modello vettoriale all'interno di una procedura di ranking per un WSE Modello booleano di ricerca Il modello booleano di ricerca è legato strettamente alla teoria degli insiemi, infatti esso si basa sull'utilizzo dell'insieme degli operatori logici classici, insieme alle operazioni insiemistiche associate. Seguendo l'approccio introdotto da questo modello a ciascun documento viene associato un valore relativo ad un dominio di due elementi (0, oppure 1). Il valore 0 indica che il documento non è considerato rilevante, mentre il valore 1 permette di concludere che il documento è rilevante. Il modello booleano di ricerca permette diversi tipi di ricerche, come: ˆ ricerche con operatori booleani : è possibile costruire delle interrogazioni q sfruttando i diversi operatori booleani e le operazioni insiemistiche associate; ˆ ricerche per adiacenza e posizione ; ˆ indicazioni di rilevanza e frequenza dei termini. Una caratteristica positiva del modello booleano di ricerca è la sua semplicità in fase di retrieving e nella fase di costruzione delle query (è suciente far uso di insiemi di operatori booleani per costruire delle espressioni booleane con i termini). D'altro canto questa semplicità si ripercuote negativamente sui risultati che un sistema basato su tale modello fornisce. Infatti si possono vericare molto spesso casi in cui i risultati ritornati siano troppi, oppure troppo pochi, ma in particolare non è possibile costruire un ordinamento parziale sui risultati proposti, rendendo quindi impraticabile un'eventuale procedura di ranking Modello probabilistico di ricerca Il modello probabilistico di ricerca si basa su una stima della probabilità di rilevanza di una collezione di documenti rispetto alla query utente. Tale modello si basa su un'ipotesi iniziale secondo la quale la presenza di un query term all'interno di un documento è un'indicazione a favore della rilevanza di tale documento. Inoltre deve essere eettuata una fase di training, nella quale il sistema di Information Retrieval sfrutta dei feedback (informazioni sulla qualità dei risultati forniti) da parte dell'utente. In questo modo è possibile innescare un meccanismo iterativo, secondo il quale vengono forniti dei risultati all'utente

18 CAPITOLO 2. TECNICHE DI WEB SEARCHING 17 e sulla base delle sue valutazioni, si rana la descrizione dell'insieme ideale per una certa query. La miglior ecacia di retrieval si raggiunge quando i documenti sono classicati in ordine decrescente rispetto alla probabilità di rilevanza. Detto d l'insieme delle rappresentazioni dei documenti, si denisce uno spazio degli eventi e l'obiettivo è quello di determinare le rappresentazioni dei documenti rilevanti, cioè stimare la probabilità di rilevanza P(R d). I vantaggi che scaturiscono dall'introduzione di un modello di ricerca probabilistico derivano dal fatto che i documenti presentati sono ordinati in modo decrescente di probabilità di rilevanza, rendendo quindi le caratteristiche chiavi di questo approccio utilizzabili all'interno di una funzione di ranking. Allo stesso tempo, però, esiste un palese svantaggio dovuto al fatto che è necessario eettuare una prima stima a priori della probabilità di rilevanza.

19 Capitolo 3 Architetture emergenti per WSE distribuiti 3.1 WSE distribuiti Nello scenario in cui i WSE moderni operano, la scalabilità e le prestazioni sono diventate delle caratteristiche di fondamentale importanza. In un ambiente in cui il numero di documenti da indicizzare aumenta costantemente, l'introduzione di tecniche di parallelizzazione e distribuzione dei dati e del lavoro sono diventate delle caratteristiche chiave nella progettazione dei WSE. Ecco quindi che le architetture moderne prevedono una ripartizione dell'indice attraverso cluster di macchine, comunicanti mediante una rete, dove è presente una macchina che funziona da broker. Tale componente ha il compito di schedulare le query verso i diversi servers e di eettuare la raccolta dei risultati producendo, eventualmente, il result set da proporre all'utente come risposta alla query che egli aveva formulato. In gura 2 è possibile osservare una rappresentazione schematica di un tipico motore di ricerca parallelo con K servers: Figura 2: Architettura di un WSE parallelo 18

20 CAPITOLO 3. ARCHITETTURE EMERGENTI PER WSE DISTRIBUITI 19 Come è possibile osservare dalla gura 2, la fase di search viene ripartita dal broker verso i diversi IR Core, i quali poi ritorneranno un insieme di risultati parziali per la ricerca. La composizione di tali risultati, verso un'unica risposta nale, verrà eettuata dal broker stesso. Un approccio distribuito per la progettazione dei WSE garantisce dei buoni livelli di scalabilità, oltre ad un insieme di caratteristiche che un ambiente centralizzato non potrebbe fornire. Tra esse si possono citare la maggior tolleranza ai guasti, la possibilità di ripartire e bilanciare il carico attraverso i nodi della rete. Inoltre, è possibile pensare di utilizzare degli approcci di tipo Peer to Peer (P2P), in cui un insieme di nodi paritari (Peer) collaborano e scambiano informazioni in modo oculato. Questo concetto risulta essere particolarmente interessante se collocato nel settore del Web Searching, vista l'idea di condivisione di informazioni (memorizzate negli indici a liste invertite) tra nodi, utilizzate per rispondere ad interrogazioni degli utenti. Nei prossimi paragra verrà eettuata una panoramica sulle principali caratteristiche di un sistema P2P, per poi soermarsi sui sistemi di Web Searching in ambito P2P, settore nel quale è possibile collocare il WSE MINERVA che sarà oggetto di diversi studi e valutazioni nel corso del lavoro. Prima di tutto, però, è utile introdurre gli approcci document partitioning e term partitioning, che permettono di eettuare una classicazione dei WSE in base alla ripartizione dell'indice a liste invertite attraverso i nodi della rete. 3.2 Gli approcci Term Partitioning e Document Partitioning Il volume di dati su cui ciascun WSE moderno opera risulta essere enorme. Sono quindi sfruttate in modo massiccio delle tecniche di parallelizzazione dell'intero task di ricerca, che permettano delle suddivisioni del carico attraverso i diversi nodi disponibili per la computazione. Naturalmente partendo da quest'idea sono state proposte diverse tipologie di WSE, le quali propongono soluzioni e tecnologie dierenti tra loro e nelle quali la suddivisione del lavoro tra le macchine disponibili è diventata una prerogativa indispensabile. Per comprendere in modo più chiaro il contesto in cui collocare i diversi spunti di ricerca che verranno analizzati in seguito, è utile introdurre un primo criterio di suddivisione applicabile ai WSE: prendendo come fattore discriminante la ripartizione dell'indice a liste invertite attraverso i nodi della rete, è possibile catalogare i seguenti due approcci: ˆ document partitioning (o local partitioning): in questo approccio l'idea alla base è quella di poter eettuare una partizione del le invertito in

21 CAPITOLO 3. ARCHITETTURE EMERGENTI PER WSE DISTRIBUITI 20 diversi sotto-le, secondo la suddivisione sica dei documenti del data set a disposizione. In questo modo ciascun nodo sarà responsabile di un sottoinsieme disgiunto dell'intera collezione di documenti. ˆ term partitioning (o global partitioning): seguendo quest'approccio, l'intera lista invertita di un termine presente nel dizionario, sarà memorizzata completamente in un nodo. Tale lista conterrà tutte le informazioni associate a quel termine e si seguirà questa tecnica di partizione per tutti i termini presenti nel dizionario. Se, ad esempio, lavorassimo con un cluster caratterizzato dalla presenza di 4 nodi e con la seguente collezione di documenti così memorizzata: Nodo1: d1 <a,b,a,c,d> Nodo2: d2 <a,d,e,a> Nodo3: d3 <b,c,a,b> Nodo4: d4 <b> un partizionamento basato sull'approccio document partitioning porterebbe al seguente risultato: Nodo1 : Nodo2 : Nodo3 : Nodo4 : a = (d1:1), (d1:3) b = (d1:2), (d1:5) a = (d2:2), (d2:4) d = (d2:2) e = (d2:3) a = (d3:3) c = (d3:2) b = (d3:1), (d3:4) b = (d4:1) mentre un partizionamento basato sull'approccio term partitioning, in cui si suppone di aver utilizzato un precedente assegnamento term nodo del tipo (a Nodo1, b Nodo2, c Nodo3, d Nodo4, e Nodo4), porta ad un risultato del tipo: Nodo1 : Nodo2 : Nodo3 : Nodo4 : a = (d1:1), (d1:3), (d2:1), (d2:4), (d3:3) b = (d1:2), (d1:5), (d3:1), (d3:4), (d4:1) c = (d1:4), (d3:2) d = (d2:2) e =(d2:3)

22 CAPITOLO 3. ARCHITETTURE EMERGENTI PER WSE DISTRIBUITI 21 La tecnica term partitioning porta ad una minimizzazione delle attività di I/O, riducendo le latenze dovute all'accesso ai dischi. D'altro canto, la gestione di un sistema che sfrutta quest'ultimo approccio risulta essere più complesso rispetto a quello document partitioning. Più in generale, la tecnica di partizione dei termini risulta conveniente in tutti quei casi in cui si riesca ad avere una distribuzione il più possibile uniforme degli index term e dei query term tra i nodi paralleli. Nel caso di distribuzioni non uniformi, quest'ultimo schema sore pesantemente il problema dello sbilanciamento del carico tra i nodi, rendendo più conveniente una tecnica di partizione dei documenti. Infatti, uno dei grossi svantaggi dell'approccio term partitioning risulta essere la possibilità di lavorare molto spesso con posting list enormi, che portano anche a possibili peggioramenti nelle prestazioni globali del sistema. Si possono quindi riassumere alcune delle principali caratteristiche dei due approcci seguendo lo schema di tabella 1: Term Partitioning Tutte le posting entry di un index term si trovano nello stesso nodo Minimizzazione delle attività di I/O Poiché la dimensione delle posting list degli index term varia in base alla frequenza delle occorrenze nella collezione, lo spazio di disco utilizzato può essere sbilanciato Document Partitioning Tutte le posting entry di un documento si trovano nello stesso nodo L'index le necessita di immagazzinare le informazioni riguardanti la localizzazione nel disco delle posting entry con gli index term. Pertanto è richiesto più spazio In generale approccio computazionalmente più semplice rispetto al term partitioning Tabella 1: Approcci term partitioning e document partitioning: proprietà 3.3 Sistemi P2P - caratteristiche, pregi e difetti I sistemi P2P sono giunti agli onori della cronaca in un recente passato: intorno alla ne degli anni '90 è diventato popolarissimo un primo sistema di le sharing per contenuti musicali, denominato Napster. Esso era basato su un'architettura di tipo P2P, ovvero una collezione di diverse entità con capacità simili alle altre entità nel sistema (denominati appunto peer). I sistemi P2P sono una classe di

23 CAPITOLO 3. ARCHITETTURE EMERGENTI PER WSE DISTRIBUITI 22 sistemi e applicazioni che utilizzano delle risorse distribuite (di calcolo, di memorizzazione, ecc.) per poter eseguire diverse funzionalità in modo distribuito. Ciascuna entità può avere funzioni sia da client che da server e il numero di nodi connessi può essere dell'ordine delle centinaia di migliaia di unità (costituendo quindi dei sistemi altamente distribuiti). Negli ultimi anni si è assistito ad un grosso sviluppo dei sistemi P2P, tanto che in recenti analisi è stato stimato che il 30% del traco Internet è riconducibile ad applicazioni P2P. Tali applicazioni spaziano dalla distribuzione e memorizzazione di contenuti (sicuramente sono le tipologie di applicazioni più famose e conosciute, vista la popolarità dei sistemi di le sharing), alla condivisione di risorse di calcolo, ai sistemi di basi di dati distribuite, ecc. In ogni caso, per le diverse tipologie di applicazioni P2P restano sempre gli stessi obiettivi di fondo, quali: 1. possibilità di sfruttare ecacemente le risorse disponibili; 2. aumentare la scalabilità del sistema; 3. aumentare la disponibilità di servizio; 4. consentire l'interoperabilità; E allo stesso tempo bisogna anche considerare i maggiori difetti che un sistema P2P introduce: 1. problemi di sicurezza; 2. eterogeneità tra i diversi peer; 3. alta instabilità nel sistema a causa di continue entrate/uscite dei peer nella rete; 3.4 Sistemi P2P - caratteristiche architetturali Dopo aver introdotto le principali caratteristiche di un sistema P2P, si passa ad analizzare le diverse architetture P2P esistenti, introducendone le caratteristiche peculiari: ˆ Architetture P2P decentralizzate pure : è la forma di architettura P2P più classica, dove ciascun nodo della rete è un peer che può avere sia funzionalità client che funzionalità server e non esiste nessun coordinatore centralizzato;

24 CAPITOLO 3. ARCHITETTURE EMERGENTI PER WSE DISTRIBUITI 23 ˆ Architetture P2P parzialmente centralizzate : in questo caso vi è la presenza di alcuni nodi che hanno la funzionalità di facilitare l'interconnessione tra diversi peer (tali nodi sono denominati sueprnodi). In pratica, un generico peer P1 che vuole connettersi ad un peer P2 interpellerà prima il supernodo (che ha una funzionalità da server) e in seguito potrà localizzare e quindi comunicare col peer stabilito, come riportato in gura 3: Figura 3: Architettura P2P parzialmente centralizzata ˆ Architetture P2P decentralizzate ibride : in questo caso vi è la presenza di una macchina server centralizzata che eettua la fase di localizzazione dei diversi peer che vogliono comunicare tra loro. E' chiaro che la presenza di una componente centralizzata introduce problemi di scalabilità, tolleranza ai guasti, ecc. tipici di un contesto centralizzato. In fase di progettazione di una qualsiasi rete P2P è fondamentale prevedere come verrà eettuato il routing, ovvero l'instradamento delle informazioni che circoleranno nella rete. Una prima soluzione è quella di costruire un overlay network, ovvero una rete virtuale sottostante, che interconnetterà i diversi peer. In questo modo sarà possibile migliorare la fase di routing, prevedendo delle forme di instradamento delle informazioni a livello applicativo (ad esempio un routing content-aware in cui si instradano le informazioni in base ai contenuti dei diversi peer). Per introdurre le altre tipologie di routing possibili, è necessario eettuare una suddivisione delle reti P2P in due classi: ˆ reti P2P non strutturate: è il caso di quelle reti in cui i nodi sono organizzati come un grafo randomizzato, ovvero in cui non esiste nessun tipo di vincolo sul posizionamento delle risorse rispetto la topologia del grafo. Questa tipologia di rete è utilizzata nei principali sistemi di condivisione dei contenuti, dove sono presenti degli alti tassi di ingressi/uscite di peer nella rete. Infatti, l'eventuale aggiunta o rimozione di un nodo è un'operazione semplice e poco costosa. D'altro canto però l'assenza di vincoli

25 CAPITOLO 3. ARCHITETTURE EMERGENTI PER WSE DISTRIBUITI 24 sulla struttura della rete si paga in termini di costo per la localizzazione di una risorsa. Esistono due forme di routing in questo contesto: 1. directory centralizzata: è presente un nodo centralizzato (denominato directory server ) che possiede l'insieme di mapping risorse/peer, utilizzato in fase di lookup. La gestione di tale directory risulta comportare diversi svantaggi, quali i costi di mantenimento e la scarsa scalabilità e adabilità che introduce la presenza di una componente centralizzata; 2. ricerca ood-based : questa tecnica di localizzazione delle risorse è completamente distribuita e prevede una propagazione della richiesta verso i peer vicini, i quali a loro volta la inoltreranno ai loro vicini (seguendo uno schema di comunicazione denominato ooding). In questo caso è necessario prevedere delle tecniche che evitino la propagazione delle richieste all'innito e l'eventuale ri-elaborazione di una richiesta da parte di nodi già interpellati precedentemente. ˆ reti P2P strutturate: all'interno di questa categoria si possono inserire tutte quelle tipologie di rete in cui esistono dei vincoli sulla topologia della rete, dove perciò l'organizzazione segue delle regole e dei principi di base consolidati. In questo contesto quindi l'inserimento e la rimozione di un nodo è un'operazione costosa, però la localizzazione di una risorsa avviene in modo più eciente rispetto ad uno schema non strutturato. Entrando maggiormente nel dettaglio, il routing in una rete strutturata prevede uno schema di questo tipo: 1. distributed hash table (DHT): in uno schema di tipo DHT si prevede un'astrazione distribuita delle strutture dati hash table, dove si applica una funzione hash per associare un ID a ciascuna risorsa e peer presente nella rete. In questo modo è possibile eettuare un routing oculato, limitando il numero di messaggi scambiati per la localizzazione di un certo peer. Le DHT forniscono un alto livello di scalabilità, potendo operare su reti con un alto numero di nodi operanti e ci si può orientare su diverse soluzioni che permettono dierenti metodologie di routing e di ricerca e memorizzazione delle risorse (es. Chord, CAN, Pastry, ecc.). 3.5 P2P Web Searching Molto spesso si associa, in modo superciale ed errato, il concetto di P2P all'idea di condivisione di le o altri contenuti, per lo più in modo illegale. La

26 CAPITOLO 3. ARCHITETTURE EMERGENTI PER WSE DISTRIBUITI 25 nuova frontiera del settore P2P si basa invece sull'utilizzo in modo oculato ed intelligente delle caratteristiche positive che queste reti possono fornire. In particolare, nel settore di ricerca relativo al Web Searching, si è cercato di coniugare entrambi i concetti, in modo da poter realizzare dei motori di ricerca che siano il più possibili ecienti. Infatti, il problema del Web Searching può essere risolto sfruttando un approccio distribuito e paritario come quello P2P. Ciò è dimostrato da diverse ragioni, quali: 1. i dati presenti nel Web sono distribuiti e risiedono su milioni di siti web dierenti tra loro; 2. le politiche distribuite non sorono dei tipici problemi che si presentano sfruttando componenti centralizzate (quali indexer e updater centralizzati, ecc.); 3. è possibile sfruttare la conoscenza acquisita attraverso i diversi peer della rete per migliorare e facilitare le ricerche. Figura 4: Un WSE Peer to Peer (P2P) Un tipico problema che si presenta in un sistema di Web Searching P2P è basato su come ricercare un certo contenuto web ed è denominato lookup problem o querying problem. In pratica, esiste un certo utente che inserisce un le X nel sistema e un altro utente vuole trovare, a seguito di una ricerca, tale contenuto in un qualsiasi momento (e anche in caso di assenza dalla rete da parte dell'utente pubblicante). Riprendendo le diverse tipologie di routing di

27 CAPITOLO 3. ARCHITETTURE EMERGENTI PER WSE DISTRIBUITI 26 una rete P2P elencate nelle sezioni precedenti, è possibile osservare l'utilizzo di due principali tecniche sfruttate per la fase di querying in un ambito completamente distribuito [7], [20] che permettono la soluzione del lookup problem. La prima prende il nome di query ooding e sfrutta uno schema di comunicazione basato sull'invio della query ai peer vicini (come in gura 5), i quali a loro volta provvederanno ad un ulteriore invio della query stessa, nel caso in cui non dispongano del contenuto richiesto. Questo schema di instradamento porta a degli ovvi e controproducenti aumenti delle latenze di comunicazione tra i nodi della rete, dato l'elevato numero di messaggi scambiati tra i diversi peer. Figura 5: query ooding Progetti di ricerca recenti hanno portato ad una soluzione maggiormente scalabile, che permette di eettuare la fase di querying riducendo i costi rispetto la tecnica del ooding [20]. L'idea di fondo è quella di sfruttare una struttura dati distribuita, denominata Distributed Hash Table (DHT) che permette di partizionare l'appartenenza di un set di keywords tra i nodi partecipanti e di inoltrare in modo eciente i messaggi verso l'unico proprietario di una certa keyword. Ciò è possibile grazie all'introduzione di un ID per ciascuna risorsa presente nella rete, ottenuta mediante una funzione hash: nel momento in cui un certo utente voglia pubblicare un certo contenuto, verrà eettuata una conversione tra il nome del contenuto e una chiave numerica ottenuta mediante una funzione hash. Tale valore servirà per localizzare il nodo su cui pubblicare il contenuto. Risulta quindi chiaro che un utente che in seguito volesse ricercare tale contenuto potrebbe semplicemente eettuare un'azione di lookup conoscendo la chiave, in modo da ottenere l'identicativo del nodo a cui formulare la richiesta. DHT fornisce prestazioni migliori rispetto al ooding, oltre ad un grado di scalabilità e tolleranza ai guasti nettamente superiore. Per poter implementare uno schema di questo tipo in modo eciente è necessario però soermare l'attenzione su alcuni punti chiave, quali:

28 CAPITOLO 3. ARCHITETTURE EMERGENTI PER WSE DISTRIBUITI 27 ˆ mappare le chiavi nei nodi in modo da mantenere un buon bilanciamento del carico; ˆ gestire una routing table che permetta di mantenere un grado di conoscenza di un peer verso gli altri peer della rete.

29 Capitolo 4 P2P WSE: approccio Term Partitioning La suddivisione dell'indice a disposizione attraverso i peer della rete è una delle proprietà chiave che permette di contraddistinguere diverse tipologie di WSE. Come introdotto nelle pagine precedenti, una possibile tecnica di partizione è quella denominata term partitioning. Essa sfrutta un partizionamento orizzontale, in cui ciascuna keywords viene ripartita in un singolo nodo, come esposto in gura 6: Figura 6: Term Partitioning tra 3 nodi Anche in un contesto P2P restano validi i pro e i contro di un approccio term partitioning. In particolare, tale partizionamento porta ad una riduzione dei costi di searching, assicurando che non vengano contattati più di k peer per la risposta ad una query di k termini. Ecco quindi che risulta utile appoggiarsi su un overlay di tipo DHT, utile per la localizzazione del peer responsabile di un certo query term. Con questo approccio è presumibile pensare che si abbia un incremento lineare del throughput nel momento in cui si aggiungono nuovi peer alla rete. 28

30 CAPITOLO 4. P2P WSE: APPROCCIO TERM PARTITIONING 29 D' altro canto le fasi di inserimento e update di un documento richiedono la partecipazione di un numero di servers proporzionale alle keywords presenti nel documento stesso (es. un documento con n keywords porta ad un massimo di n peer contattati). Inoltre, esiste la possibilità di avere delle liste invertite di dimensioni variabili e tale caratteristica si ripercuote negativamente sull'intero sistema, in quanto si può arrivare ad un consistente sbilanciamento del carico. 4.1 Come risolvere il problema dello sbilanciamento del carico In letteratura sono presenti diversi lavori che hanno come obiettivo l'eliminazione dello sbilanciamento del carico in contesti in cui si sfrutta un partizionamento dell'indice rispetto i termini. Un lavoro recente [6] utilizza l'idea di sfruttare il comportamento degli utenti, attingendo informazioni dalle recenti ricerche eettuate attraverso i query log. I query log presenti nei WSE memorizzano l'insieme delle diverse ricerche svolte dagli utenti, includendo insiemi di informazioni annesse (data, ora, tipologia della query, ecc.). In [6] viene eettuata una denizione formale del problema, introducendo la risoluzione di un quesito di ottimizzazione nella ripartizione dei termini del dizionario, il cui obiettivo nale è quello di fornire una massimizzazione del throughput e una minimizzazione del tempo di risposta medio. Per risolvere entrambi gli obiettivi è appunto necessario sfruttare la conoscenza contenuta nei le di log: in particolare è possibile ridurre il numero di risposte alle query da parte di ciascun server, assegnando nella stessa partizione quei termini che spesso co-occorrono insieme nelle query utente esplorate. E' da sottolineare che la soluzione proposta in [6] è stata pensata originariamente per un WSE parallelo, in cui è presente un server centralizzato che intercetta le varie richieste in arrivo dagli utenti ed indirizzate al WSE. Nulla vieta comunque un suo utilizzo in un WSE P2P. Alla base vi è infatti l'introduzione di un approccio di tipo pipelined, dove una query utente q attraversa tutti i servers H, coinvolti nell'esecuzione di q stessa. In particolare, ciascun server inoltra la lista dei DocIDs più rilevanti rispetto alla parte di query processata, verso il server successivo. Seguendo questa tecnica, il parallelismo sarà esplicitato rispetto query dierenti tra loro e non rispetto sottoinsiemi della stessa query. Inoltre si cerca di ridurre il numero medio di servers impiegati, allocando in modo oculato l'insieme dei termini e delle posting list rispetto ai diversi servers a disposizione.

31 CAPITOLO 4. P2P WSE: APPROCCIO TERM PARTITIONING Una stima degli indicatori di Searching Se si volesse fare una stima del workload W associato ad un generico server e della latenza associata ad una generica query, si dovrebbe mantenere traccia dei diversi tempi spesi per una generica esecuzione. In particolare, per ogni coppia <t, lt> (dove con t si indica un termine mantenuto in memoria principale, mentre con lt la posting list associata) memorizzata in memoria secondaria, il workload sarà dato dalla somma di tre componenti: 1. Toverhead: rappresenta il tempo speso da una CPU per ricevere ed inviare un messaggio; 2. Tdisk(lt): corrisponde al tempo speso per trasferire dal disco la posting list lt; 3. Tcompute(lt): che coincide col tempo di computazione speso per la posting list lt. W = T overhead + T disk(lt) + T compute(lt) Tra le tre componenti elencate, il fattore Tdisk(lt) risulta essere quella di maggior rilievo, a causa di alcune costanti spese per le operazioni di I/O. Perciò vale che: W T disk(lt) Nel caso in cui si lavori con una memoria principale di grosse dimensioni, si può assumere che la cache del sistema operativo possa rispondere a molte richieste indirizzate al disco, rendendo quindi il workload circa pari a: W T overhead + T compute(lt) Sotto l'assunzione che ciascun server abbia un numero suciente di sottoquery distinte tra loro da dover analizzare, il tempo di comunicazione che viene

32 CAPITOLO 4. P2P WSE: APPROCCIO TERM PARTITIONING 31 speso per il trasferimento delle query stesse e dei risultati parziali attraverso i diversi nodi, risulta essere over-lappato con della computazione utile. In questo caso il workload totale Wtot, rispetto al usso di query φ, risulterebbe essere: W tot = T c(φ) dove Tc = Tempo di completamento; e il tempo medio speso per servire una query risulterebbe essere pari a: T q = W tot φ Passando a valutare il throughput X del sistema, in [6] viene proposta una formula che permette di esplicitare il rapporto "numero query eseguite / tempo", sulla base delle precedenti grandezze introdotte. In particolare, X risulterà essere: O( φ W tot ) Se si riuscisse ad ottenere un buon bilanciamento del carico tra i nodi, si otterrebbe la condizione: lim O( φ /W tot) = O( φ ) W tot 0 dove: O( φ ) > O( φ W tot ) Inoltre, sfruttando un approccio term-partitioning pipelined, la latenza media L per la risposta ad una generica query (q φ) può essere considerata pari a: O(γ(φ)) q. dove γ è il numero di server impiegati per rispondere ad una generica query

33 CAPITOLO 4. P2P WSE: APPROCCIO TERM PARTITIONING Term Assignment Problem Mediante un partizionamento oculato dei termini attraverso i diversi servers è possibile ottenere un miglioramento degli indici X ed L, riconducendosi quindi ad un problema di ottimizzazione, denominato Term Assignment Problem. Una delle principali grane nella soluzione di questo problema resta il fatto che esso è espresso rispetto alla grandezza φ, la quale risulta essere incognita. L' idea di fondo di [6] è basata sull'utilizzo dei query log come insieme di training da cui attingere conoscenza. L'osservazione si basa sul fatto che esistono delle forti similarità nei query log, sfruttabili per costruire modelli di predizione ecienti. Lavorando in questo scenario è stato proposto un algoritmo greedy, che permette di determinare una funzione oggetto per il problema sopra menzionato. Il funzionamento è il seguente: INPUT: φ, p (numero di servers), T (numero di termini); OUTPUT: p-partitioning function; Essendo un algoritmo greedy, ogni qualvolta si inserisce un nuovo termine in una partizione viene eettuata una valutazione del valore Ω(φ), indicatore per

34 CAPITOLO 4. P2P WSE: APPROCCIO TERM PARTITIONING 33 la funzione oggetto. I termini vengono considerati come frequenti e non frequenti. In particolare, al primo passo vengono ricercati i termini F1 più frequenti nel query log φ. Tali termini saranno poi ordinati in modo decrescente rispetto la frequenza, in modo da sfruttare tale ordinamento per scegliere la miglior partizione rispetto a Ω(φ), a cui assegnare il termine in questione. Nella seconda fase i termini rimanenti saranno anch'essi assegnati, secondo una politica che cerchi di rendere bilanciato l'assegnamento globale dei termini tra i diversi servers. Un ulteriore spunto interessante presentato in [6] è l'idea di sfruttare la replicazione tra tutti i servers a disposizione degli indici relativi ai termini più frequenti. Sfruttando le analisi descritte in precedenza è possibile introdurre una piccola percentuale (da 0.001% a 0.1% del numero totale di termini del dizionario) di termini replicati. Prove sperimentali hanno dimostrato che il numero medio di server per query utilizzati risulti essere diminuito. 4.2 Possibili politiche di caching In questo paragrafo vengono introdotte alcune strategie di caching applicabili nel contesto dei WSE basati su un approccio term partitioning, le quali hanno l'obiettivo di migliorare le prestazioni di tali componenti Web. Infatti le vaste dimensioni dei data set gestiti dai moderni WSE e la necessità di mantenere alti livelli di scalabilità, ha reso le memorie cache una componente di fondamentale importanza, dato che possono permettere di rispondere ad una query in modo immediato e diminuendo quindi i costi di comunicazione e di computazione associati. Nelle prossime pagine verrano perciò presentati alcuni lavori in merito, pensati per WSE P2P, oppure originariamente introdotti per WSE con caratteristiche architetturali dierenti, ma comunque applicabili in un contesto P2P Distributed Cache Table (DCT) Sfruttando i beneci che una cache può fornire in fase di risposta ad una query, è possibile costruire una struttura di caching distribuita che mantenga traccia di alcune risposte, scelte in modo oculato. All'interno di questo lone di ricerca è da citare il lavoro [9], che ha portato all'implementazione di una nuova struttura di caching per reti P2P, denominata DCT (Distributed Cache Table). L'idea di fondo del lavoro è proprio quella di costruire una struttura dati che permetta di associare alle query utente l'insieme dei suoi risultati in modo non banale. Tale approccio è giusticato dal fatto che un grosso numero di entry nella cache risulterà essere scarsamente acceduto, rendendo quindi il loro man-

35 CAPITOLO 4. P2P WSE: APPROCCIO TERM PARTITIONING 34 tenimento non necessario. DCT è stato pensato per query di tipo multiterm, dove ciascuna cache disponibile immagazzina una lista di digest di documenti (del tipo DocId - Lista di termini rilevanti estratti dal documento) che sono utili per risolvere la query, nel caso in cui il suo risultato stia nella lista stessa. Per poter individuare le query da inserire in cache, ciascun peer della rete sfrutta un insieme di statistiche ed un algoritmo greedy per la selezione. In questo modo è possibile costruire una strategia di indicizzazione di tipo query-adaptive on-the-y. Un result set RS(q) contiene l'insieme dei digest di documenti che possono essere utilizzati per risolvere una generica query q. Naturalmente una query q è costituita da un insieme di termini {t1, t2, t3,..., tn} e similmente un generico documento d può essere rappresentato come un insieme di termini d = {t1, t2, t3,..., tr}. Perciò la query q è soggetta ad un match con il documento d sse q d e il result set per q è dato dall'insieme di tutti i documenti che godono della proprietà di matching rispetto q stesso: RS(q) = { di D q di} Inoltre, in [9] si sfrutta un principio innovativo, denominato query subsumption, che permette di denire delle relazioni di inclusioni tra i result set delle query, utili in fase di risposta alle query stessa. In particolare, si può dire che una query a è inclusa in una query b, quando tutti i termini di a sono anche contenuti in b (ovvero a b). Formalizzando l'idea si può descrivere la relazione di query subsumption come in gura 7, dove si riporta il reticolo costruito per i generici termini {a, b, c, d}: Figura 7: Relazione di Query Subsumption tratta da [9] Il reticolo riportato in gura 7 include un insieme di punti che rappresentano le query possibili. Sono anche presenti delle frecce, da interpretare come relazioni di inclusione (es. a b, indica a b). Inoltre, vale la relazione a b RS(a)

36 CAPITOLO 4. P2P WSE: APPROCCIO TERM PARTITIONING 35 RS(b), ovvero la query b può essere risposta mediante un post-processing dei risultati associati alla query a. Seguendo le relazioni di inclusione introdotte dalle frecce di gura 7, è possibile fare un esempio: prendendo tutti i possibili discendenti dei nodi a e cd, è possibile determinare tutte le query che sono incluse in a e cd. Infatti, tutte le query che contengono o il termine a o entrambi i termini c e d possono essere eseguite sfruttano i due Result Set RS(a) e RS(cd). Questo esempio è illustrato gracamente in gura 8: Figura 8: Struttura del reticolo dopo l'inserimento in cache delle query a e cd Un generico peer della rete sfrutta il proprio spazio di storage per inserire in cache il result set associato ad un insieme di query del proprio query load. Non appena tale peer eettua la memorizzazione di un risultato, avverte gli altri peer utilizzando un meta-index distribuito, che mantiene traccia a tutti i componenti della rete di ciò che è presente in cache e permette di sfruttare ecacemente la relazione di inclusione sopra illustrata. Formalmente, il meta-index è una struttura dati distribuita che, data una query q, permette di localizzare una cache per la query q', dove vale la relazione q' q e che permette di risolvere la query q stessa. Data una query q il meta-index ritorna una lista di t-uple {qi, uri(rs(qi)} per le query memorizzate in cache e che sono incluse in q, sfruttando le funzionalità standard put/get oerte da DHT. Perciò per risolvere una query sono richiesti in tutto O(n log N) messaggi: n = q messaggi inviati agli n peer responsabili degli n termini ti di q, più l'insieme delle risposte relative ai peer che hanno una lista di risultati in cache per le query q', tali che q' q. Con N invece si indica il numero di peer presenti nella rete. Nel caso in cui non vi siano cache in grado di risolvere la query, si eettuerà il broadcast verso tutti gli altri peer. Anche in [9] viene proposta una soluzione al problema di ottimizzazione dello spazio di memorizzazione in cache, con l'obiettivo di minimizzare il numero di messaggi inviati in broadcast per la risoluzione di una query e massimizzare il

37 CAPITOLO 4. P2P WSE: APPROCCIO TERM PARTITIONING 36 numero di cache hit. Perciò è stata introdotta una funzione protto, la quale permette di stimare per ciascun peer l'importanza o meno della presenza in cache dei dati relativi ad una certa query Q: dove: profit(q) = sf(q) RS(Q) sf(q) = bf req(q) q Q dove: bf req(q) = n broadcast(q) ovvero il numero di comunicazioni in broadcast eettuate per risolvere q. Sulla base di questa funzione è stata introdotta una strategia greedy, secondo la quale un peer può creare una nuova cache se c'è abbastanza spazio disponibile, oppure può esserci dello spazio disponibile in seguito al rilascio di una zona di memoria che ha una funzione protto più bassa. In questo modo ciascun peer può selezionare localmente la cache più conveniente al momento. A causa delle relazioni di inclusione che si instaurano tra le query, le operazioni di inserimento richiedono un costo aggiuntivo pari a O(log N) per l'aggiornamento del metaindex, mentre un'operazione di rimozione causa un solo messaggio extra. Dalle formule sopra introdotte si capisce che se una query q ha associato un result set di grosse dimensioni avrà poche probabilità di essere inserita in cache, dato che avrà una funzione protto bassa. La soluzione proposta in merito in [9] è quella di eettuare il caching dei top k result, la cui funzione di protto rivista è la seguente: profit topk (q) = af(q) k dove af(q) = sf(q) e k è il massimo numero di record che l'utente visualizza. Le prove sperimentali condotte in [9] dimostrano che il lavoro proposto fornisce buoni livelli di cache-hit, senza dover utilizzare una grossa quantità di storage. Infatti, per ottenere un cache-hit pari all'85% sono necessari 100 peer che immagazzinano 200K records ciascuno. Ma soprattutto si pone enfasi sul fatto che questo approccio fornisca una drastica riduzione di traco rispetto ad un approccio "naive" single-term standard, tanto da portare ad una diminuzione di due ordini di grandezza. Nel caso del bilanciamento del carico si possono osservare delle situazioni poco soddisfacenti nel caso di query molto popolari. Tale

38 CAPITOLO 4. P2P WSE: APPROCCIO TERM PARTITIONING 37 problema risulta alleviato in caso di richiesta dei "top 10 result", anche se per una reale risoluzione viene proposta in [9] una tecnica che sfrutta meccanismi di replicazione per quelle query che risultino essere particolarmente popolari View Tree: una struttura dati eciente per il Web Caching Una struttura dati interessante per il caching dei query result è quella proposta in [13]. In particolare, lavorando con query che hanno una struttura del tipo (ai aj... ak)... (bi bj... bk),... il risultato di tale interrogazione risulta essere l'unione degli items che hanno come attributi una delle congiunzioni di letterali sopra espresse (es.(ai aj... ak)). Formalmente in [13] con il termine view query si intende ciascuna query booleana e con il termine view l'insieme di elementi che soddisfano una particolare view query. Per poter estendere il lavoro anche ad altre tipologie di query viene eettuata una conversione iniziale verso una query vista come una disgiunzione di congiunzioni ed eettuato il caching di ciascuna congiunzione (ad esempio, sarà presente una entry nella cache per (a b) e un'altra per (b c) che possono essere usate congiuntamente o separatamente in query dove sono presenti tali congiunzioni). Esiste però il problema che per una singola query congiuntiva del tipo (ai aj... ak), con k attributi, il numero di views utilizzati per la valutazione della query risulta essere esponenziale in k. La soluzione proposta in [13] è una struttura dati denominata view tree, che permette di mantenere uno snapshot distribuito delle views presenti in un dato istante. I nodi di un view tree sono etichettati con attributi e per poter localizzare il nodo in cui una certa view a 1, a2,..., ak è memorizzata, si eettua una discesa dalla radice dell'albero verso a1, indirizzandosi in seguito verso i nodi glio a2, a3, ecc. Resta però il problema che la localizzazione del più piccolo insieme di views che permettono la valutazione di una query congiuntiva è un problema NPhard nel caso centralizzato. Tale complessità risulta essere ancora maggiore in ambito distribuito, tanto da introdurre in [13] un insieme di linee guida utilizzate all'interno dell'algoritmo di ricerca sui view tree proposto. L'algoritmo non permette ricerche esaustive, data la grossa complessità computazionale che esse introducono e ci si rifà perciò alle seguenti linee guida: 1. exact match: se esise una view che è soggetta ad un match perfetto con la query, allora si ha subito successo; 2. forward progress: in caso di mancanza del match perfetto vorrà dire che almeno un attributo incontrato non occorre nella query formulata.

39 CAPITOLO 4. P2P WSE: APPROCCIO TERM PARTITIONING 38 Figura 9: Struttura dati view-tree In gura 9 è possibile osservare la struttura tipica di un View Tree. In particolare, è interessante notare come la struttura ad albero risulti avere il nodo radice caratterizzato dal possedere molti rami discendenti. Ciò è dovuto al fatto che tutte le views della forma (ai aj... ak) faranno parte di un sottoalbero avente come radice il nodo ai, dato che compare per primo nella congiunzione. Tale fattore può però portare ad un ovvio sbilanciamento nella struttura dell'albero. In [13] è stato risolto il problema seguendo un semplice schema, che prevede la determinazione di tutte le possibili permutazioni della view di partenza e in seguito la selezione in maniera random di una di tali permutazioni. L'inserimento di tale permutazione sarà eettuato nel sottoalbero che dispone del best current prex, ovvero il cui presso ottenuto dalla composizione dei nodi presenti nel cammino discendente che si avvicina di più alla struttura della permutazione stessa. E' chiaro quindi che la struttura view tree risulta subire delle modiche con una certa frequenza. E' perciò desiderabile avere una integrità nell'albero, tanto da pensare di introdurre una politica di refresh apposita, come presentato in [13]. Secondo tale teoria, i gli devono inviare periodicamente dei messaggi verso il padre: se tali messaggi non sono ricevuti entro un certo periodo di tempo (timeout), il nodo padre provvede ad una eliminazione dei gli che non trasmettono. Nel caso di assenza di risposte da parte del padre, saranno i gli stessi a provvedere al loro reinserimento nella struttura view tree. Oltre a seguire delle politiche di tolleranza ai guasti, sono evidentemente necessarie delle tecniche che permettano di riadattare la struttura in funzione di nuovi inserimenti. In particolare, come è possibile osservare in gura 10, l'inserimento di una nuova clausola 'aeg' porta all'inserimento della permutazione 'eag' e ad una modica nei rami della vecchia struttura associata al padre 'ea':

40 CAPITOLO 4. P2P WSE: APPROCCIO TERM PARTITIONING 39 Figura 10: Inserimento della clausola 'aeg' Prove sperimentali svolte in [13] hanno dimostrato i grossi beneci ottenuti dal mantenimento di una struttura view tree. In particolare, sfruttando dei livelli di profondità maggiori nella struttura dell'albero, si ottiene una netta diminuzione degli overhead spesi per l'intersezione delle liste. Inoltre, i tempi spesi per le fasi di update della struttura view tree risultano essere insignicanti. 4.3 Tecniche di ottimizzazione dell'intersezione di liste invertite Dopo aver introdotto nel capitolo precedente alcune politiche di caching per WSE, si passano ad analizzare altre tecniche che perseguono anch'esse l'obiettivo di aumentare la scalabilità dei WSE. In questa sezione sono infatti proposti alcuni spunti di ricerca interessanti, collocabili nel settore che studia delle tecniche di esecuzione di query in modo eciente. L'obiettivo di tutti i prossimi lavori è quello di ottimizzare la fase di intersezione delle liste invertite, nel caso di esecuzione di query multiterm su WSE basati sull'approccio term partitioning. La costruzione della risposta per una query presuppone che si eettui una prima fase di ricerca delle liste associate a tutti i termini che la compongono e una successiva intersezione di tali liste, il cui risultato verrà poi proposto in output. Proprio quest'ultima fase di intersezione risulta essere molto dispendiosa, sia in termini di banda consumata che di latenza dovuta all'invio delle liste attraverso la rete (si ricorda che uno dei principali svantaggi di un approccio term partitioning è la possibilità di lavorare con liste invertite di dimensioni enormi). Perciò la ricerca si è indirizzata verso lo studio di tecniche alternative all'inter-

41 CAPITOLO 4. P2P WSE: APPROCCIO TERM PARTITIONING 40 sezione delle intere liste ritornate, proponendo diverse soluzioni che forniscono risultati apprezzabili Fagin's Algorithm (FA) Tra i diversi algoritmi che permettono di eettuare la valutazione dell'insieme dei top-k result, senza eettuare la scansione delle intere liste invertite, è possibile collocare il Fagin's Algorithm (FA) [15]. L'idea di fondo è quella di poter ordinare le liste invertite in modo oculato, al ne di trovare i top-k result scandendo solo una piccola porzione dell'intera lista. Assumendo che in ciascuna lista invertita l'insieme degli items (D, fd,w) (che indica la struttura di ciascun nodo delle posting list, con il riferimento al documento (D) e la relativa frequenza del termine nel documento (fd,w)) siano ordinati in modo discendente rispetto al valore di fd,w, è possibile eettuare una scansione simultanea di tutte le liste, partendo dal loro inizio e fermandosi nel momento in cui sono stati incontrati k docid presenti in tutte le liste scandite. Infatti, per ciascuno di questi k docid si conosce il loro preciso punteggio, mentre per gli altri docid che sono presenti in una sola lista, si può eettuare un'ulteriore ricerca nelle altre liste al ne di determinarne il loro punteggio nale. Una variante di FA viene dal cosiddetto Threshold Algorithm (TA). Esso eettua delle ricerche randomizzate attraverso le altre liste per la determinazione del punteggio preciso, nel momento in cui un nuovo docid è trovato durante la procedura di scanning. Inoltre, la condizione di terminazione viene modicata in questo modo: in ciascun step si combinano i punteggi associati all'ultimo item scandito in tutte le liste e se il punteggio ottenuto è più piccolo, rispetto al k-esimo punteggio maggiore calcolato precedentemente, ci si ferma. Prove sperimentali eettuate in ambito P2P [15] hanno dimostrato come l'approccio (TA) porti a sensibili miglioramenti prestazionali Simple Algorithm (SA) Il metodo più semplice utilizzabile per determinare l'insieme dei risultati da fornire ad una query è quello di collezionare l'insieme di tutte le liste invertite disponibili ed inviarle ad un nodo centrale che ne eettuerà la valutazione rispetto alla query. Per ovvie ragioni di scalabilità, ecienza e tolleranza ai guasti, è preferibile orientarsi verso un approccio collaborativo, che preveda la ripartizione dell'intera computazione tra più nodi. Da quest'idea è nato il Simple Algorithm (SA), così strutturato: 1. tutti i nodi eettuano un ordinamento ascendente rispetto la lunghezza

42 CAPITOLO 4. P2P WSE: APPROCCIO TERM PARTITIONING 41 delle liste che mantengono. Il primo nodo invia quindi l'intera lista di item del tipo (D,fD,t) al secondo nodo; 2. il secondo nodo eettua una ricerca rispetto la propria lista invertita al ne di calcolare l'intersezione delle due liste a disposizione. Dopo aver eettuato tale calcolo, viene inviato il risultato della nuova lista al nodo successivo; 3. ciascun peer ripete il secondo step e aggiunge il proprio score all'intersezione risultante. L'ultimo peer ritornerà quindi i k docids con il punteggio maggiore Distributed Threshold Algorithm Una variante dell'algoritmo SA è il Distributed Threshold Algorithm (DTA), introdotto in [15]. Il precedente algoritmo SA si basa su un trasferimento di liste tra i diversi nodi e nel caso in cui le liste risultino essere di grosse dimensioni tale soluzione risulta essere ineciente. Ecco quindi che per alleviare il problema è stato introdotto DTA, un algoritmo applicabile in ambito P2P. DTA sfrutta delle tecniche di pruning e la presenza di un query integrator, il quale eettua una split di una query di m termini in m sottoquery indipendenti e le distribuisce al corrispettivo peer (che diviene il peer leader per tale sottoquery). Tutte le sottoquery ottenute possono quindi essere eseguite in parallelo, eettuando una scansione relativa all'indice del peer a cui sono state assegnate. In seguito si sfrutta una struttura a catena (simile ad SA) per il passaggio dei risultati parziali ottenuti, in modo che ogni nuovo risultato ottenuto sia inviato verso il query integrator. Infatti, il query integrator mantiene traccia dei top-k result parziali e una volta vericata la condizione di terminazione, provvederà ad eettuare la notica verso i peer coinvolti nella computazione. Per ragioni di controllo dei costi di updating sono eettuate delle partizioni in blocchi delle liste disponibili. Prove sperimentali hanno dimostrato che DTA permette di ridurre i costi di esecuzione delle query, in particolare per query caratterizzate da pochi termini. Nel momento in cui si lavora con query più articolate le prestazioni calano sensibilmente, date le dipendenze del costo di DTA rispetto il numero di documenti della collezione e del numero di query term presenti Filtri di Bloom I ltri di Bloom sono una particolare struttura dati basata su hashing, che permette di riassumere l'insieme dei membri appartenenti ad un certo insieme. Essi consentono di mappare un insieme S={x1, x2,..., xn} su un bit-vector

43 CAPITOLO 4. P2P WSE: APPROCCIO TERM PARTITIONING 42 di m elementi, inizialmente posti a 0. Il ltro è composto da un insieme di k funzioni hash indipendenti, applicate su ogni elemento dell'insieme in questione, producendo k valori zk. In seguito verranno posti ad 1 gli elementi zk in un bit-vector B. Un esempio di tale procedimento viene riportato in gura 11, dove l'insieme di partenza S è costituito da 2 elementi: Figura 11: Filtro di Bloom su S = 2 elementi Per vericare che un generico elemento y appartenga ad S, si vanno ad applicare le k funzioni hash del ltro ad y. L'elemento y apparterrà ad S sse tutti gli elementi del bit-vector B saranno uguali ad 1. Un esempio di tale procedura viene riportato in gura 12, dove viene ripreso l'insieme S precedente: Figura 12: Determinazione dell'appartenenza di un elemento Tale struttura può essere usata in modo eciente nel conteso del Web Searching, come proposto in [14] e [15], per poter diminuire i costi di intersezione di liste invertite. In particolare, supponendo uno scenario come quello riportato in gura 11, l'invio del ltro di Bloom da parte del server SA come sostituto della lista A, permette di ridurre le comunicazioni per il server B per la determinazione di A B. Tale calcolo conterrà tutti gli elementi presenti nella reale intersezione, con in più alcuni falsi positivi, che comunque non inuiranno sulla qualità della risposta e saranno eliminati in step successivi.

44 CAPITOLO 4. P2P WSE: APPROCCIO TERM PARTITIONING 43 Figura 13: Approccio naive (a sinistra) e con ltr idi Bloom (a destra) per l'intersezione di liste invertite Più formalmente, A e B rappresentano l'insieme di documenti da intersecare, ciascuno contenente un grande numero di DocId, rispetto alle keywords KA e KB. Per determinare l'intersezione A B, il server SA invia un ltro di Bloom F(A) per il documento A al server SB. A questo punto il server SB eettua un test per ciascun membro dell'insieme B, inviando quindi il risultato B F(A) al server SA. Il server SA si occuperà dell'eliminazione dei falsi positivi, calcolando A (B F(A)), che è equivalente all'intersezione A B. Prove sperimentali svolte in [14] hanno dimostrato una diminuzione della memoria occupata e delle comunicazioni globali, dimostrando come i ltri di Bloom permettano di migliorare le prestazioni delle ricerche, a patto di utilizzare una piccola fetta di banda disponibile per l'eliminazione dei falsi positivi che essi comportano. Inoltre, utilizzando i ltri di Bloom è possibile mantenere cache che possono lavorare con insiemi di termini più grandi. Ciò deriva dal fatto che un ltro di Bloom per una keyword è caratterizzato da un'occupazione di memoria sicuramente più piccola rispetto alla memorizzazione di un'intera lista invertita. Inserendo in cache tali ltri è possibile eettuare uno skip della prima fase di lavoro per l'intersezione delle liste, dato che il server SB (gura 13) ha già a disposizione il ltro F(A) Bloom Circle Threshold Algorithm L'introduzione dei ltri di Bloom nel contesto dei WSE ha portato ad una rivalutazione di algoritmi precedentemente proposti in funzione di questa nuova struttura dati. Riprendendo le idee introdotte in DTA è stato presentato un nuovo algoritmo: Bloom Circle Threshold Algorithm (BCTA). Anche in questo caso la query di partenza viene suddivisa in più sottoquery, una per ciascun

45 CAPITOLO 4. P2P WSE: APPROCCIO TERM PARTITIONING 44 query term presente. In questo caso però viene fatto circolare un Compressed Bloom Filter per ciascun blocco, overlappando quindi la fase di circolazione di tale blocco e una seconda fase simile al procedimento di DTA. Dopo che il ltro di Bloom del primo blocco è arrivato al nodo successivo vengono applicate le diverse funzioni hash che caratterizzano il ltro stesso. Nel caso in cui un bit presente all'interno del ltro non eettui il match, esso viene eliminato. In questo modo il tempo speso per ciascun blocco è proporzionale alla dimensione del blocco stesso e non alla dimensione della lista invertita ricevuta dal peer, aumentando le prestazioni rispetto a DTA. Un esempio di funzionamento di BCTA è riportato in gura 14. E' possibile osservare come il peer A smisti il ltro di Bloom associato a ciascun blocco in suo possesso verso i peer B e C e poi invii gli item rimanenti, attraverso gli altri peer disponibili, verso il coordinatore (come eettuato in DTA): Figura 14: Funzionamento dell'algoritmo BCTA 4.4 La tecnica dei risultati incrementali Sia le politiche di caching che i ltri di Bloom permettono di migliorare le prestazioni di un WSE, però nessuna delle due tecniche risulta essere indipendente dalla dimensione dei documenti presenti nella rete. E' infatti ovvio che sia una cache che un ltro di Bloom sono caratterizzati dal possedere una dimensione proporzionale al numero di documenti presenti nella rete. Una tecnica che permette di ottenere tale indipendenza è quella proposta in [14], basata su un troncamento dei risultati forniti all'utente. Più precisamente, quando un utente formula una query, è interessato solo ad un numero ssato di risultati. Per raggiungere il numero pressato si possono

46 CAPITOLO 4. P2P WSE: APPROCCIO TERM PARTITIONING 45 attuare delle tecniche di comunicazione incrementale. Osservando la gura 15 è possibile vedere come il server SA invii il ltro di Bloom per la keyword A in chunck, mentre il server SB invia un blocco di risultati (contenente la reale intersezione e i falsi positivi presenti) per ciascun chunk ricevuto. Tale schema viene iterato no a quando non è stato ottenuto il numero di risultati richiesti. In questo modo è possibile costruire un protocollo di comunicazione estendibile a più servers: Figura 15: Protocollo per la determinazione dei risultati in modo incrementale Un ltro di Bloom non può essere suddiviso in diverse parti, perciò la tecnica proposta in [14] è quella di suddividere l'insieme A in chunck e produrre il ltro corrispondente a ciascun chunck. Tali chunck possono essere scambiati attraverso i diversi server coinvolti nel protocollo in modo parallelo.

47 Capitolo 5 P2P WSE: approccio Document Partitioning Dopo aver descritto l'approccio term partitioning e i suoi sviluppi nei WSE P2P, si passa ad uno studio delle caratteristiche dell'altro approccio utilizzabile per la suddivisione dell'indice. In questo capitolo verranno perciò descritti pregi e svantaggi dei WSE basati sul partizionamento document partitioning, soermandosi sui progetti di ricerca introdotti per migliorare le prestazioni e la scalabilità di tali sistemi. L'approccio document partitioning si basa su un partizionamento verticale dell'indice attraverso i diversi nodi. Ciascun nodo è perciò responsabile delle porzioni di liste invertite associate ai documenti che esso mantiene nel proprio spazio, come riportato in gura 16: Figura 16: Document Partitioning tra 3 nodi Questo tipo di partizionamento è quello utilizzato dal popolarissimo motore di ricerca Google, e si basa sull'idea che in fase di risposta ad una query tutti i nodi presenti nella rete vengano contattati. Ciascun nodo quindi fornisce 46

48 CAPITOLO 5. P2P WSE: APPROCCIO DOCUMENT PARTITIONING 47 l'insieme di documenti considerati i migliori candidati come risposta alla query formulata. Le fasi di inserimento e di modica di un documento non richiedono dei costi di comunicazione proporzionali al numero di keywords presenti nel documento, al contrario dell'approccio term partitioning. Una nota negativa resta comunque la comunicazione broadcast utilizzata in fase di risposta ad una query. Perciò anche in un WSE P2P in cui si aggiungono dei nuovi peer alla rete, si verica una situazione in cui non si ottengono degli incrementi del throughput proporzionali al numero di nuovi nodi disponibili. 5.1 Possibili politiche di caching Dato che un eventuale inserimento di nuovi peer nella rete non porta ad un conseguente aumento del throughput, è lecito pensare che vi siano delle tecniche alternative che permettano di rendere un WSE basato su un approccio document partitioning maggiormente performante e scalabile. In particolare, sono state studiate diverse soluzioni di caching in tale ambito e di seguito verranno illustrate le tecniche in merito ritenute maggiormente interessanti Two-Level Caching for Scalable Search Engines Uno spunto di ricerca interessante nell'ambito del caching è quello proposto in [10]. L'obiettivo di fondo del lavoro è quello di ridurre i tempi di computazione e di I/O per il searching, senza però andare a stravolgere il ranking del motore di ricerca stesso. In [10] vengono proposti tre dierenti implementazioni di cache: 1. Cache dei query result : questa strategia permette di mantenere in memoria la lista dei documenti associati ad una data query. In particolare, per ciascun documento, viene memorizzata una t-upla composta da {Url, titolo documento, 250 caratteri di Abstract}. Tale t-upla verrà poi utilizzata dalla cache come surrogato di ciascun documento. Innanzitutto in [10] è stato risolto il problema della determinazione del numero di documenti da memorizzare in cache per ciascuna query. Sfruttando alcuni risultati sulle tendenze dei comportamenti degli utenti, si è dimostrato che essi non richiedono più di 50 risposte per query (nel 70% dei casi solo le prime 10 risposte). Perciò si è deciso di limitare la cache ai soli primi 50 risultati per ogni query. Il secondo problema trattato è stata la politica di sostituzione dei blocchi della cache. In [10] è stato proposto un metodo LRU, che fornisce buone prestazioni globali; 2. Cache delle liste invertite: tale strategia prevede la memorizzazione in

49 CAPITOLO 5. P2P WSE: APPROCCIO DOCUMENT PARTITIONING 48 cache della lista dei documenti Web associati ad un dato query term. Il WSE inserisce in cache le liste invertite associate a ciascun termine e le utilizza per rispondere alle query. In questo modo è possibile aumentare la scalabilità del WSE. I problemi da dover trattare riguardano la dimensione delle cache list e l'organizzazione interna della cache. Come enunciato nelle pagine precedenti, la dimensione della lista invertita è proporzionale alla popolarità del termine di riferimento e al numero di documenti indicizzati. Ecco quindi che spesso si possono trovare delle liste di dimensioni enormi, dicili da trattare. In [10] si è sfruttato un ordinamento della lista invertita rispetto alla frequenza del termine nel documento, in modo da non dover attraversare l'intera lista. Perciò è possibile partizionare la lista ordinata in blocchi di documenti, nei quali il termine compare con la stessa frequenza. E' chiaro che i primi blocchi saranno quelli di dimensioni minori e via via tale dimensione aumenterà per i blocchi più lontani. Inoltre è necessario adottare una strategia di prefetching per i primi blocchi, dato che essi saranno quelli più acceduti e viste le piccole dimensioni, porterebbero a molti seek I/O evitabili; 3. Cache a 2 livelli: le due metodologie di caching sopra discusse presentano pregi e difetti. In particolare, nel caso di caching dei query result si ottengono dei miglioramenti nei tempi di risposta rispetto il caching delle liste invertite. D'altro canto l'hit ratio del primo approccio risulta essere molto inferiore rispetto al secondo. Ecco quindi che in [10] è stato proposto un uso combinato dei due metodi, costruendo uno schema secondo il quale prima si eettua un check con la cache dei query result ed in seguito, in caso di miss, si sfrutta l'altra cache.

50 CAPITOLO 5. P2P WSE: APPROCCIO DOCUMENT PARTITIONING 49 Figura 17: Cache dei Query Result (a), Cache delle liste invertite (b), Cache a 2 livelli (c) Prove sperimentali eettuate in [10] hanno dimostrato che l'introduzione di una cache permette di ottenere un miglioramento di un fattore 3 del throughput rispetto ad un sistema senza caching. Inoltre, tra i tre diversi schemi proposti, il caching a 2 livelli è quello che fornisce le prestazioni migliori, tanto da portare ad un miglioramento del 52% rispetto al caching basato sulle liste invertite e del 36% rispetto al caching dei query result Weighted Caching Tra le diverse politiche di caching per il Web Searching, le tecniche di caching pesato assumono un ruolo molto importante, vista la loro essibilità di progettazione. E' possibile infatti partire da uno schema algoritmico di base ed introdurre diverse varianti che permettono di implementare politiche di caching dierenti tra loro. Innanzitutto è necessario formalizzare il problema, secondo quanto introdotto in [12]: ˆ Obiettivo: mantenere in una memoria cache un insieme di le, che permettano di rispondere immediatamente ad un usso di query φ, massimizzando l'hit ratio; ˆ A ciascun le x è associato un intero positivo, denotato con size(x) ed un costo cost(x) non negativo per caratterizzare il suo retrieving e che permetta di valutare casi in cui la distanza tra i nodi della rete vari;

51 CAPITOLO 5. P2P WSE: APPROCCIO DOCUMENT PARTITIONING 50 Per la risoluzione di un problema di caching pesato è possibile utilizzare uno schema algoritmico denominato LandLord Algorithm così strutturato: 1. si mantiene traccia di un valore reale proporzionale a size(x) e a cost(x), denominato credit(x) per ogni le x nella cache e che rispetti la disuguaglianza 0 credit(x) cost(x); 2. non appena un le x viene richiesto: (a) se il le non è nella cache si ripete la procedura eviction no a quando si trova spazio nella cache per il le x. In caso di spazio disponibile si inserisce x, inizializzando i parametri credit(x) e cost(x); (b) se il le è presente in cache, allora si rivaluta il valore credit(x). La procedura eviction si basa sulla seguente idea: 1. le x presente in cache: credit(x) = credit(x) - ( * size(x)); 2. si elimina dalla cache ogni sottoinsieme non vuoto dei le x con credit(x) = 0. Partendo da questo schema algoritmico di base è possibile riportarsi a delle politiche di caching dierenti tra loro. Ad esempio: ˆ LRU: è possibile specializzare l'algoritmo LandLord in una politica LRU settando il credit(x) pari ad 1 in caso di hit per il le ed eliminando il le LRU con credito 0 nella procedura eviction Three-Level Caching for Scalable Search Engines Proseguendo nell'analisi degli spunti di ricerca in merito al caching P2P, è importante citare il lavoro [11]. In [11] si utilizza uno schema di caching a tre livelli, che estende in parte il lavoro [10], introducendo però delle teorie e dei concetti dierenti. In particolare, si parte dall'idea consolidata che le liste invertite siano una struttura dati di dimensioni inferiori e più semplici da trattare rispetto ad un'intera collezione di documenti. Nonostante ciò, la lunghezza delle liste invertite può risultare in molti casi troppo grande, rendendo le operazioni di attraversamento delle stesse problematiche. Perciò è stato proposto uno schema di caching a tre livelli, così strutturato: ˆ cache dei query result, seguendo l'approccio introdotto in [10] si mantiene traccia dei risultati delle query più recenti. Questo livello può essere presente sia a livello disco che memoria;

52 CAPITOLO 5. P2P WSE: APPROCCIO DOCUMENT PARTITIONING 51 ˆ cache delle liste invertite, seguendo l'approccio introdotto in [10] si sfrutta una piccola porzione della memoria principale per mantenere traccia delle liste invertite maggiormente accedute; ˆ Intersection caching (Projection caching), in questo livello si eettua un caching delle liste invertite associate a coppie di termini, che co-occorrono con una certa frequenza, in query congiuntive. Nel momento in cui bisogna eettuare l'intersezione di due liste invertite è possibile recuperare dalla cache la lista intersezione, diminuendo drasticamente il costo dell'esecuzione della query. Lo spazio occupato per questo livello è sull'ordine del 20/40% dello spazio disco usato dall'intero indice. Una caratteristica introdotta in [11] è il modo di trattare l'intersezione tra liste invertite: nel momento in cui vengono trattate due liste La e Lb, si inseriscono due proiezioni del tipo Ia b, Ib a, dove Ia b contiene tutti i postings di La, i cui docid appaiono anche in Lb, e viceversa. In questo modo è possibile gestire un risultato equivalente alla normale intersezione ed ottenibile in modo più facile. D'altro canto una proiezione occupa più spazio di un intersezione, anche se in [11] viene considerato un problema di scarsa rilevanza rispetto al miglioramento delle prestazioni che si ottiene con questo approccio. Figura 18: Sistema 3-level caching Il livello di caching dei query result permette di ottenere buoni risultati per query costituite da un singolo termine o da due termini, mentre nel caso si lavori con query costituite da più termini i risultati tendono ad essere più scadenti. Comunque prove sperimentali in [11] hanno dimostrato che in query con tre o più termini esiste una buona probabilità di trovare coppie di termini già incontrate in passato. Perciò un approccio a tre livelli permette di gestire un caching dei risultati per query a singolo termine (o 2 termini) e utilizzare un cache delle liste invertite e di eventuali proiezioni di esse, nel caso di query strutturate con più di 2 termini.

53 CAPITOLO 5. P2P WSE: APPROCCIO DOCUMENT PARTITIONING 52 Nel lavoro [11] sono stati schematizzati i costi per la gestione del caching delle proiezioni, i quali possono essere così riassunti: 1. costo di scrittura: dovuto all'inserimento di una nuova proiezione nel disco; 2. costo di codica: dopo aver scritto la proiezione è necessaria una fase di codica secondo lo schema di compressione utilizzato nell'indice invertito; 3. creazione della proiezione: la proiezione viene creata durante l'esecuzione di una query, senza costi disco addizionali, ma richiedendo un CPU overhead, a causa dei cambiamenti in atto nel query processor. Per quanto riguarda il primo costo citato si è dimostrato in [11] che esso può essere contenuto a bassi valori, mentre per il costo di codica si possono sfruttare delle tecniche di compressione veloce per l'indice, che portano ad una drastica riduzione di tale overhead. Il terzo costo merita un'analisi più accurata, per questo all'interno del lavoro proposto in [11] sono state fornite due dierenti versioni per il problema della creazione dell'intersezione delle liste invertite. La prima versione è stata denominata oine e si basa sull'assunzione che il usso di query sia conosciuto in anticipo e l'insieme delle proiezioni venga creato prima dell'inizio dell'esecuzione del usso stesso. Nella versione online le query sono presentate una alla volta e la fase di proiezione viene creata e inserita in cache durante l'esecuzione della query. Risulta chiaro che il problema oine sia di dicile soluzione, tanto da rientrare nella classe NP, eccezion fatta per il caso in cui le proiezioni siano della stessa dimensione e le query siano limitate a solo due termini (complessità polinomiale). In [11] sono proposte le soluzioni per entrambi i problemi: Oine Problem: è stato implementato un algoritmo greedy, di complessità O(k log(k)) dove k è la somma dei quadrati delle dimensioni delle query, che eettua una valutazione delle proiezioni, inserendo quelle che sono considerate le più convenienti. L'algoritmo procede seguendo i seguenti step: 1. per ciascuna query qi in una certa sequenza Q e ciascuna proiezione It t', con (t,t' qi) si crea una nuova entry con struttura (t, t', i, It t', It - It t' ). L'ultimo campo è il benet associato alla proiezione quando viene usata al posto della lista intera; 2. tutte le entry con parametri t,t' identici verranno quindi raggruppati in una entry unica, ma aggiungendo un campo addizionale (total benet), il quale contiene la somma dei benet della entry condivisa; 3. vengono caricate tutte le entry in un heap (il quale permette l'estrazione degli elementi con benet massimo);

54 CAPITOLO 5. P2P WSE: APPROCCIO DOCUMENT PARTITIONING ripetutamente viene estratto un elemento ed inserito nella cache. Nel caso in cui non sia un elemento opportuno per la cache verrà rimpiazzato con un nuovo elemento. Online Problem: in [11] viene osservato che tale problema è un'istanza del problema del caching pesato, dove gli oggetti hanno una dimensione arbitraria e viene eettuato il caching degli oggetti "più convenienti". In particolare, a ciascun oggetto inserito in cache viene assegnato una deadline, proporzionale al rapporto benecio/dimensione dell'oggetto (secondo lo schema dell'algoritmo LandLord introdotto nel paragrafo precedente). Tale valore viene utilizzato per valutare quale oggetto debba essere rimpiazzato nella cache, a favore di uno nuovo. Inoltre viene eettuata una rivalutazione della deadline per un elemento della cache che è stato recentemente utilizzato. Prove sperimentali svolte nel lavoro [11] hanno dimostrato che l'introduzione del livello di caching delle proiezioni porta ad un netto miglioramento delle prestazioni, aumentando il throughput del WSE. Inoltre, usando uno schema a 3 livelli di caching è possibile ridurre il numero medio di blocchi letti per query DiCAS Caching Mechanism Una politica di caching per un WSE può anche essere vista come una tecnica hardware e software che permetta di trovare un giusto compromesso per il tradeo costi di indicizzazione/costi di ricerca. E' infatti noto che i meccanismi di routing in un sistema P2P sono basati principalmente su due tecniche dierenti: la tecnica del ooding, che prevede inizialmente l'instradamento dei dati verso un peer vicino che provvederà ad un ulteriore inoltro verso i suoi vicini nel caso in cui risulti necessario; l'altra tecnica si basa sull'utilizzo di strutture dati di tipo DHT, le quali permettono un miglioramento nei criteri di ricerca grazie a dei mapping delle risorse/dati da gestire in un unico peer, individuato mediante l'utilizzo di una funzione hash. Risulta quindi chiaro che con il primo approccio si ottengono dei miglioramenti nei costi di indicizzazione, pagando però dazio in fase di ricerca, mentre nel secondo approccio la situazione risulta essere simmetrica (in particolare in caso di rete fortemente dinamica i costi di mantenimento dell'indice risultano essere elevati). Per bilanciare tale trade-o è stato proposto nel lavoro [21] un meccanismo di caching distribuito, combinato con un algoritmo di ricerca adattivo, denominato DiCAS. L'idea di fondo è quella di poter inserire in cache gli indici disponibili in gruppi di peer sfruttando delle funzioni hash predenite. In seguito, mediante le stesse funzioni hash sarà possibile eettuare una ricerca adattiva in modo da inviare una query solo ai peer che possiedano un'alta probabilità di disporre

55 CAPITOLO 5. P2P WSE: APPROCCIO DOCUMENT PARTITIONING 54 dell'indice richiesto. Inizialmente ciascun nodo della rete assumerà in modo randomizzato un valore iniziale compreso in un range [0.. M-1] e una query eettuerà match con un certo peer solamente se verrà soddisfatta l'equazione: P eergroupid = hash(query) modm DiCAS fornisce un protocollo secondo il quale la risposta ad una certa query verrà inserita in cache solamente in un determinato peer, limitando quindi l'invio della query ad un ristretto insieme di peer, con conseguente diminuzione del traco di rete. Tale soluzione porta ad una suddivisione virtuale dell'intero spazio di ricerca in diversi livelli, dove ciascun livello di peer è etichettato con lo stesso group ID. Ad esempio, se si utilizzasse un fattore M=3 si otterrebbe una soluzione come quella illustrata in gura 19: Figura 19: Partizionamento logico con fattore M=3 Come è possibile osservare dalla gura 19, dopo aver localizzato il gruppo di peer da interrogare, si passerà ad una fase di ooding interno a tale gruppo. L'implementazione del progetto DiCAS proposta in [21] è basata sull'utilizzo della rete P2P Gnutella. In particolare, è stata eettuata una modica nei peer disponibili: rispetto ad un peer Gnutella standard, quello proposto in [21] è in grado di creare e mantenere un indice locale di cache relativo ad insiemi di query result. Tale peer è stato denominato CGC peer e permetterà ad ogni altro peer della rete di utilizzare la propria porzione di cache nelle future fasi di interrogazione. A riguardo sono state svolte delle prove sperimentali in cui in un primo caso si è utilizzato un unico peer CGC, il quale permette ai propri peer vicini di utilizzare la cache disponibile in fase di risposta ad un certa query e nell'altro caso si sfruttano due peer CGC collegati tra loro. Di particolare interesse è il fatto che in DiCAS ciascun peer mantiene, oltre al proprio indice locale, un response index che mantenga traccia dei query result che passano attraverso il peer. Ciascun item del response index includerà il nome associato della query, oltre all'indirizzo IP della macchina dove sarà

56 CAPITOLO 5. P2P WSE: APPROCCIO DOCUMENT PARTITIONING 55 localizzato il le corrispondente. In questo modo quando un peer ricerverà una query da un proprio vicino, eettuerà una ricerca sul proprio local index oltre che sul response index. Inoltre, sfruttando la suddivisione a livelli precedentemente introdotta, la fase di caching di un certo query result sarà eettuata passivamente (in modo da non richiedere eccessive comunicazioni) solamente dai peer appartenenti al group ID ottenuto dall'apposita funzione hash (nell'esempio della gura 20 il group ID ottenuto è 1 e solamente i peer con group ID 1 cachano i query result che uiscono in tale usso di query): Figura 20: Strategie di caching in DiCAS In questo modo è possibile costruire una politica di caching distribuito localizzato solo ad alcuni peer. Inoltre, la ricerca adattiva proposta in [21] si basa anch'essa sull'utilizzo dei group ID creati, al ne di limitare il numero di peer da contattare in fase di risposta. Per garantire la coerenza della cache disponibile si è deciso di utilizzare uno schema più conveniente rispetto i classici metodi di checking o di notica. Tale soluzione prende il nome di one more step forwarding e prevede che nel momento in cui si verica un cache hit, invece di rispondere direttamente alla richiesta, venga inviata la query al peer che detiene il le. Nel caso in cui tale peer non disponga del le o sia irraggiungibile, si passerà ad un'invalidazione della cache e la query verrà inoltrata. Per ridurre gli overhead dovuti alla fase di verica si è deciso di introdurre un timestamp Tc a ciascun item c presente in cache, in modo da poter registrare l'ultima validazione di c. Si può quindi introdurre un intervallo di tempo τ, in modo che per un query hit relativo all'item c in tempo t, se si verica che Tc < t < Tc + τ si può passare ad un invio immediato della risposta. Altrimenti se t > Tc + τ, la query dovrà essere inviata al peer detentore del le, al ne di controllare la validità. Sempre in [21] è stato proposto uno schema di coerenza della cache che prevede l'invio da parte del caching peer del proprio indirizzo IP, oltre che della risposta. Nel caso in cui il querying peer fallisce la fase di retrieving del dato, invierà un clearing message al peer di cui dispone dell'indirizzo IP (il peer che deteneva in cache l'in-

57 CAPITOLO 5. P2P WSE: APPROCCIO DOCUMENT PARTITIONING 56 formazione). Tale messaggio porterà all'invalidazione dell'item corrispondente nella cache. Questo approccio è stato denominato appunto backtrack clearing. Le simulazioni compiute nel lavoro [21] sono incentrate su un confronto esplicito delle performance fornite da DiCAS e da un approccio UIC (Uniform index cache mechanism). In UIC viene eettuato un caching dei query result nei peer che occorrono nel cammino inverso della query, con la speranza che le query future possano essere risposte in modo diretto da tali cache. DiCAS va oltre l'approccio UIC, eettuando un caching e una successiva fase di ricerca orientata a sottogruppi appositi di peer e limitando quindi delle ovvie ridondanze di dati. Il confronto porta a dimostrare come DiCAS riduca notevolmente il traco di rete. Per ottenere dei risultati soddisfacenti in termini di hit ratio è però necessario attuare alcune correzioni allo schema di base: innanzitutto è necessario che quando un peer si connette alla rete debba calcolare l'hash di ogni suo oggetto e nel caso di mismatch provveda ad indirizzare tali oggetti nella cache corretta; inoltre nel caso in cui una certa query non possa essere inoltrata ulteriormente, a causa di mismatch con i peer vicini, si provvederà ad inviare la query al vicino con grado di connessione più alto (inteso come numero di vicini di cui dispone). Le simulazioni compiute in [21] hanno dimostrato come l'hit ratio sia inversamente proporzionale al numero di livelli. Nonostante il numero di livelli abbia un'alta dipendenza con la struttura della rete è sempre preferibile utilizzare un valore di M basso. Eettuando un ulteriore confronto tra DiCAS, (nella versione ottimizzata), UIC e un sistema senza cache (e che sfrutta quindi il ooding) è stato dimostrato come DiCAS riduca il traco di rete e il tempo di risposta, mantenendo dei buoni valori di successo (hit ratio). Inoltre, con l'aumentare del numero di query presenti nei ussi in arrivo ai peer, i risultati ottenuti dalle simulazioni risultano essere particolarmente favorevoli all'approccio DiCAS Distributed Caching based on Query Similarity Proseguendo nell'analisi di soluzioni di caching è interessante citare il lavoro [22]. Esso è incentrato sull'utilizzo di un overlay network ibrido, denominato HON (Hybrid Overlay Network), che permette di organizzare un insieme di peer e di dati in uno spazio n-dimensionale. Fondamentalmente HON prevede una prima ripartizione dei peer che condividono contenuti simili in uno spazio n- dimensionale, in modo da limitare il ooding mediante l'invio oculato di query attraverso i peer; e una seconda fase di organizzazione dei contenuti in regioni adiacenti ad un feature space, al ne di ottimizzare range/nearest-neighbor query. Il feature space è rappresentato da particolari attributi associati ai dati trattati ed è partizionato in diverse celle, ottenute da una suddivisione logica

58 CAPITOLO 5. P2P WSE: APPROCCIO DOCUMENT PARTITIONING 57 dei range di valori associati a ciascuna feature. In questo modo è possibile introdurre un concetto di similarità tra oggetti, riferendosi alla locazione in cui essi vengono mappati. In maniera più specica, la costruzione di HON può essere schematizzata nei seguenti step: ˆ organizzazione dei dati in uno spazio di feature: ciascun dato viene descritto mediante un vettore di feature e corrisponde ad un punto nel feature space. Se ad esempio si utilizzasse un feature space bidimensionale, i dati verrebbero mappati nelle celle in base alla loro descrizione, ottenendo una possibile situazione come quella riportata in gura 21: Figura 21: Organizzazione dei dati in HON ˆ in seguito è necessario organizzare i peer nel feature space. Ciascun peer verrebbe mappato in un insieme di celle che contiene i suoi dati. Per poter ottenere tale mapping è necessario usare una soglia T, in modo che un dato peer verrà mappato in una cella solo se ha un numero di oggetti maggiore a T in essa: Figura 22: Organizzazione dei peer in HON

59 CAPITOLO 5. P2P WSE: APPROCCIO DOCUMENT PARTITIONING 58 Ciascun peer presente in HON mantiene un link ai peer simili, ovvero i peer che risiedono nella stessa cella. Inoltre, vengono mantenuti degli insiemi di links con un insieme random di peer cha appartengono alle celle adiacenti (neighboring links). In un livello separato ciascun peer mantiene degli shortcuts, che sono creati nel momento in cui il peer si connette alla rete: non avendo informazioni circa i peer più distanti egli sfrutterà inizialmente la conoscenza fornita dai peer vicini, in modo da ottenere insiemi di peer rilevanti alle proprie query. Tali peer saranno inseriti in una lista denominata shortcut (gura 23): Figura 23: Indicizzazione in HON Quando un peer deve gestire una certa query Q, denisce prima la target cell, ovvero quella cella in cui sono contenute le risposte rilevanti per la query Q. In seguito si potrà passare ad un inoltro della query attraverso i peer vicini (sfruttando i neighbors links) e presenti nelle shortcut list. Perciò la query verrà inoltrata nché raggiungerà la target cell, dove poi verrà eettuato il ooding per determinare le risposte rilevanti e simili (gura 24): Figura 24: Arrivo alla target cell e successivo ooding

60 CAPITOLO 5. P2P WSE: APPROCCIO DOCUMENT PARTITIONING 59 Una tecnica di caching che sfrutta HON prevede l'assegnamento di una cache a ciascuna cella non vuota e le query che sono mappate nella stessa cella saranno memorizzate e servite dalla stessa cache. In questo modo è possibile raggruppare nella stessa cache insiemi di query simili, aumentando il tasso di successo ed evitando ridondanze. Inoltre, un obiettivo di fondamentale importanza è la riduzione al minimo del ooding all'interno di ogni cella, in modo da aumentare le prestazioni globali. Perciò in [22] si è deciso di puntare su una tecnica di caching in HON che è dierente dalle tradizionali politiche di caching: non si eettua il caching di dati, bensì di indirizzi di peer utili per rispondere ad una certa query. Questa tecnica permette perciò di indirizzare la query ai soli peer che contengono una risposta rilevante, diminuendo il ooding. Una cache è assegnata ad un solo peer per ogni cella (denominato active peer) e tutti gli altri peer (passive peer) saranno registrati da tale peer. Nel momento in cui una query raggiunge la target cell, l'active peer rilevante eettuerà un controllo della cache e in caso di hit si sfrutterà l'indirizzo memorizzato per determinare il peer che fornirà la risposta. Altrimenti, in caso di miss si effettuerà un ooding della query attraverso tutti i peer contenuti nella target cell. Nella gura 25 si riporta un esempio dove si può vedere come vi sia una drastica riduzione dei messaggi scambiati rispetto alla soluzione precedente in cui si eettuava il ooding: Figura 25: Caching in HON (eliminazione del ooding) Le simulazioni eettuate in [22] hanno dimostrato come le politiche di caching su HON permettano di ridurre sensibilmente il query scope, ovvero la frazione di peer che sono impiegati nella fase di query processing, rendendo quindi le ricerche ottimali.

61 Capitolo 6 MINERVA: un WSE P2P basato su Document Partitioning In questo capitolo verrà presentato in dettaglio un WSE P2P basato sull'approccio document partitioning e denominato MINERVA [2], [3], [4], nato da un recente progetto di ricerca che si basa su alcune idee di fondo particolarmente interessanti. Sfruttando un approccio document partitioning in una rete P2P, si può pensare ad uno scenario in cui ciascun peer mantiene traccia di una porzione dell'intero web disponibile mediante un proprio indice locale e nel momento in cui esso si collega al resto della rete già presente, condivide il tutto con gli altri utenti. L'obiettivo cruciale dell'intero progetto è quello di poter usufruire di un insieme di risultati per le ricerche che garantiscano dei buoni valori per gli indicatori classici dell'information Retrieval, quali precisione e richiamo. Allo stesso tempo, però, bisogna anche disporre di un processo di ricerca che scali con la dimensione della rete: vista la variabilità del numero di peer presenti e dell'intera topologia delle rete, è necessario avere sempre prestazioni soddisfacenti. In questo scenario è possibile collocare MINERVA, un WSE basato su un approccio Collection Selection in ambito P2P. Per comprendere meglio le linee guida del progetto è utile introdurre un semplice esempio: seguendo un approccio di ricerca tradizionale, un'interrogazione basata su una query multiterm del tipo 'Michael Jordan' o 'Studenti dottorandi', porterebbe ad una prima decomposizione di ciascuna query in un insieme di termini singoli e alla successiva ricerca dei best peer per ciascun termine. Ottenute tali liste di peer si passerebbe ad una loro intersezione, in modo da poter disporre di una lista globale (PeerList), utile per il successivo invio dell'intera 60

62 CAPITOLO 6. MINERVA: UN WSE P2P BASATO SU DOCUMENT PARTITIONING 61 query. Questo approccio di "fattorizzazione" della query porta però a dei risultati scadenti, in quanto non vengono mai sfruttate delle possibili correlazioni intercorrenti tra i query term. Ad esempio, nella query 'Studenti dottorandi' questa correlazione risulta essere molto elevata, per cui è corretto pensare che all'interno dei migliori risultati (best matches) per la query vi sia una grossa probabilità di trovare i due query term insieme. In MINERVA si cerca perciò di introdurre un approccio di Collection Selection in ambito P2P, in modo da poter disporre di un metodo che permetta di indirizzare la query solo ad un numero ristretto di nodi, in grado di fornire i risultati più rilevanti. I caveaut del progetto MINERVA sono quindi l'utilizzo di un overlay network, basato su una struttura dati di tipo Distributed Hash Table (DHT), che connette i peer e permette la gestione di una directory distribuita, utile per la memorizzazione di informazioni aggregate circa la "conoscenza" disponibile a ciascun peer gestita in termini di statistiche e metadati. L'altra caratteristica chiave è la possibilità di sfruttare le statistiche passate relative alle fase di querying, in modo da poter inferire conoscenza per migliorare le prestazioni e la qualità delle risposte oerte dal sistema. In questo modo i peer della rete avranno un duplice ruolo: directory peer e storing peer (delle index list). 6.1 La struttura DHT di MINERVA La DHT è una struttura introdotta con l'obiettivo di poter gestire un insieme di informazioni aggregate che sono pubblicate ed utilizzate dai peer della rete attraverso una directory distribuita. In MINERVA si è deciso di eettuare una distribuzione deli metadati e delle informazioni statistiche associate ai query term, senza però distribuire documenti o porzioni di indici attraverso i peer. Una struttura dati DHT ricalca le caratteristiche delle hash table, le quali sono basate su insiemi di coppie <key, value>, utili per la localizzazione di dati a cui viene associata una chiave, ma sfrutta anche i pregi oerti dalle strutture dati distribuite, quali: ˆ decentralizzazione; ˆ scalabilità; ˆ fault tollerance. In particolare, in MINERVA viene sfruttato il protocollo Chord [3] per ottenere le funzionalità tipiche di una DHT. Infatti Chord è un protocollo P2P che permette di ottenere un'eciente localizzazione del nodo che mantiene in memoria il data item corrispondente ad una certa chiave di ricerca fornita in input. Esso possiede delle caratteristiche di tolleranza ai guasti e di gestione di eventuali

63 CAPITOLO 6. MINERVA: UN WSE P2P BASATO SU DOCUMENT PARTITIONING 62 fasi di modiche nella topologia della rete. Sfruttando questa tecnica, in MIN- ERVA sarà possibile una gestione relativa a ciascun peer dei metadati associati ad un sottoinsieme random di termini. Ciò scaturisce dal fatto che Chord permette una mappatura uniforme del dominio relativo alle chiavi di ricerca tra il dominio delle Chord keys. Assegnando a ciascun nodo Ni una chiave Ki nel dominio [0, 2m) sarà possibile ordinare i diversi id mediante un identicatore circolare modulo 2m. Ciascun nodo Ni sarà quindi responsabile di tutte le chiavi presenti nell'intervallo (Ki-1, Ki] (mod 2m). Nella gura 26 viene riportata una rappresentazione schematica della struttura di Chord: Figura 26: Struttura ad anello di Chord Le caratteristiche di Chord permettono una memorizzazione da parte di ciascun nodo delle informazioni relative ai suoi predecessori e successori nella topologia circolare della rete, oltre alla presenza di una nger table con associati gli indirizzi di altri m nodi. Inoltre, grazie all'uniformità nella distribuzione dei valori nel dominio delle chiavi, il protocollo possiede le seguenti caratteristiche: ˆ in un sistema ad n nodi saranno necessari O(log n) messaggi per localizzare un nodo responsabile di una certa chiave; ˆ esiste una garanzia nel bilanciamento tra i nodi del carico di informazioni memorizzate. In questo scenario ciascun peer pubblica un insieme di informazioni per-term, ovvero relative all'insieme di termini presenti nel proprio indice locale. Tali dati sono memorizzati in una porzione della directory distribuita e si sfrutta DHT per la determinazione del peer responsabile dei dati associati ad un certo termine. In questo modo si può disporre di un insieme di primitive quali: ˆ value retrieve(key);

64 CAPITOLO 6. MINERVA: UN WSE P2P BASATO SU DOCUMENT PARTITIONING 63 ˆ insert (key, value). Per tutti i termini che compaiono nella query, sarà possibile eseguire la primitiva retrieve (term), la quale ritornerà l'insieme di tutti i peer più promettenti, sulla base delle statistiche mantenute nella directory distribuita. Una volta individuato il peer, si è sicuri che esso manterrà nella directory distribuita una PeerList di postings per un certo termine, ottenuta sfruttando i dati disponibili da tutti i peer presenti nella rete. Ciascun post mantiene un riferimento al peer che detiene dei dati utili in merito al termine, oltre a delle statistiche utilizzabili per calcolare indici di qualità tipici dell'information Retrieval (es. la dimensione della lista invertita per il termine in questione, ecc.) e che saranno utili per determinare il peer più promettente per la query. La primitiva insert (key, value) permetterà, invece, l'inserimento di una nuova PeerList per un certo termine. Le informazioni memorizzate nella directory distribuita sono ottenute attraverso delle analisi locali rispetto ai diversi indici e sono utili per limitare il numero di peer da contattare durante la fase di risposta ad una query. In particolare, in MINERVA si eettuano delle continue analisi locali a ciascun peer sull'indice a disposizione e vengono calcolate delle statistiche circa la qualità dell'indice rispetto a particolari termini. Ad esempio, si tiene traccia di grandezze quali la dimensione dell'indice, il numero di termini distinti che vi compaiono all'interno, il numero di documenti che contengono un particolare termine, ecc. Mediante le tecniche classiche di data mining sarà possibile estrarre conoscenza da questo insieme di informazioni aggregate. 6.2 Valutazione di una query multiterm in MIN- ERVA L'esecuzione di una query multiterm procede in MINERVA seguendo i seguenti passaggi: 1. la query viene prima eseguita localmente utilizzando l'indice locale al peer. A livello progettuale ci si aspetta che questo primo step permetta di rispondere a molte query senza dover incorrere in costi di comunicazione ulterori. Altrimenti, in caso di risultato valutato in modo insoddisfacente dall'utente, verrà eettuata un'ulteriore ricerca dei peer potenzialmente utili, in modo da ottenere un insieme di query result costruiti sulla base degli indici di diversi peer della rete. Tale ricerca è basata su una PeerList Request, la quale prevede che, per ciascun termine che è presente all'interno della query formulata, venga eettuata una ricerca specializzata. In questo modo è possibile trovare il best peer associato a ciascun termine e costru-

65 CAPITOLO 6. MINERVA: UN WSE P2P BASATO SU DOCUMENT PARTITIONING 64 ire una lista dei peer (PeerList) potenzialmente utili per la valutazione dell'intera query iniziale. Quest'ultimo passaggio viene denominato query routing e verrà illustrato in modo più dettagliato nelle sezioni successive del capitolo; 2. una volta che si ha a disposizione la PeerList sarà possibile inviare la query a ciascuno dei peer presenti in tale lista o ad un sottoinsieme della lista (ovvero verso i top-k peer). L'esecuzione della query originale sarà quindi ora riferita all'indice mantenuto da ciascuno di tali peer; 3. una volta ottenuto un insieme di risultati parziali relativi alla query iniziale, valutata su ciascun peer della PeerList costruita nello step 1, si potrà eettuare il loro merging in modo da inviare una risposta globale al query initiator (l'intera fase prende il nome di query merging). Nel progetto MINERVA è stata particolarmente studiata la fase di query routing, come evidenziato in [2], [4], [5]. In particolare, nel momento in cui viene inoltrata una PeerList Request, la selezione dei peer più promettenti non si basa su una mera valutazione della qualità dei dati posseduti, come la freschezza e la dimensione dell'indice. E' stato infatti proposto in [2] un approccio che permette di eliminare dalla ricerca quei peer che non forniscono informazioni addizionali rispetto a quelle di cui già si dispone. In questo modo, mescolando tra di loro i diversi parametri di stima, è possibile ottenere dei buoni risultati di richiamo, diminuendo drasticamente il numero di peer da contattare. Un'altra linea guida del progetto si basa sulla possibilità di inserire altre informazioni accessorie per migliorare l'intera fase di routing. Ad esempio, è possibile includere i bookmarks degli utenti della rete: in questo modo, ciascun nodo avrà un elenco di bookmarks associato e nel momento in cui si eettuerà il query routing, ci si potrà indirizzare verso un peer il cui elenco risulti avere tematiche correlate a quelle della query (risulta evidente come l'idea di condivisione di tematiche/interessi si sposi perfettamente con un approccio collaborativo oerto da una rete P2P). 6.3 Query routing in MINERVA Nel caso in cui un utente valuti in modo insoddisfacente i risultati di una query, ottenuti mediante una ricerca relativa al solo indice del query initiator, viene inviata una PeerList Request verso la directory distribuita. In questo modo si passa ad una ricerca dei peer più promettenti a cui inviare la query. Questa lista dovrà però essere ltrata, calcolando i peer promettenti per l'intera query (tale fase può essere ad esempio eettuata mediante una semplice intersezione delle PeerList associate a ciascun query term) e inoltrando ad essi la query originale.

66 CAPITOLO 6. MINERVA: UN WSE P2P BASATO SU DOCUMENT PARTITIONING 65 Il processo di derivazione della PeerList globale ottimale per l'intera query e il conseguente invio della query a tali peer prende il nome di query routing. In letteratura sono presenti diversi lavori a riguardo, per lo più basati su metodi statistici e su indicatori tipici dell'information Retrieval. E' stato però dimostrato in [4] come le tecniche introdotte da questi studi lavorino bene nel caso di collezioni di dati disgiunte, ma risultino essere poco adabili nel momento in cui si operi in un contesto dove vi sono diversi peer indipendenti tra loro. Perciò è stato proposto in [2], [4], [5] un approccio di query routing specializzato, basato su insiemi di riassunti statistici compatti Collection Selection in ambito P2P Collection Selection è un ramo di ricerca dell'information Retrieval distribuito, molto attivo negli ultimi anni, il cui obiettivo è quello di poter eettuare una selezione di un sottoinsieme di collezioni che contengano documenti rilevanti per una certa query. Solitamente come supporto a queste tecniche di Retrieval vengono utilizzate delle informazioni statistiche pre-calcolate: esse sono impiegate come stimatori della qualità attesa dei risultati associati a dierenti collezioni, da cui poter identicare la risorsa più promettente relativamente ad una certa informazione. Un obiettivo basilare resta sempre la minimizzazione del numero di collezioni impiegate per l'ottenimento di un insieme di risultati di qualità. L'introduzione e lo sviluppo delle reti P2P ha portato ad una estensione delle tecniche di Collection Selection, rivedendo le proprie caratteristiche in funzione di un contesto mutevole e altamente decentralizzato come quello P2P. Ciò deriva, ad esempio, dall'assenza di indici centrali e dalla dicoltà di computazioni globali, rendendo quindi gli approcci tipici di Collection Selection meno precisi e potenti. Uno studio condotto e presentato nel lavoro [16] ha introdotto una nuova tecnica per la stima di una collezione specica per una certa query, sfruttando un nuovo modo di combinare una metrica di stima della qualità basata su stimatori di coincidenza. L'obiettivo è quello di poter costruire ricerche distribuite su larga scala adabili, rifacendosi ad un approccio di Collection Selection classico, denominato CORI CORI Collection Selection Uno degli approcci Collection Selection più noti è CORI [16]. In CORI la similarità tra una query e un insieme di collezioni di documenti noti viene calcolata fornendo un ordine, utilizzabile in seguito per inviare la query a ciascuna collezione. In questo modo è possibile ricercare un insieme di documenti

67 CAPITOLO 6. MINERVA: UN WSE P2P BASATO SU DOCUMENT PARTITIONING 66 top-ranked ed eettuare una successiva fase di merging dei risultati parziali ottenuti. La similarità di una query q rispetto ad una collezione c è data dalla somma delle probabilità che i query term appaiano nella collezione. Tale grandezza in CORI viene calcolata sfruttando la seguente formula: CORI(q, c) = ΣtɛQ c(db + (1 db) T c, t Ic, t q dove db è settato a 0.4, Tc,t è il peso del termine nella collezione, Ic,t è l'inverso delle frequenza della collezione e q è il numero di query term distinti. In particolare Ic,t viene così calcolato: Ic, t = log((n + 0.5)/ft) log(n + 1.0) mentre Tc,t viene calcolato in questo modo: T c, t = dt + (1 dt) log(fc, t + 0.5) log(maxc + 1.0) dove dt viene settato a 0.4 e maxc rappresenta il numero di documenti che contengono il termine più frequente nella collezione c. Per poter stimare la qualità attesa dei risultati di una collezione, CORI sfrutta quindi un insieme di statistiche aggregate, denominate anche misure per collection. In un ambito P2P si può pensare ad un collezione come all'indice locale di un peer e considerare ciascuna query come un insieme di termini (q = {t1, t2,..., tn}). In questo contesto CORI calcola lo score Si della collezione associata all'i-esimo peer Pi nel seguente modo: dove: Si = t q (Si, t) q Si, t = α + (1 α) T i, t Ii, t Il calcolo di Ti,t e Ii,t sfrutta il numero di peer nel sistema (indicato con np), la frequenza del termine t nei documenti della collezione i-esima (cdf) e la massima frequenza di ciascun termine t presente nei documenti della collezione i-esima (cdf max ): cdfi, t T i, t = V (cdfi, t [ i V avg ])

68 CAPITOLO 6. MINERVA: UN WSE P2P BASATO SU DOCUMENT PARTITIONING 67 Ii, t = [ log(np+0.5) cft ] [log(np + 1)] dove cft è il numero di peer che contengono il termine t. Come si evince dalle formule sopra introdotte, CORI considera la dimensione Vi del term space di un peer e lo space term medio V avg di tutti i peer che contengono un termine t. E' chiaro che in un contesto P2P risulta dicoltoso calcolare un indice medio attraverso tutti i peer della rete, per questo in [16] si è approssimato V avg sfruttando una media attraverso l'insieme delle collezioni elencate nelle PeerList Improving Collection Selection with Overlap Awareness L'idea di fondo che è stata utilizzata nel progetto [16] è di considerare degli stimatori di coincidenza come una componente essenziale per estendere quanto introdotto in CORI in un contesto distribuito a larga scala. Infatti negli usuali approcci di Collection Selection si cerca di stimare la rilevanza di una collezione rispetto una query, senza però considerare la coincidenza che si ha con collezioni utilizzate in precedenza. Più formalmente, ciò di cui si è interessati nell'approccio [16] quando si fa una stima della coincidenza, è la novelty (novità) di un peer rispetto ad una certa collezione di riferimento Cref. Ovvero, data una rappresentazione di un document space che è già stato precedentemente esplorato (ad esempio da altri peer per query precedenti), si stima il contributo che la collezione Ci del peer Pi può aggiungere a tale spazio: novelty = C i C i C ref La valutazione di tale grandezza risulta essere un problema di non semplice soluzione in un ambiente distribuito, perciò si deve ricorrere a diverse tecniche di ottimizzazione. Ad esempio, è stato introdotto in [16] uno schema di comunicazione che manda in piggybacking tutte le informazioni necessarie per il calcolo del fattore novelty. Per poter stimare la coincidenza tra collezioni, ciascuna collezione deve pubblicare un appropriato riassunto dei documenti che essa contiene. Perciò ciascun peer mantiene un riassunto compresso in un ltro di Bloom, facilmente accedibile e manipolabile, relativo al proprio indice. Prendendo come esempio un generico peer Pi, si può pensare ad una situazione in cui a tale peer è stata eettuata una PeerList Request. Quindi ad esso arriverà,

69 CAPITOLO 6. MINERVA: UN WSE P2P BASATO SU DOCUMENT PARTITIONING 68 per ciascun query term, un numero di Posts che contengono dei riassunti e il ltro di Bloom relativo ad un certo termine e ad un certo peer: {b,t1, b,t2,..., b,tr} per la query {t1,t2,..., tr} A questo punto è possibile sfruttare una proprietà dei ltri di Bloom, per cui per due ltri di uguale lunghezza e con le stesse funzioni hash, è possibile calcolare il ltro che ne rappresenta l'intersezione mediante un semplice AND logico (gura 27): Figura 27: intersezione di 2 ltri di Bloom Perciò, dato un ltro di Bloom che rappresenta il document space già consultato e un ltro per un dato peer, è possibile stimare il contributo (novelty) di ciascun peer Pi al query result. Infatti, confrontando il ltro bfi per il peer Pi, con l'unione bfcomb (bfcomb= j Sbfj) dei ltri associati ai peer precedentemente selezionati per query passate, si ottiene una stima di novelty: {k bf comb [k] = 0 bf i [k] = 1} con la formula sopra è possibile derivare il numero di bit che sono nel ltro di Pi ma non ancora in bfcomb. Analogamente è possibile denire la coincidenza tra bfcomb e il ltro di Bloom associato al peer Pi (come il numero di bit presenti in entrambi i ltri): {k bf comb [k] = 1 bf i [k] = 1} Lavorando con i ltri di Bloom esiste la nota possibilità di incontrare dei falsi positivi nell'analisi; allo stesso tempo, però, essi forniscono un buon compromesso con la riduzione di banda e di spazio occupato, da qui l'idea di utilizzarli nell'approccio proposto in [16]. Sempre nel lavoro [16] è stato introdotto uno schema algoritmico a 2 step: nel primo passo si eettua il rank di una data collezione sulla base di uno stimatore di qualità e in seguito si passa ad un nuovo rank della collezione, incorporando le informazioni di coincidenza tra coppie:

70 CAPITOLO 6. MINERVA: UN WSE P2P BASATO SU DOCUMENT PARTITIONING 69 L'algoritmo sopra proposto include una combinazione delle misure di qualità e di coincidenza, prendendo in input un insieme P di peer con score s[i] e un ltro di Bloom bf[i] per ciascun peer e sfruttando la formula: α quality[i] + (1 α) novelty[i] dove il parametro α è variabile(α = [0..1]). Mediante l'algoritmo proposto sotto è possibile invece eettuare una stima relativa alla misura della qualità di un peer i-esimo, presente in un insieme di peer:

71 CAPITOLO 6. MINERVA: UN WSE P2P BASATO SU DOCUMENT PARTITIONING 70 Inne, in [16] viene anche proposto un algoritmo che permette di calcolare una misura del contributo di ciascun peer. Esso sfrutta le funzioni newdocs() e olddocs(), che si rifanno alle formule precedentemente proposte per la stima del fattore novelty: newdocs(bf 1, bf 2 ) = {k bf comb [k] = 0 bf i [k] = 1} olddocs(bf 1, bf 2 ) = {k bf comb [k] = 1 bf i [k] = 1} In pratica si eettua una stima dei bit non presenti (o già presenti nel caso di olddocs) nei due ltri di Bloom analizzati: Prove sperimentali svolte in [16] hanno dimostrato che l'aancamento al classico approccio CORI di uno schema che possa determinare la coincidenza tra collezioni, garantisce buoni risultati. Infatti, è possibile ottenere dei valori di richiamo ssati con un numero di peer contattati drasticamente minore. In uno scenario P2P ciò risulta essere un risultato di grossa importanza, visti i costi e le latenze da sopportare in caso di eccessive comunicazioni tra i peer.

72 CAPITOLO 6. MINERVA: UN WSE P2P BASATO SU DOCUMENT PARTITIONING Analisi delle correlazioni esistenti tra query term in MINERVA Una caratteristica peculiare di MINERVA è la capacità del WSE di eettuare delle continue analisi statistiche ottenute da un monitoraggio delle query e dei comportamenti di ricerca degli utenti [4], [5]. In particolare, mediante l'analisi dei query log è possibile estrarre informazioni circa le correlazioni esistenti tra query terms. Per questo ciascun peer eettua delle analisi periodiche del proprio query log, sfruttando le tecniche classiche di mining. A supporto di ciò è anche possibile usare dizionari o thesauri, dove si potranno individuare combinazioni di termini correlati. Queste informazioni sono elaborate ed inserite all'interno di una directory distribuita, dove sia possibile eettuare delle inferenze e delle estrazioni di conoscenza. L'obiettivo è quello di determinare quali sono i peer che possiedono keywords con alta correlazione, molto utili per le risposte a query congiuntive. Mantenendo una struttura di tipo DHT ciascun peer sarà responsabile delle statistiche e dei metadati associati ad un sottoinsieme di termini random. Il metodo di funzionamento di MINERVA si basa sull'utilizzo della struttura DHT, la quale ritorna per un dato termine il peer responsabile, che mantiene una PeerList di posting (del tipo peer address - statistiche associate) per il termine in questione. Proprio le statistiche vengono usate per individuare il peer più promettente tra quelli disponibili, attingendo da informazioni come la dimensione della lista invertita associata ad un termine, ecc. Tale procedura viene attivata in seguito ad una PeerList Request, scaturita in seguito ad una valutazione da parte dell'utente di scarsa precisione dei risultati della query, costruiti solo sulla base dell'indice locale al peer contattato. Il processo di determinazione delle correlazioni esistenti tra termini mediante l'analisi delle query è basata su un utilizzo delle informazioni mantenute nei query log. Eettuando dei ltraggi e applicando delle tecniche statistiche, ciascun peer eettua delle analisi periodiche sui dati a disposizione nei log. I risultati di tali analisi verranno in seguito propagati verso gli altri peer, sfruttando delle tecniche di gossiping e rendendo ciascun peer responsabile anche dei termini correlati a quelli principali che esso già manteneva. L'informazione circa eventuali correlazioni tra termini estratta nei passaggi precedenti verrà quindi sfruttata in diversi modi: ˆ un primo metodo è quello di trattare tali dati come chiavi per l'overlay di tipo DHT: in questo modo mediante un semplice hashing sarà possibile, da parte del query initiator, individuare il peer responsabile associato, che fornirà la PeerList rappresentante l'insieme dei best peer per l'intera

73 CAPITOLO 6. MINERVA: UN WSE P2P BASATO SU DOCUMENT PARTITIONING 72 query. Esiste anche la possibilità, nel caso di una PeerList troppo corta, di suddividere la query in tutti i suoi termini e ottenere una PeerList per ciascuno di essi (denominata opzione fallback). Questa opzione però porta ad un aumento della latenza, dovuto al fatto che è necessario l'invio di un secondo messaggio; ˆ alternativamente viene sempre collezionata la PeerList associata ai termini che presentano alta correlazione, ma tale struttura dati viene associata al peer che è responsabile per il primo termine, secondo un ordinamento lessicograco dei termini stessi. In questo schema l'eventuale opzione di fallback della query viene gestita per intero dal nodo responsabile della PeerList stessa; ˆ il terzo ed ultimo caso considera quelle situazioni in cui non esistono informazioni circa eventuali correlazioni tra i termini di un'intera query, anche se la query stessa contiene delle coppie di termini o sottoinsiemi di termini che presentano alte correlazioni ed hanno delle entry all'interno della directory distribuita. Sotto queste ipotesi il query initiator contatterà tutti i peer responsabili delle diverse directory entry associate a ciascun termine della query, mandando in piggybacking l'intera query. Quando viene ricevuto il messaggio, ciascun peer decompone la query in diversi sottoinsiemi, al ne di testare la presenza di PeerList sucientemente lunghe associate a tali insiemi e ritorna le PeerList considerate più promettenti. La fase di decomposizione risulta essere un'operazione locale poco dispendiosa, data la grossa probabilità di lavorare con query costituite al massimo da cinque termini. E' inoltre chiaro che in questo caso l'opzione di fallback non viene prevista, dato che è automaticamente inclusa nella strategia stessa. 6.5 La fase di Peer Selection Per poter comprendere l'importanza delle analisi circa la presenza di eventuali correlazioni tra termini è utile analizzare la fase di Peer Selection di MINERVA [4]. Questo step può essere eettuato seguendo due approcci dierenti, i quali utilizzano o meno le informazioni di correlazione disponibili: ˆ approccio standard : la Peer Selection è ottenuta combinando le PeerList associate a tutti i termini presenti nella query; ˆ approccio full-query: in questo caso si sfruttano le statistiche associate a combinazioni di termini e si eettua una ricerca relativa dell'intera query. Prove sperimentali svolte in [4] hanno dimostrato che la seconda tecnica permette una drastica riduzione dei peer da contattare: ad esempio, ssando una

74 CAPITOLO 6. MINERVA: UN WSE P2P BASATO SU DOCUMENT PARTITIONING 73 soglia di richiamo pari al 50%, il primo approccio richiede che siano contattati 130 peer, mentre nel secondo caso si può ridurre tale numero a 45 (gura 28). Questi risultati sono essere di estrema importanza per l'applicabilità di un approccio di Web Search in ambiente P2P e testimoniano l'importanza dell'utilizzo di informazioni sulla correlazione dei termini all'interno del WSE MINERVA. Figura 28: prove sperimentali: risultati ottenuti

75 Capitolo 7 Tecniche di caching per il WSE MINERVA Una caratteristica peculiare che un WSE deve garantire è un alto livello di scalabilità, soprattutto in un ambito altamente distribuito e variabile come quello P2P. Ecco quindi che in questo contesto le politiche di caching rivestono un ruolo cruciale per garantire tale proprietà. Costruire una cache che permetta di rispondere a diverse query utente con dei risultati precedentemente memorizzati può portare a grossi miglioramenti nelle prestazioni del sistema di ricerca e ad una conseguente riduzione delle risorse spese per rispondere alle query utente. L'obiettivo di questo capitolo è quello di studiare delle possibili tecniche di caching utilizzabili nel WSE MINERVA, introdotto in precedenza. Verrà brevemente ripresa la struttura di MINERVA, al ne di illustrare alcune prime soluzioni di caching progettate dagli stessi sviluppatori di tale WSE ed utilizzate durante la fase di esecuzione delle query. In seguito si passerà a presentare un'ulteriore tecnica di caching per MINERVA, da utilizzare parallelamente alle precedenti soluzioni citate e che permetta di migliorare le prestazione globali di tale WSE. La soluzione proposta sarà illustrata sia sotto gli aspetti architetturali, che valutandone il funzionamento durante la fase di esecuzione di una query utente. 7.1 La struttura di MINERVA MINERVA è un WSE prototipo basato su un approccio di tipo Document Partitioning (si veda il capitolo 6 per una descrizione più dettagliata delle sue caratteristiche). Esso è strutturato in un contesto di tipo P2P, dove ciascun peer lavora su una porzione dell'intero set di documenti disponibili. Inoltre, è 74

76 CAPITOLO 7. TECNICHE DI CACHING PER IL WSE MINERVA 75 presente un overlay network di tipo DHT (Distributed Hash Table) per gestire un insieme di informazioni aggregate utilizzabili dai peer della rete in fase di costruzione del result set per una query utente (gura 29): Figura 29: struttura schematica del WSE MINERVA Sfruttando la struttura e le primitive oerte da DHT, è possibile mantenere una directory distribuita di informazioni e statistiche su cui poter fare delle inferenze e perciò utilizzabile in fase di risposta ad una query utente. Infatti, è possibile sfruttare due primitive come: ˆ insert (key, value) ˆ value retrieve(key) Il peer che si andrà a contattare manterrà una PeerList relativa al termine ricercato, utile per avere una traccia dei peer potenzialmente utili per la risposta a tale query. 7.2 Esecuzione di una query multiterm in MIN- ERVA Per poter studiare delle politiche di caching per il WSE MINERVA è indispensabile prendere in considerazione gli aspetti fondamentali del progetto. In particolare è necessario valutare il criterio seguito per gestire la fase di querying: si ricorda che ciascuna query multiterm formulata dall'utente viene prima eseguita localmente, sfruttando l'indice locale a disposizione del peer a cui è stata formulata l'interrogazione. Nel caso in cui l'utente valuti i risultati forniti in modo poco soddisfacente, è possibile inviare una PeerList Request, che

77 CAPITOLO 7. TECNICHE DI CACHING PER IL WSE MINERVA 76 permetterà di ottenere un insieme di risultati addizionali per la query, riferiti ai documenti mantenuti da alcuni peer della rete e quindi potenzialmente più precisi rispetto la risposta locale. Per poter eettuare una valutazione dei peer più promettenti, relativamente ad un insieme di termini presenti nella query, si sfruttano le analisi di correlazioni che intercorrono tra query term. Tali statistiche sono ottenute da delle analisi dei query log, eettuate periodicamente dai peer e che sfruttano le tecniche classiche di mining. Inoltre è possibile sfruttare altri insiemi di dati, come thesauri, dizionari, ecc. da cui poter estrarre insiemi di parole correlate. Tali analisi di correlazione tra termini sono poi utilizzate come: ˆ chiavi per l'overlay DHT, in modo da poter localizzare in modo diretto il peer responsabile che detiene una PeerList per l'intera query; ˆ traccia per poter mantenere insiemi di PeerList associate a combinazioni di termini caratterizzati dal possedere un'alta correlazione. Tali PeerList sono mantenute secondo un approccio basato sulla memorizzazione della lista all'interno della directory del peer responsabile per il primo termine secondo l'ordine lessicograco della query. In base alle caratteristiche illustrate l'intera fase di querying è perciò estesa introducendo la possibilità di sfruttare le PeerList Request da parte dell'utente per richiedere una qualità maggiore delle risposte fornite dal WSE per una certa query. Utilizzando una rappresentazione schematica si può quindi descrivere la fase di querying in MINERVA come fatto in gura 30, mettendo in evidenza i possibili step per l'esecuzione di una PeerList Request: Figura 30: esecuzione di una query in MINERVA (in evidenza l'esecuzione di una PeerList Request)

78 CAPITOLO 7. TECNICHE DI CACHING PER IL WSE MINERVA 77 Come è possibile osservare dalla gura 30, in caso di PeerList Request è possibile sfruttare l'analisi di correlazione tra termini in diversi modi (per chiarezza si è deciso di associare un nome a ciascuno dei tre possibili step): ˆ Key_DHT : il metodo più semplice è quello di sfruttare la struttura DHT, trattando le informazioni di correlazione come chiavi per l'overlay network ed utilizzando successivamente i mapping memorizzati per localizzare il peer responsabile. In questo modo sarà possibile ottenere, dal peer localizzato mediante DHT, una PeerList per l'intera query. Inoltre è possibile eettuare il fallback della query, ovvero valutare ciascun query term in maniera separata, eettuando una successiva intersezione delle PeerList ottenute ed associate a ciascun termine ricercato; ˆ Twist directory: una variante allo schema precedentemente proposto prevede una modica nello schema di memorizzazione delle PeerList nelle directory. In particolare, si terrà traccia delle PeerList associate a combinazioni di termini che presentano un'alta correlazione, mappando ogni lista sul peer responsabile del primo termine, secondo un ordinamento lessicograco dei termini stessi. In caso di fallback, sarà tale peer a gestire l'intera fase di scomposizione in singoli termini della query, diminuendo la latenza rispetto allo schema illustrato precedentemente; ˆ Query ooding: l'ultima soluzione proposta è utilizzabile nel caso in cui non si disponga di un'alta correlazione tra i termini presenti in un'intera query, ma la query contiene coppie di termini o sottoinsiemi di termini che presentano alta correlazione e sono memorizzati in DHT. In tali casi il query initiator a cui è giunta della Peer List Request contatta tutti i peer responsabili dei diversi termini della query, mandando in piggybacking a ciascuno l'intera query. Ottenuto tale messaggio, ciascun peer provvede a decomporre la query in sottoinsiemi e verica se dispone di una PeerList per uno o più di questi sottoinsiemi. In caso aermativo ritornerà al query initiator tali liste. In questo caso l'opzione di fallback non è prevista, dato che è automaticamente inclusa nella strategia presentata. E' interesante osservare come DHT venga utilizzato in ciascuna delle tre possibili tecniche illustrate per risolvere una PeerList Request. Proprio l'utilizzo di DHT e la memorizzazione di insiemi di PeerList per insiemi di termini correlati, mette in evidenza il fatto che si sia puntato sull'introduzione di una tecnica di caching per risolvere le PeerList Request. Tale tecnica prevede appunto l'utilizzo di liste di riferimenti a peer, che sono potenziali candidati per fornire dei risultati addizionali alla query trattata.

79 CAPITOLO 7. TECNICHE DI CACHING PER IL WSE MINERVA 78 Partendo da questo punto si è perciò deciso di aancare un'ulteriore tecnica di caching per il WSE MINERVA, che però preveda la memorizzazione di query result. Tali risultati saranno utilizzabili da ciascun peer per rispondere alle query inviate e per poter fornire dei risultati globali (riferiti quindi agli indici di diversi peer del sistema) a PeerList Request pervenute. L'introduzione di una cache di risultati porta ad una diminuzione dei tempi di computazione delle risposte, rispetto una cache di PeerList, dato che in caso di hit si ha a disposizione un insieme di query result per la query cercata, senza dover necessariamente eettuare gli accessi agli indici dei peer potenzialmente utili (best peer). D'altro canto in una cache di query result si ha una peggior gestione dello spazio di cache, visto che una pagina di query result occupa molto più spazio di memorizzazione rispetto una semplice PeerList. 7.3 Strategie di caching per WSE In questa sezione vengono proposti due lavori di ricerca particolarmente interessanti, che hanno introdotto due nuove strategie di caching per WSE. L'obiettivo comune è quello di introdurre una strategia di caching più eciente della tecnica LRU (Least Recently Used), al ne di ottenere delle prestazioni migliori. Infatti LRU sfrutta solamente delle statistiche dinamiche rispetto la freschezza dei riferimenti memorizzati, senza appoggiarsi a delle analisi più complesse, che porterebbero ad un miglioramento nelle prestazioni del sistema di caching. Da ciò è nato il progetto Static Dynamic Cache [8] e in seguito il progetto Admission Policies [23], che può essere visto come una generalizzazione, di più semplice gestione, del primo lavoro. In entrambi i progetti [8], [23] si sono utilizzate queste due strategie per la progettazione di una cache centralizzata che risieda nella macchina broker e che quindi intercetti le richieste verso il WSE provenienti dagli utenti. Sarebbe perciò interessante poter utilizzare tali approcci nella costruzione di un sistema di caching P2P per MINERVA, al ne di valutarne la loro l'applicabilità in un ambito distribuito e P2P Il progetto Static Dynamic Cache Recentemente è stata proposta una strategia di caching particolarmente interessante e denominata Static Dynamic Cache (SDC) [8]. Originariamente nel lavoro [8] è stato utilizzato un WSE, basato sull'approccio document partitioning, nella quale si era introdotta una cache centralizzata che intercettasse le richieste in arrivo dagli utenti ed indirizzate al WSE. Nulla vietà però di poter progettare un WSE equivalente ma basato sull'approccio term partitioning, che sfrutti la strategia di caching introdotta in [8].

80 CAPITOLO 7. TECNICHE DI CACHING PER IL WSE MINERVA 79 In tale lavoro sono stati utlizzati un insieme di principi e tendenze emersi da analisi approfondite dei query log e che hanno portato alla costruzione di una cache semistatica. Tali tendenze possono essere così elencate: 1. molte query sottomesse ai motori di ricerca sono condivise da utenti differenti. Esistono quindi query che si ripetono con un'alta regolarità; 2. è presente una località spaziale tra gli stream di query processate; 3. è presente una località temporale tra gli stream di query processate; Queste proprietà sono utilizzate per implementare una strategia di caching denominata SDC, che permetta di sfruttare in modo eciente tali proprietà presenti negli stream di query processate. In questo modo si vogliono ottenere dei miglioramenti nelle prestazioni, rispetto l'utilizzo di una politica di replacement classica, come LRU. In LRU infatti si utilizzano solamente delle statistiche dinamiche rispetto alla freschezza dei riferimenti, come base per la gestione delle politiche di rimpiazzo dei blocchi. Per ottenere tale obiettivo, in SDC viene eettuata un'interessante suddivisione in fase di caching: ˆ SDC estrae dai dati relativi alle query recentemente sottomesse le interrogazioni più frequenti e le immagazzina in una porzione di cache statica, con proprietà read-only. Proprio quest'ultima proprietà permette di aumentare il valore del throughput parallelo, dato che gli accessi ad una regione di memoria in sola lettura possono avvenire senza sincronizzazioni. La parte statica contiene un insieme di entry associato alle query maggiormente frequenti nel passato. In [8] viene giusticato questo approccio sostenendo che le query più popolari sottomesse ai WSE non cambiano in modo frequente nel corso del tempo (e quindi possono risiedere a lungo in cache). Comunque questa porzione della cache SDC viene periodicamente re-freshata, sulla base dei dati di utilizzo del WSE disponibili; ˆ Le altre entry della cache vengono gestite in modo dinamico e saranno impiegate per tutte quelle query che non saranno soddisfatte dalla porzione statica di SDC. La gestione della cache dinamica introdotta in [8] utilizza un insieme di politiche dierenti (LRU, SLRU, ecc.) per la sostituzione degli elementi memorizzati. Nel momento in cui viene formulata una query verrà fatto un controllo circa la possibilità di un match con qualche risultato presente nell'insieme statico della cache SDC e nel caso in cui la richiesta non sia stata soddisfatta, si invierà la richiesta alla parte dinamica della cache. In particolare, nel lavoro [8] la cache SDC è stata inserita all'interno della macchina broker, ovvero la macchina che fa da tramite tra l'interfaccia del WSE e il nucleo del motore di ricerca stesso.

81 CAPITOLO 7. TECNICHE DI CACHING PER IL WSE MINERVA 80 Inoltre è stata fatta una suddivisione della cache in una parte che memorizza pagine HTML intere ritornate all'utente (HTML cache) e una parte che semplicemente memorizza un vettore di DocID (DocID cache). SDC sfrutta un approccio server-side e un punto chiave per il progetto è stato utilizzare tre diversi query log (Excite, Tiscali, Alta Vista) come base per la determinazione delle statistiche di utilizzo. Esse hanno dimostrato quanto era stato ragionevolmente supposto, ovvero: la dimensione ottimale della cache statica dipende dal query log considerato. Comunque, un valore vicino a 0.7 (dove 1.0 indica una cache completamente statica ) risulta essere un buon compromesso per qualunque cache; le query più popolari sono soddisfatte dalla porzione statica. Le burst query sono invece trattate dalla parte dinamica della cache. Esse sono tutte quelle query che sono frequenti solo per un breve periodo di tempo e che quindi non giusticano l'introduzione di complesse politiche per la sostituzione dei blocchi di cache. Sempre attraverso le prove sperimentali eettuate in [8] sono emerse interessanti considerazioni in merito al fatto che i query log presentano una località temporale, dovuta al fatto che una query richiesta in precedenza avrà grosse probabilità di essere richiesta nel futuro, oltre ad una meno marcata località spaziale. La località temporale risulta essere alta per i query log di Tiscali ed AltaVista, mentre è più bassa per Excite, anche a causa dell'anzianità di quest'ultimo log. Per quanto riguarda la località spaziale è necessario evidenziare il fatto che essa è dierente rispetto al concetto classico di località spaziale in caso di cache di dati: nei WSE essa signica che, dopo aver ottenuto una pagina di risposta in merito alla query formulata, l'utente richiede una nuova pagina collegata a quella precedente e in un breve lasso di tempo Politiche di prefetching adattivo in Static Dynamic Cache Osservando la presenza di località spaziale nei query log, è stata proposta in [8] una strategia di prefetching adattivo che anticipa la richiesta dell'utente delle pagine successive. In questo modo è possibile ottenere un aumento dell'hit ratio complessivo, senza dover introdurre un eccessivo overhead. Più formalmente, quando la cache riceve una query del tipo (keywords, page_no) e la pagina corrispondente non è presente, viene inviata una query espansa (keywords, page_no, k), che richiede le k (k 1 è il fattore di prefetching) pagine consecutive a partire dalla pagina page_no. Prove sperimentali in [8] dimostrano che tale tecnica porta ad un miglioramento dell' hit ratio (no al 50%), anche se il valore

82 CAPITOLO 7. TECNICHE DI CACHING PER IL WSE MINERVA 81 k non può crescere all'innito, dato che esiste una probabilità da considerare nell'accesso alle pagine pre-fetchate. Addirittura, in caso di cache di piccole dimensioni, il prefetching può portare ad un degrado delle prestazioni, visto che inuisce negativamente sulla politica di sostituzione dei blocchi in cache e che aumenta il carico nel WSE, degradando il throughput. Per rendere la tecnica del prefetching conveniente, in [8] è stato introdotto un approccio euristico, secondo il quale conviene pre-fetchare un numero limitato di pagine, solo nel caso in cui il cache miss dipenda da una richiesta ad una pagina diversa dalla prima. Tale approccio risulta essere un buon trade-o tra la massimizzazione dei beneci del prefetching e la riduzione dei carichi addizionali per il WSE Risultati e possibili sviluppi futuri del progetto Static Dynamic Cache Dividendo il query log in una porzione che funge da training set ed in una che rappresenta un test set, è stato possibile dimostrare in [8] che la freschezza dei dati contenuti nella cache statica non rappresenta un grosso problema e che la presenza della cache dinamica per le query burst (ovvero le query meno frequenti) porta ad un netto miglioramento delle prestazioni. Inoltre, è stata dimostrata un'interessante tendenza secondo la quale alcuni gruppi di query sono particolarmente presenti/assenti in certi periodi della giornata. Proprio quest'ultima osservazione può essere uno spunto interessante per proporre una strategia di popolamento della cache statica in modo oculato. Infatti, sarebbe possibile costruire un modulo che permetta di inserire nella porzione statica della cache dei risultati dierenti a seconda del momento della giornata in cui ci si trova. In questo modo, si potrebbero risolvere query particolarmente presenti nel lasso giornaliero in cui si opera, diminuendo i cache miss e migliorando la gestione dello spazio di cache. Tale modulo potrebbe essere, ad esempio, un sistema software che lavora parallelamente alla query e che eettua delle analisi statistiche sui dati dei query log disponibili. Attraverso una valutazione delle tendenze orarie giornaliere è possibile eettuare dei rimpiazzi dei blocchi di una parte della cache statica, mantenendo in una parte della cache le query maggiormente frequenti e sfruttando l'altra parte per query frequenti solo in alcuni e limitati periodi giornalieri Il progetto Admission Policies Negli ultimi mesi è stato presentato un lavoro di ricerca che ha introdotto una strategia di caching che generalizzi quella introdotta nel lavoro [8] (SDC). Come nel caso di SDC, si è introdotta questa strategia per gestire una cache centralizzata presente nella macchina broker di un WSE, che intercetti le richieste in

83 CAPITOLO 7. TECNICHE DI CACHING PER IL WSE MINERVA 82 arrivo, garantendo però una gestione più semplice rispetto a quella possibile con l'utilizzo di SDC. Nell'articolo correlato [23] è stata infatti presentata una strategia di caching completamente dinamica e basata su delle politiche di Admission Policies, a supporto delle decisioni relative al caching dei query result trattati. In particolare, l'introduzione di tali politiche di Admission ha l'obiettivo di evitare l'introduzione in cache di query poco frequenti, che possono portare ad una fase di pollution della cache ed ad una conseguente diminuzione delle prestazioni. L'implementazione è basata perciò sulla presenza di uno stimatore che permetta di predire se una query possa essere catalogata come poco frequente o come query frequente e quindi come un potenziale hit futuro. Lo stimatore si appoggia su due possibili tipi di analisi, così catalogate: ˆ stateless feature: sono tutte quelle proprietà che possono essere analizzate senza bisogno di utilizzare statistiche in merito al query log passato, sfruttando semplicemente lo stream di query attuale. Proprio per questa proprietà sono catalogate come feature di basso costo, facili da ottenere e che non richiedono l'utilizzo di spazio di memorizzazione extra. Un esempio di stateless feature viene dall'analisi della lunghezza di ciascuna query, proprietà che può permettere di discriminare da una query che può presentarsi con alta frequenza o meno; ˆ stateful feature: sono delle proprietà che si appoggiano su un insieme di informazioni di tipo storico sull'utilizzo del WSE da parte degli utenti. Esse richiedono, in generale, dello spazio extra di memorizzazione, dato che si appoggiano su insiemi di dati statistici estratti dai query log passati oltre che un costo maggiore per via della necessità di collezionare dati statistici. Nella grande maggioranza dei casi le stateful feature si appoggiano a valutazioni circa la frequenza di occorrenza delle query passate e necessitano di opportune politiche di refresh ad intervalli regolari. Come detto precedentemente, il nuovo approccio introdotto generalizza SDC, dividendo la memoria allocata per il caching in due porzioni: ˆ porzione controlled : dove vengono inserite tutte quelle query che lo stimatore cataloga come frequenti e quindi come futuri hit per la cache. Si sfrutta una politica di sostituzione dei dati di tipo LRU e rappresenta la porzione statica dell'approccio SDC; ˆ porzione uncontrolled : dove si inseriranno le rimanenti query catalogate come meno frequenti o che appaiono solo in piccoli burst, come nella porzione dinamica di SDC; anche in questa porzione si sfrutta una politica di sostituzione di tipo LRU per i blocchi inseriti in cache.

84 CAPITOLO 7. TECNICHE DI CACHING PER IL WSE MINERVA 83 L'approccio proposto generalizza perciò SDC, rendendo la porzione controlled (ovvero la porzione statica di SDC) più essibile e completamente dinamica. SDC diventa un caso speciale del nuovo sistema, dove la porzione controlled verrebbe resa completamente statica. Inoltre Admission Policies rappresenta una tecnica di caching apparentemente di più semplice gestione rispetto SDC, dato che presuppone l'utilizzo di insiemi di analisi sulle query più semplici e senza la necessità di dover necessariamente mantenere traccia di statistiche passate, oltre a non dover gestire il vincolo rappresentato dalla presenza di una porzione statica di cache. Le prove sperimentali svolte nel lavoro [23] hanno dimostrato che l'approccio che sfrutta delle politiche di Admission permette di ottenere delle prestazioni (misurate solamente in termini di hit ratio totale) quasi equivalenti a SDC, nel caso in cui si usino delle stateless feature ed ad ottenere dei miglioramenti prestazionali se si sfruttano delle stateful feature. Sarebbe perciò interessante valutare se tale tendenza risulti essere rispettata anche in un ambito distribuito e P2P, in modo sia da poter vericare l'applicabilità dell'approccio Admission Policies P2P, che per poter osservare se esistono dei sistemi di caching, istanze di Admission Policies P2P, che forniscono prestazioni migliori di sistemi basati su SDC P2P. 7.4 Una nuova tecnica di caching per MINERVA Come visto nella sezione precedente, MINERVA prevede l'introduzione di tecniche di caching sfruttate nel momento in cui sia inviata una PeerList Request per una query. Queste soluzioni di caching possono essere estese, al ne di migliorare ulteriormente le prestazioni di tale WSE. In questa sezione verrà perciò descritta un nuova tecnica di caching, da aancare a quello prevista in MINERVA, che prevede la memorizzazione di query result per rispondere alle query e alle PeerList Request formulate. Tale tecnica si basa perciò sull'introduzione di un sistema di caching, che prevede l'utilizzo combinato di una cache locale per ciascun peer della rete e di una cache globale distribuita, che sfrutta un apposito overlay network basato su una struttura DHT. Inoltre verranno utilizzate le due strategie di caching precedentemente illustrate (SDC e Admission Policies). Per ottenere maggior chiarezza nella descrizione, nelle prossime sezioni verranno prima illustrate le caratteristiche del sistema di caching in cui si usa SDC, per poi passare ad illustrare le proprietà del sistema in cui si sfrutta l'approccio Admission Policies.

85 CAPITOLO 7. TECNICHE DI CACHING PER IL WSE MINERVA Sistema di caching SDC-P2P Il sistema di caching SDC-P2P si basa sull'utilizzo, per ciascun peer Pi, di due porzioni di cache: ˆ una cache locale, denominata LCH i, che conterrà dei query result locali al peer e quindi costruiti mediante l'esclusivo utilizzo dell'indice locale al peer Pi; ˆ una cache globale distribuita tra i peer. Perciò il peer Pi disporrà di una propria porzione di cache globale, denominata GCH i, la quale conterrà dei query result globali, ottenuti mediante gli indici di diversi peer del sistema. Le diverse porzioni di cache globale distribuita sono collegate tra loro mediante l'utilizzo di un Cache Overlay Network, denominato CON e basato su una struttura DHT. In questo modo i dati globali presenti saranno accedibili da ogni peer presente nel sistema. Gracamente si può riassumere la struttura di SDC-P2P come fatto in gura 31: Figura 31: un nuovo sistema di caching per MINERVA: SDC-P2P La cache locale progettata viene utilizzata in seguito all'invio della query ad un certo peer, in modo da poter fornire direttamente dei query result per la query. Prendiamo come esempio una situazione in cui al peer Pi arrivi una query utente q. Il peer eettuerà una prima ricerca nella cache locale LCHi di un insieme di query result per q e, se presenti, verranno ritornati all'utente come risposta per q. In caso di miss nella cache LCHi si passerà al normale schema di esecuzione di MINERVA, che prevede la ricerca nell'indice locale del peer Pi.

86 CAPITOLO 7. TECNICHE DI CACHING PER IL WSE MINERVA 85 La cache globale distribuita sarà invece utilizzabile in seguito all'invio di una PeerList Request, in modo da poter fornire all'utente dei query result computati mediante gli indici di diversi peer della rete. In quest'ultimo caso la localizzazione dei query result per una query q viene eettuata mediante una duplice indirezione: la prima indirezione prevede l'individuazione, mediante una struttura DHT, di un puntatore ad un peer, usato per la seconda indirezione, che permette di individuare i query result per q. Supponiamo uno scenario in cui al peer Pi arrivi una PeerList Request per la query q. Lo schema di esecuzione prevede una fase di lookup nella cache globale distribuita: mediante DHT il peer Pi ottiene l'indirizzo del peer Pj, il quale manterrà dei dati globali nella propria cache GCHj. Tali dati saranno quindi inviati a Pi, che li proporrà in output all'utente che aveva inviato una PeerList Request per q. Gracamente si ha la situazione riportata in gura 32: Figura 32: esecuzione di una PeerList Request usando la cache globale distribuita La scelta di utilizzare questa doppia indirezione in SDC-P2P può sembrare complicata e dispendiosa. In realtà la prima indirezione prevede un utilizzo di DHT, che sfrutta il protocollo Chord per mappare i riferimenti attraverso i peer della rete. Grazie all'uso di Chord si ha una garanzia circa l'uniformità nella distribuzione dei riferimenti tra i peer, visto l'utilizzo di un'apposita funzione hash SHA-1. Inoltre in questo primo accesso i messaggi scambiati prevedono l'invio di riferimenti, perciò dei dati molto meno pesanti rispetto una pagina di query result, garantendo quindi un'ottimizzazione nel riempimento dello spazio disponibile nella cache globale distribuita.

87 CAPITOLO 7. TECNICHE DI CACHING PER IL WSE MINERVA La cache locale di SDC-P2P La cache locale di SDC-P2P prevede la presenza di una memoria cache associativa per ciascun peer, ed è la prima componente che viene contattata nel momento in cui arriva una query utente. Nel caso in cui la cache del peer contattato contenga dei query result utili in merito alla query, si potrà disporre di una risposta immediata da proporre all'utente. Tali risultati saranno costruiti sulla base dell'indice locale del peer. La tecnica di caching proposta prevede, in caso di PeerList Request, un'accesso ad una struttura DHT per ottenere il riferimento ad un peer che detiene, nella propria porzione di cache globale distribuita, dei dati globali utili. E' chiaro che un'accesso a DHT comporta un costo sia in termini di latenze, che di messaggi scambiati tra DHT e i peer coinvolti. Si è perciò deciso di estendere la struttura della cache locale ed eettuare la memorizzazione dei riferimenti che vengono ottenuti mediante DHT a seguito dell'invio di una PeerList Request. Ad esempio, supponiamo che al peer Pi venga inviata una PeerList Request per la query q. DHT fornisce l'indirizzo del peer Pj, che mantiene nella cache GCHj i query result globali per q. In seguito a tale accesso il peer Pi memorizzerà nella propria cache locale LCHi il riferimento a Pj. In questo modo una successiva PeerList Request per q inviata a Pi, sarà eseguita senza dover accedere a DHT, dato che si dispone già di un riferimento valido per tale query. La cache locale di ogni peer è stata progettata utilizzando un partizionamento statico/dinamico, seguendo lo schema introdotto dal progetto Static Dynamic Cache (SDC) [8]. In questo modo la cache locale dispone di una porzione statica, di tipo read-only, dove inserire i query result associati alle query che risultano essere più frequenti, relativamente al query log locale ed una dove inserire i rimanenti query result e i riferimenti ottenuti da DHT in seguito all'arrivo di una PeerList Request. Per la porzione dinamica è stata utilizzata una politica di sostituzione dei blocchi della cache, in modo da poter gestire la scelta di eventuali blocchi da sostituire a favore di nuovi dati da inserire in cache. La scelta proposta prevede l'utilizzo di una politica di sostituzione LRU (Least Recently Used), che nel caso di sostituzione di un blocco precedentemente memorizzato, seleziona il dato riferito meno recentemente. La struttura risultante della cache locale di ciascun peer della rete è perciò equivalente a quella rappresentata in gura 33:

88 CAPITOLO 7. TECNICHE DI CACHING PER IL WSE MINERVA 87 Figura 33: struttura della cache locale del peer Pi Come è possibile osservare dalla gura 33, la cache locale del peer Pi prevede una porzione in cui verranno inseriti i query result ottenuti esclusivamente dall'indice locale di Pi (suddivisa in una parte statica e una parte dinamica) e una seconda porzione utilizzata per inserire i riferimenti ottenuti in seguito a delle PeerList Request pervenute a Pi (esclusivamente a livello dinamico) La cache globale di SDC-P2P Se l'utente valuta in maniera negativa i risultati forniti dal peer contattato relativamente ad una query, viene inviata una PeerList Request verso il peer stesso. Essa porterà all'individuazione di un insieme di risultati supplementari, ottenuti dagli indici di un insieme di peer potenzialmente utili per rispondere alla query formulata. In questo caso è necessario introdurre delle politiche di caching ad-hoc, in quanto la fase di ricerca a livello dell'intera rete per una query può essere un'operazione molto dispendiosa e poco scalabile. In MINERVA è stata introdotta una prima tecnica di caching da utilizzare in seguito ad una PeerList Request. Essa prevede la memorizzazione di PeerList per coppie di termini che presentano un'alta correlazione. Partendo da questo punto si è deciso di introdurre nel sistema SDC-P2P una cache globale e distribuita tra i peer, che permetta di fornire in modo immediato un insieme di query result globali (costruiti mediante gli indici di diversi peer della rete) per una query soggetta a PeerList Request. Il funzionamento della cache globale distribuita si basa su un primo processo di localizzazione, mediante DHT, di un puntatore ad un peer che, nella propria porzione di cache globale, disponga di un insieme di query result globali per la query ricercata. A livello architetturale si è deciso di eettuare una ripartizione della cache globale distribuita in due porzioni: una porzione statica e una porzione dinamica. Riprendendo l'idea introdotta nella tecnica SDC [8], ed impiegata anche per la cache locale, si è pensato di utilizzare una porzione statica, di tipo readonly, ove memorizzare le query più frequenti nel query log locale e una porzione

89 CAPITOLO 7. TECNICHE DI CACHING PER IL WSE MINERVA 88 dinamica, dove andranno inserite le rimanenti query. La porzione dinamica prevede l'utilizzo di una politica di sostituzione dei blocchi LRU (Least Recently Used). A livello graco la porzione di cache globale distribuita del peer Pi (GCHi) può essere rappresentata come in gura 34: Figura 34: struttura della cache globale del peer Pi Cache Overlay Network La cache globale distribuita di SDC-P2P prevede l'introduzione di un Cache Overlay Network con struttura DHT (Distributed Hash Table), denominato CON ed indipendente dalla struttura DHT presente in MINERVA. Introducendo un overlay specializzato per la cache è possibile rendere le diverse porzioni di cache globale distribuita collegate e comunicanti tra loro. Mediante DHT ogni peer sarà in grado di individuare la presenza di una porzione di cache globale distribuita, che mantenga dei query result per una query soggetta a PeerList Request. Per eettuare tale operazione sarà suciente invocare un'azione di lookup, nella quale si eettua il calcolo dell'hash della query passata, ottenendo quindi l'indirizzo del peer che manterrà nella propria porzione di cache globale dei query result per la query. Oltre ad un'azione di lookup è necessario prevedere la possibilità di inserire e rimuovere dei riferimenti gestiti mediante DHT. Per fare ciò è necessario introdurre le primitive insert e delete. Quindi, riassumendo, CON prevede l'utilizzo delle seguenti primitive: ˆ peer-id lookup (q): passando una query q in input è possibile ottenere l'indirizzo peer-id, relativo al peer che mantiene nella propria porzione di cache globale distribuita dei query result per q; ˆ insert (q, peer-id): passando in input una query q è possibile con tale primitiva inserire un nuovo riferimento per q. Si passerà quindi all'individuazione, mediante il calcolo dell'hash di q, dell'indirizzo peer-id, riferito al peer che detiene la porzione di cache globale distribuita dove saranno memorizzati i query result per q;