Indici per Big Data
Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
Elaborato finale in Basi di Dati
Indici Per i Big Data
Anno Accademico 2012/2013
Candidato:
Luca Cangiano
matr. N46/657
1
Indici per Big Data
2
Indici per Big Data
Indice
Introduzione
4
Capitolo 1. L’era dei Big Data
6
1.1
1.2
1.3
1.4
Big Data nel Mondo
Big Data in Database World
Big Data in System World
Big Data Oggi
6
7
8
10
Capitolo 2. Parallel Database System e Hadoop System
11
2.1
2.2
2.3
Parallel Database System
Hadoop System
Pro e contro di un’architettura Hadoop
Capitolo 3. Indici per Big Data
3.1
3.2
3.2.1
3.3
3.4
Conclusioni
Bibliografia
Indici Primari e Secondari
Il CG-index
B+-tree
Architettura di un Sistema Cluster
Risoluzione delle Query
11
12
13
14
14
15
16
17
19
22
23
3
Indici per Big Data
Introduzione
“What is Big Data?”
“A meme and a marketing term, for sure, but also shorthand for advancing trends in
technology that open the door to a new approach to understanding the world and making
decisions.”[1]
Il termine Big Data, sicuramente abusato nelle moderne strategie di mercato, indica grandi
aggregazioni di dati, che non possono essere processati o analizzati con i tradizionali processi
e strumenti di analisi. I Big Data aprono le porte verso nuovi modi di percepire il mondo e di
prendere decisioni.
Si è cominciato a parlare di “Big Data” intorno al 1970, poi il problema si è ripresentato più
urgente che mai nel 2000, quando i cambiamenti spinti dal Web hanno portato sviluppatori e
colossi mondiali come Google, Yahoo!, Amazon, Facebook, e altri, a sviluppare nuove
architetture di “storing,accessing and analyzing” dei “Big Data”.
In questo elaborato viene aperta una finestra sul mondo dei Big Data e su come questi abbiano
cambiato profondamente le dinamiche economiche e sociali dei nostri tempi.
Cercheremo dunque di capire come il mondo ha reagito a questa nuova sfida, per poi
concentrare la nostra attenzione sulle tecniche d’indicizzazione sviluppate per grandi quantità
di dati.
Dato un insieme di dati di grandi dimensioni, infatti, è spesso necessario eseguire ricerche che
soddisfino un criterio specifico.
Nel corso dell’analisi dei dati, questo tipo di ricerche è ragionevole che accada ripetutamente e
la scansione dell'intero set di dati per trovare elementi idonei è ovviamente impraticabile.
Ad esempio, si consideri un sistema di gestione del traffico con informazioni riguardanti
migliaia di veicoli e hotspot locali sulle strade. Il sistema può avere bisogno di prevedere i
4
Indici per Big Data
potenziali punti di congestione lungo un percorso scelto da un utente, e di suggerire
alternative.
Per farlo occorre valutare più interrogazioni di prossimità spaziale che calcolino le traiettorie
di oggetti in movimento.
Sono dunque necessarie nuove strutture d’indicizzazione per sostenere tali query.
La progettazione di suddette strutture diventa particolarmente difficile quando il volume dei
dati è in rapida crescita e le query hanno limiti di tempo di risposta ridotti.
Il resto della relazione è organizzato come segue: nel primo capitolo viene trattato l'impatto
dei Big Data nel mondo e nei sistemi di memorizzazione distribuiti; nel secondo capitolo
verranno presentati i sistemi di memorizzazione distribuiti che l'evoluzione tecnologica ha
saputo generare; infine, nel terzo capitolo l'attenzione è interamente dedicata ai sistemi di
indicizzazione sviluppati per enormi quantità di dati.
5
Indici per Big Data
Capitolo 1
L’era dei Big Data
1.1 Big Data nel Mondo
Grazie alle nuove frontiere tecnologiche, siamo in grado di “percepire” il mondo che ci
circonda come non avevamo mai fatto prima, e questa percezione aggiunta ci spinge verso il
desiderio di studiare e immagazzinare le informazioni che da essa ne derivano.
Per esempio, innumerevoli sensori digitali, in tutto il mondo, presenti in attrezzature
industriali, automobili, strumenti di misura e pacchi postali, possono misurare e comunicare
posizione, movimento, vibrazioni, temperatura, umidità e cambiamenti nella composizione
chimica dell'aria.
Colleghiamo questi sensori e interfacciamoli a un’elaboratore e assisteremo alla nascita di
quello che viene chiamato “Internet of Things” o “Industrial Internet”.
Intuiamo che la maggior parte di questi dati nasce “selvaggiamente”, come aggregazione di
parole, immagini e video dal Web e dal flusso di dati dei sensori.
Questi sono chiamati dati non strutturati e sono difficilmente “digeribili” dai tradizionali
database.
Allora, essere in grado di gestire e analizzare questa grossa mole di informazioni al fine di
fornire decisioni istantanee è la moderna sfida offerta dai Big Data.
I Big Data nascondono anche un grosso potere predittivo ancora inesplorato e che sicuramente
fornirà un grande supporto in campi come quello della salute pubblica o dello sviluppo
economico.
6
Indici per Big Data
Alcuni ricercatori, per esempio, notarono, in una regione, un picco delle ricerche su Google
contenenti come parole chiave “sintomi influenzali” e “cure per l’influenza” esattamente due
settimane prima che le stanze dei pronto soccorso fossero prese in assalto da persone con
sintomi influenzali.
E’ doveroso, inoltre, fare un breve riferimento anche al mondo dei social network in virtù dei
profondi cambiamenti sociali che questi hanno introdotto.
Oggi la ricerca in quest’ambito, coinvolge la raccolta di un enorme insieme di dati sul
comportamento collettivo nella rete.
Per esempio, i ricercati sono in grado di estrapolare modelli d’influenza collettiva e picchi di
comunicazione semplicemente seguendo gli “hashtag” su Twitter.
Il mare d’internet è dunque una finestra in tempo reale sul comportamento di un numero
smisurato di persone. Tutto questo è possibile solo grazie ai Big Data.
1.2 Big Data in Database World
Nel mondo dei database, i problemi dei Big Data sorsero quando le aziende ritennero
necessario la creazione di data warehouse per immagazzinare i propri “historical business
data” e poter effettuare grosse interrogazioni su questi dati, al fine di ricavare le relative
business analysis.
Divenne necessario la progettazione di architetture software e hardware dedicate a questi
scopi.
Nel 1980 nasce la prima generazione di software basato su database paralleli, architetture che
oggi vengono comunemente chiamate “shared-nothing”.
7
Indici per Big Data
Un’architettura “shared-nothing” è un’architettura di calcolo distribuito nella quale ogni nodo
è indipendente e autosufficiente. In particolare, nessuno di questi nodi condivide memoria o
dischi di archiviazione.
Il primo sistema basato su database paralleli che ebbe successo commerciale fu il “Teradata
system”.
Questi sistemi sfruttarono la natura dichiarativa set-oriented dei linguaggi di query relazionali
e aprirono la strada all'uso del parallelismo divide-and-conquer, basato sul partizionare i dati
per l'archiviazione e l'esecuzione di operatori relazionali per l'elaborazione delle query.
Un'altra forma di supporto ai Big Data emerse in concomitanza ai sistemi query-oriented
sopracitati e furono i Transaction Processing (TP) systems.
Questi sono alla base delle più comuni applicazioni online, nonché la forza delle attività
finanziarie di tutti i giorni e sono i maggiori produttori di grosse mole di dati.
1.3 Big Data in Systems World
Nel mondo dei sistemi distribuiti, i “Big Data” iniziarono ad essere un problema intorno al
1990 a causa della crescita esponenziale del World-Wide-Web e come risultato della necessità
di indicizzare e interrogare rapidamente i dati.
La risposta di Google alla sfida di analizzare e gestire i dati provenienti dal Web fu semplice,
ma diede il via a quella che sarebbe stata la Big Data Revolution nei sistemi informatici del
mondo.
8
Indici per Big Data
Google creò il Google File System (GFS), questo, fornisce ai “clients” un flusso di byte
astratto per file di grosse dimensioni il cui contenuto può essere “spalmato” su centinaia di
macchine in shared-nothing cluster, creati usando prodotti hardware di basso costo.
Infine, per gestire l'elaborazione su file di così grosse dimensioni, Google fu pioniera ancora
una volta, introducendo il framework MapReduce. Tale framework, permise agli sviluppatori
di Google di processare grosse collezioni di dati attraverso l'uso di due funzioni usate nella
programmazione funzionale, “map e reduce”, che il MapReduce framework applica alle
istanze e ai gruppi ordinati di istanze( map ) che condividono una chiave comune( reduce ).
Mentre questo processo può spesso apparire inefficiente attraverso l’uso di algoritmi che sono
più sequenziali, MapReduce può essere applicato significativamente a grandi quantità di dati
che i server sono in grado di gestire comodamente - una grande server farm può usare
MapReduce per ordinare petabyte di dati in sole poche ore.
Guidati dalle stesse motivazioni, sviluppatori software come Yahoo!, Facebook, e altre grandi
compagnie del Web seguirono l'esempio di Google.
Partendo da quelle che erano le specifiche del GFS e del modello MapReduce, venne
sviluppata una soluzione equivalente open-source, la piattaforma Apache Hadoop MapReduce
e il relativo file system HDFS ( Hadoop Distribuited File System ).
Presto, stanca della natura a basso livello della programmazione MapReduce, la comunità
Hadoop sviluppò un set di linguaggi dichiarativi ad alto livello per la scrittura di query e per
l'analisi dei flussi di dati.
I linguaggi più popolari includono Pig per Yahoo!, Jaql per IBM, e Hive per Facebook.
Sulla base di tali sistemi, sono state progettate architetture software più sofisticate per
supportare una vasta gamma di applicazioni. Una di queste sono i sistemi di archiviazione
basati su valori chiave.
9
Indici per Big Data
Google introdusse la BigTable, un sistema di storage distribuito per dataset, collezioni di dati
su larga scala. Questo è costruito sul GFS e combina le due tecniche di database column-based
e row-based.
HyperTable è una soluzione open-source equivalente alla BigTable di Google, realizzata sul
HDFS.
Il sistema Dynamo di Amazon è un archivio basato su valori chiave e utilizzato per diversi
servizi Amazon.
Cassandra è la combinazione tra Dynamo e BigTable creata da Facebook per efficienti
ricerche InBox.
Sottolineiamo che queste differenti implementazioni hanno tutte un punto di partenza comune:
forniscono tecniche di memorizzazione di enormi dataset su cluster di computer sharednothing.
1.4 Big Data Oggi
Oggi, le compagnie di fronte alla sfida dei Big Data hanno diverse possibilità.
Se un’azienda deve poter affrontare interrogazioni di grosse dimensioni, può scegliere l'acquisto
di una licenza di database paralleli poiché, sfortunatamente non esistono alternative opensource.
Se invece la prova da affrontare è l'analisi batch di dati semi-strutturati, allora può affidarsi a
una delle tecnologie open-source messe a disposizione dal mondo Hadoop.
10
Indici per Big Data
Capitolo 2
Parallel Database System e Hadoop System
Dopo aver cercato di riassumere brevemente la storia dei database systems a supporto della
sfida dei Big Data, il seguente capitolo ha come obiettivo quello di offrire una panoramica sulle
due architetture proposte, Database Paralleli e Hadoop System, al fine di avere un quadro
generale delle tecnologie a supporto dei Big Data.
2.1 Parallel Database System
SQL Compiler Relational Data2low Layer Row/Column Storage Manager Figura 1: Livelli di un’architettura basata su database paralleli.
Questa tipologia di database è basata su uno schema a livelli.
Alla base di un database parallelo vi è un record-oriented storage manager, in realtà viene
implementato un manager per ogni macchina del cluster.
Questi gestori dell'archiviazione sono organizzati per fornire ai livelli superiori servizi di
archiviazione shared-nothing per grandi tabelle relazionali.
11
Indici per Big Data
Al livello superiore, nel mezzo, ritroviamo una collezione di sistemi di operatori relazionali
utilizzati per eseguire il piano di accesso delle query per il livello superiore.
In testa a questa stratificazione si trova un compilatore SQL il quale accetta, ottimizza e genera
un appropriato piano di accesso per le query.
Tale gestione a livelli, permette all'utente finale di avere accesso ovviamente al solo strato più
alto della pila di livelli (SQL layer).
Questa architettura software viene spesso paragonata ad un cipolla: per la sua stratificazione,
per l'accesso al solo livello più alto e per i costi di licenza, in quanto non esistono alternative
open-source di sistemi basati su database paralleli.
2.2 Hadoop System
HiveQL/Pig/Jaql (High-­‐Level languages) Hadoop MapReduce Data2low Layer HBase Key-­‐Value Store Hadoop Distributed File System Figura 2: Hadoop System
Alla base di un’architettura Hadoop troviamo naturalmente l'HDFS, un file system distribuito
nel quale ogni file appare come un sequenza di byte contigua e ad accesso casuale.
12
Indici per Big Data
Per l'analisi batch, il livello superiore è il MapReduce Hadoop System, il quale applica le
operazioni di “map” alle partizioni di un HDFS file, ordina e redistribuisce i risultati su valori
chiavi producendo i dati di output, e infine applica le operazioni di “reduce” ai gruppi di dati
con la stessa chiave calcolata al passo precedente.
In testa all'architettura Hadoop vi sono compilatori di linguaggi ad alti livello attraverso i quali i
clients del sistema possono effettuare le interrogazioni.
2.3 Pro e contro di un’architettura Hadoop
Portando lo sguardo alle tendenze economiche, è chiaro che un’architettura Hadoop è
preferibile a un sistema di database paralleli per diversi casi d'uso dei moderni Big Data.
Tuttavia, non è ancora possibile definire i sistemi Hadoop la “giusta” risposta alla sfida dei Big
Data, ma è anche chiaro che questi possiedono un numero rilevante di proprietà desiderabili:
•
Disponibilità Open-Source.
•
Struttura non monolitica o suddivisa in livelli.
•
Supporto per il recupero incrementale dei lavori con tasks falliti.
•
Possibilità di schedulare il lavoro in sotto-problemi con carichi di lavoro elevati.
•
Distribuzione e bilanciamento automatico dei dati.
•
Supporto per sostituzione e il rimpiazzo di macchine difettose senza l'intervento di un
operatore.
Analizziamo anche l’altra faccia della medaglia:
• La costruzione di un livello record-oriented su un flusso di dati globale viene ritenuta poco
sensata; così come l’esecuzione parallela di dati su un modello con operatori unari
(MapReduce).
• Il livello di archiviazione dei valori chiave, con possibilità d’interrogazioni remote rende
inefficiente il livello superiore, poiché pone un limite in uno dei posti peggiori di architettura
di gestione dei dati.
13
Indici per Big Data
• Una qualsiasi mancanza d’informazioni sullo schema è trascurabile ma porterà difficoltà
future.
Capitolo 3
Indici per Big Data
Presenteremo di seguito un innovativo schema d’indicizzazione basato su B+-tree per la
lavorazione efficiente di dati.
Tale schema, inizialmente sviluppato a sostegno del Cloud Computing, può essere integrato in
diversi sistemi di memorizzazione garantendo elevate prestazioni e concorrenza.
Con il termine “Cloud Computing” si vuole indicare un tipo d’infrastruttura di elaborazione
distribuita che è solitamente composta da un certo numero di nodi.
Per sfruttare a pieno la forza del Cloud, è necessaria una gestione efficiente dei dati, per
governarne l’enorme volume e supportare un grosso numero di utenti concorrenti. Per
raggiungere tale obiettivo, è richiesto uno schema d’indicizzazione scalabile e con alte
performance.
3.1 Indici Primari e Secondari
Dato un file f con campo chiave k, ricordando che un campo chiave è un valore attraverso il
quale è possibile individuare la locazione fisica dei dati, un indice secondario è un altro file, in
cui ciascun record è logicamente composto di due campi, uno contenente un valore della
14
Indici per Big Data
chiave k del file f e l’altro contenente l’indirizzo o gli indirizzi fisici dei record di f che hanno
quel valore chiave. L’indice secondario è ordinato in base al valore della chiave e consente
quindi una rapida ricerca in conformità a tale valore. Pertanto, l’indice secondario può essere
utilizzato da un programma per accedere rapidamente ai dati del file primario, supponendo che
l’interrogazione cui dare risposta abbia un criterio basato sul campo k.
Quando invece l’indice contiene al suo interno i dati esso viene detto primario, perché
garantisce non solo un accesso in base alla chiave, ma contiene anche i record fisici necessari
per memorizzare i dati. Ovviamente, un file può avere un solo indice primario e più indici
secondari.
3.2 Il CG-Index
Il CG-index(Cloud Global Index) è uno schema d’indicizzazione secondario sviluppato per
piattaforme Cloud, progettato per query online e mantenuto in modo incrementale.
Tale schema condivide alcune delle strategie d’implementazioni comuni ai database sharednothing, ai sistemi peer-to-peer e agli attuali sistemi di memorizzazione Cloud.
Un CG-index consiste di due componenti: una libreria collegata con le applicazioni utente e un
set di server indice dove sono memorizzati gli indici.
I server indice lavorano in un gruppo di nodi di elaborazione condivisi, mentre il processo
server di indicizzazione può risiedere anche sulla stessa macchina fisica del processo server di
memorizzazione.
Tutti i sistemi di memorizzazione esistenti implementano uno schema di partizionamento
orizzontale per memorizzare grossi “dataset” in un cluster.
L’idea è di partizionare il dataset in parti più piccole chiamate “data shards”.
Ogni data shard è un’unità distribuita e archiviata su un unico nodo.
15
Indici per Big Data
Il CG-index è progettato per offrire buone performance con questo sistema di partizionamento.
Infatti, esso costruisce un indice locale B+-tree per ogni data shard, chiamato shard index.
Le query sono quindi servite con una ricerca di tutti gli indici shards qualificati.
3.2.1 B+-tree
Un B+-tree è una struttura ad albero dinamica (cioè efficiente anche in presenza di
aggiornamenti) tra le più utilizzate per la realizzazione di indici.
Ogni albero è caratterizzato da un nodo radice, vari nodi intermedi, e molteplici nodi foglia;
ogni nodo coincide con una pagina o blocco a livello del file system. I legami tra nodi
vengono stabiliti da puntatori che collegano fra di loro le pagine; in genere ogni nodo ha un
numero di figli abbastanza grande, che dipende dall’ampiezza della pagina.
Un requisito importante per il corretto funzionamento della struttura è che gli alberi siano
bilanciati, cioè che la lunghezza di un cammino che collega il nodo radice da un qualunque
nodo foglia sia costante, in questo modo il tempo di accesso ai dati è lo stesso per tutte le
foglie ed è pari alla profondità dell’albero.
La struttura tipica di un nodo non foglia presenta una sequenza di F valori ordinati di chiave,
dove ogni chiave Ki, con 1 ≤ i ≤ F, è seguita da un puntatore Pi che indirizza un sotto-albero.
Il puntatore P0 indirizza al sotto-albero che permette di accedere ai record con chiavi minori di
K1; il puntatore PF indirizza al sotto-albero che permette di accedere ai record con chiavi
16
Indici per Big Data
maggiori o uguali a KF ; infine, ciascun puntatore intermedio Pi indirizza un sotto-albero che
contiene chiavi comprese nell’intervallo [Ki, Ki+1).
In sintesi, ciascun nodo contiene F valori chiave e F + 1 puntatori; il valore F + 1 viene detto
fan-out dell’albero.
Della struttura presentata, esistono due versioni, denominate B e B+.
Negli alberi B+, i nodi foglia sono collegati da una catena che li connette in base all’ordine
imposto dalla chiave. Tale catena consente di svolgere in modo efficiente anche interrogazioni
su intervalli di valori ammissibili. In tal caso, infatti, è sufficiente accedere al primo valore
dell’intervallo, per poi scandire sequenzialmente i nodi foglia fino a trovare valori di chiave
maggiori del secondo valore dell’intervallo.
Un B+-tree distribuito ha i propri nodi suddivisi su più server.
Per indicizzare i dataset in un cluster, viene proposto l’algoritmo basato su B+-tree distribuito.
Il B+-tree è distribuito fra i nodi disponibili in modo casuale, collocando i nodi dell’albero tra
quelli di elaborazione, chiamati “server nodes”.
Questa soluzione porta in se due debolezze: la prima è che nonostante sia utilizzato un indice
basato su B+-tree, l’indice è disegnato principalmente per query di ricerca semplici e pertanto
non è in grado di gestire query su intervalli di valori in modo efficiente; in secondo luogo
comporta costi di manutenzione elevati per i nodi server e provoca un eccessivo overhead
nelle macchine degli utenti.
17
Indici per Big Data
3.3 Architettura di un Sistema Cluster
Un set di macchine a basso costo costituisce i nodi di elaborazione del cluster.
Questo è un sistema shared-nothing dove ogni nodo ha la propria memoria e i propri hard disk.
Per facilitare la ricerca, i nodi sono connessi secondo il protocollo BATON. In BATON, ogni
nodo è responsabile di una chiave e ogni nodo mantiene puntatori d’instradamento verso il
predecessore, il successore e la radice.
Questa forma di indicizzazione è molto simile a quella del B-tree.
18
Indici per Big Data
In questi sistemi, i dati sono partizionati in data shards, i quali sono distribuiti in modo casuale
ai nodi di elaborazione. Per facilitare la ricerca per una chiave secondaria, ogni nodo
costruisce un B+-tree per indicizzare i dati locali. In questo modo, dato un valore chiave, si
riceve efficientemente “l’handle” corrispondente.
L’handle è una stringa di bit arbitraria che viene utilizzata per estrarre il valore corrispondente
dal sistema di memorizzazione.
Per risolvere le query nel cluster, uno schema tradizionale distribuisce le query in broadcast a
tutti i nodi, dove le ricerche in locale vengono svolte in parallelo. Questa strategia, per quanto
semplice, non è efficiente e scalabile.
Un altro approccio è di mantenere le informazioni sul partizionamento dei dati in un server
centrale, ma anche questa soluzione, come tutte quelle che prevedono un nodo centrale,
presenta uno svantaggio: il nodo centrale diverrebbe il collo di bottiglia del sistema.
Dunque, dato un valore chiave o un intervallo di ricerca, per localizzare il corrispondente B+tree, costruiremo un indice globale ( CG-index ) sul B+-tree locale.
In particolare, alcuni nodi del B+-tree locale sono pubblicizzati e indicizzati nei nodi remoti di
elaborazione secondo il protocollo di routing sovrastante. Per evitare costi di memoria
eccessivi, inoltre, vengono memorizzati solo i meta-data di un nodo B+-tree pubblico: il blk,
19
Indici per Big Data
disk block number del nodo, il range del nodo, le chiavi di ricerca del B+-tree e l’IP del
corrispondente nodo di computazione.
In questo modo, manteniamo un indice remoto per il B+-tree locale in ogni nodo del cluster.
L’insieme di questi indici costituisce il CG-index.
3.4 Risoluzione delle Query
Data una query su un intervallo Q, abbiamo bisogno di ricercare il CG-index per localizzare il
nodo B+-tree il cui intervallo coincide con Q.
Proviamo a simulare l’algoritmo di ricerca per risolvere la query.
Partendo dal limite inferiore di Q, seguiamo i collegamenti adiacenti per cercare nodi di pari
livello fino a raggiungere il limite superiore di Q.
Tale algoritmo di ricerca può essere ulteriormente ottimizzato. Supponendo che k nodi
coincidano con Q, il costo medio di una ricerca su intervallo in BATON è all’incirca
½log2N+k, dove N è il numero di nodi di elaborazione totale del sistema.
La prima ottimizzazione può essere fatta sul punto di partenza della ricerca che andrebbe
spostato all’interno dell’intervallo. Ipotizzando, infatti, che i dati sono distribuiti
uniformemente tra i nodi e chiamato R l’intervallo totale, quest’ottimizzazione riduce il costo
medio di ricerca da ½log2N+k a ½log2 QN/R +k.
Gli studi esistenti ignorano gli effetti di k, il quale, di fatto, domina le prestazioni di ricerca in
una rete su larga scala. Un semplice esempio, in una rete di 10'000 nodi, supponiamo i dati
partizionati uniformemente tra i nodi, avremo k = 100 se Q/R = 0.01.
20
Indici per Big Data
Per ridurre la latenza della ricerca per intervallo, la seconda ottimizzazione comporta
l’aumento del parallelismo inviando la query in broadcast a tutti i nodi di elaborazione che si
sovrappongono con l’intervallo di ricerca.
In conclusione, il nuovo algoritmo di ricerca può essere riassunto come:
1. Localizzare i nodi di calcolo nell’intervallo di ricerca.
2. Seguire i collegamenti adiacenti e individuare il nodo radice del sotto-albero BATON.
3. Inviare la query in broadcast ai soli nodi figli del sotto-albero.
4. In ogni nodo di elaborazione, dopo aver ricevuto la richiesta di ricerca, eseguire una
ricerca locale per il CG-index corrispondente.
L’introduzione del parallelismo riduce il costo medio di ricerca a ½log2 QR/N + log2N, dove
quest’ultimo contributo additivo è il massimo valore dell’albero BATON.
21
Indici per Big Data
Conclusioni
Abbiamo cercato di riassumere brevemente come il mondo dell'informazione ha reagito a
questa nuova sfida, al fine di essere in grado di sfruttare il grande potere economico e sociale
che i Big Data rappresentano.
Per fare ciò, la gestione di questi dati diventa fondamentale ed è dunque necessario uno
schema di indicizzazione ad alte prestazioni.
Un albero B+ locale è costruito per ogni dataset memorizzato in un nodo. Per aumentare le
prestazioni del sistema, organizziamo i nodi di elaborazione in una struttura stratiforme sulla
quale viene costruito un indice CG-index globale. Solo una parte degli alberi B+ locali ai nodi
viene resa pubblica e indicizzata nel CG-index. In base al protocollo di instradamento
sovrastante, il CG-index viene distribuito tra i nodi computazionali.
Modifiche future prevedono di adattare la strategia di indicizzazione affinché possa pubblicare
selettivamente i nodi albero B+ locali in base alla distribuzione delle interrogazioni.
La soluzione proposta dimostra che tale schema è efficiente e scalabile.
22
Indici per Big Data
Bibliografia
[1]
Steve Lohr 2012 “The Age of Big Data”
[2]
Vinayak Borkar, Michael J. Carey, Chen Li 2012 “Inside “Big Data
Management”:Ogres, Onions, or Parfaits? ”
[3]
Paolo Atzeni, Stefano Ceri, Piero Fraternali, Stefano Paraboschi, Riccardo Torlone
Seconda Edizione “Basi di Dati: Architetture e linee di evoluzione”
[4]
Sai Wu , Dawei Jiang , Beng Chin Ooi , Kun-Lung Wu 2010 “Efficient B-tree Based
Indexing for Cloud Data Processing”
23
