Indici Per i Big Data. Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica. Elaborato finale in Basi di Dati. Anno Accademico 2012/2013

Transcript

1 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

2 2

3 Indice Introduzione 4 Capitolo 1. L era dei Big Data Big Data nel Mondo Big Data in Database World Big Data in System World Big Data Oggi 10 Capitolo 2. Parallel Database System e Hadoop System Parallel Database System Hadoop System Pro e contro di un architettura Hadoop 13 Capitolo 3. Indici per Big Data Indici Primari e Secondari Il CG-index B + -tree Architettura di un Sistema Cluster Risoluzione delle Query 19 Conclusioni 22 Bibliografia 23 3

4 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

5 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

6 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

7 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

8 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

9 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

10 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

11 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

12 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

13 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

14 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

15 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

16 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 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 K i, con 1 i F, è seguita da un puntatore P i che indirizza un sotto-albero. Il puntatore P 0 indirizza al sotto-albero che permette di accedere ai record con chiavi minori di K 1 ; il puntatore P F indirizza al sotto-albero che permette di accedere ai record con chiavi 16

17 maggiori o uguali a K F ; infine, ciascun puntatore intermedio P i indirizza un sotto-albero che contiene chiavi comprese nell intervallo [K i, K i+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

18 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

19 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

20 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 ½log 2 N+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 ½log 2 N+k a ½log 2 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 =

21 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 ½log 2 QR/N + log 2 N, dove quest ultimo contributo additivo è il massimo valore dell albero BATON. 21

22 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

23 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