Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in BASI DI DATI Document Object Oriented: MongoDB Anno Accademico 2015/2016 Candidato: Giorgio Birra matr. N46000396 A te Zio Armando ,mi ero promesso che avrei concluso gli studi dopo la tua improvvisa dipartita, per renderti omaggio e fiero di me perché per me sei stato e sei un esempio da seguire. A voi mia famiglia che credete in me ed io vi amo. A tutti quelli che mi hanno sostenuto e soprattutto a quelli che mi hanno criticato A me. Indice Sommario Indice .................................................................................................................................................. III Introduzione ......................................................................................................................................... 5 Capitolo 1: Big Data ............................................................................................................................ 6 1.1 Caratteristiche dei Big Data ....................................................................................................... 7 1.1.1 Volume ........................................................................................................................... 7 1.1.2 Velocità ........................................................................................................................... 7 1.1.3 Varietà ............................................................................................................................. 7 1.1.4 Complessità ..................................................................................................................... 7 1.1.5 Veridicità ......................................................................................................................... 7 1.2 Tecniche per manipolare i “Big Data” ...................................................................................... 8 1.2.1 Algoritmi Genetici .............................................................................................................. 8 1.2.2 Agenti Intelligenti ............................................................................................................... 8 1.2.3 Crowdsourcing .................................................................................................................... 8 1.3 Hadoop ................................................................................................................................ 10 1.3.1 HDFS ................................................................................................................................ 11 1.4 Criticità Dei Big Data .......................................................................................................... 12 Capitolo 2 : Sistemi NOSql ................................................................................................................ 13 2.1 ACID ........................................................................................................................................ 13 2.2 Teorema del CAP .................................................................................................................... 13 2.3 Classificazione Sistemi NOSql ................................................................................................ 15 2.4 Esempi sistemi NOSql ............................................................................................................ 16 2.4.1 Big Table by Google ........................................................................................................ 16 2.5 BASE ...................................................................................................................................... 18 2.6 Garanzie delle tecniche di tipo NOSql per i Big Data ............................................................. 18 Capitolo 3 : MongoDB ....................................................................................................................... 19 3.1 Architettura Base e con Replica ............................................................................................... 19 3.1.1 Failure Server principale,come si risolve ........................................................................... 20 3.1.2 Limitazioni del modello Base e con Replica ..................................................................... 21 3.2 Tecnica Sharding...................................................................................................................... 21 3.2.1 Partizionamento e Bilanciamento ...................................................................................... 22 3.3 Casi D’uso MongoDB .............................................................................................................. 23 3.3.1 Avvio.................................................................................................................................. 23 3.3.2 Creazione di un DB ............................................................................................................ 24 3.3.3 Inserimento di un record .................................................................................................... 25 3.3.4 Ricerca di un documento.................................................................................................... 26 Conclusioni ........................................................................................................................................ 28 Bibliografia .................................................................................................................................... 29 Ringraziamenti ............................................................................................................................... 30 Introduzione L’utilizzo di basi di dati è diventato da anni molto diffuso e ci sono sempre più casi d’uso nella vita reale. Si possono fare tantissimi esempi della vita quotidiana in cui una base di dati entra in gioco, come catalogare i propri libri, avere traccia di incassi, clienti, e molto altro ancora. E’ anche vero che, con l’innovazione delle tecnologie per gestire una base di dati, entra in gioco la complessità delle sempre crescenti esigenze di lavorare con una collezione di dati molto grande, talvolta caratterizzati da grandi dimensioni. Inoltre a volte i dati sono eterogenei e gli aspetti implementativi del software non sono trascurabili. Dato il “peso” o, meglio, il volume dei dati delle nuove realtà da memorizzare, si è pensato di trovare una strada più agevole che punti alla riduzione del tempo di interrogazione di questi ultimi per estrarne i contenuti. Le basi di dati classiche sono fondate, ad esempio, su uno schema relazionale che rappresenta il grado di dipendenza tra entità, per poi essere implementate in un software. L’alternativa è quella di creare basi di dati che non facciano uso di tutte le caratteristiche tradizionali come schemi relazionali, tabelle e campi fissi. Questa soluzione prende il nome di NOSql. L’acronimo originale è SQL dei database tradizionali, il NO sta per NOT ONLY. Il distacco dalle basi di dati tradizionali sta nel fatto che non si segue uno schema fisso nella memorizzazione dei dati, ovvero i dati non hanno una struttura fissa. Un dato può avere degli attributi mentre un altro può non averne o averne di più. Questa proprietà porta la base di dati ad essere più agevole nel trattamento e nell’uso e a miglioramenti nell’utilizzo in numerosi contesti. Una base di dati NOSql può avere tabelle e campi, ma questi non hanno schemi fissi. Questo approccio è molto utile per i servizi Internet dove si richiede velocità di elaborazione di questi dati molto “voluminosi”. Per cercare di fare intendere l’esistenza di questi dati e la loro grande dimensione basta riflettere sui seguenti esempi: 1- Un aereo in volo genera, periodicamente durante il tragitto, circa 10 TB di dati. 2- Google elabora milioni di query ogni minuto. 3- C’è un flusso continuo sui social: ogni secondo utenti si scambiano milioni e milioni di messaggi. 5 Nel 2010 è stato fatto uno studio che evidenzia la grande quantità di dati che produciamo all’incirca in una settimana e ciò dimostra che in questo periodo ci troviamo a produrre un numero di dati che potrebbe bastare a scrivere l’intera storia di una civiltà. E’ ovvio che questo è un grande fenomeno; ci sono stati e ci sono tutt’ora degli studi al riguardo poiché sì è visto che questi dati, combinati alle esigenze degli utenti, possono aiutare le imprese a migliorare i propri servizi. E’ stato dimostrato che ci sia chiesto come sfruttare al massimo le potenzialità di questi dati. Un modo per sfruttarle appunto è il sistema distribuito Hadoop descritto in seguito. Hadoop è un framework per sistemi distribuiti, ossia sistemi con dati sparsi su varie postazioni perché l’insieme di dati da gestire, il dataset, è grande e questo sistema ne facilita la gestione. In occasione del terremoto di Haiti nel 2010, grazie alle card dei cellulari, è stato possibile rintracciare le persone fuggite in seguito alla catastrofe e ciò fu possibile consultando gli spostamenti rilevati da dalle card stesse; Ugual procedimento fu adottato quando ci fu il diffondersi del colera, per rintracciare dove comprare i farmaci ed evitare la diffusione dell’epidemia. Questi avvenimenti hanno portato a pensare di adottare i Big Data anche nella gestione amministrativa pubblica. 6 Capitolo 1: Big Data Definiamo Big Data una raccolta di dati con la particolarità di essere molto grandi in termini di spazio occupato e complessità di elaborazione. Questa permette di avere in poco tempo il dato desiderato e richiede una tecnologia non convenzionale per elaborarli. Si lavora molto spesso con dati che sono di tipo diverso tra loro. L’utilizzo dei Big Data è molto diffuso soprattutto in internet, dove hanno trovato molte applicazioni in Google, social network, ecc... e sono utilizzati per lo più per automatizzare aspetti e operazioni di numerosi utenti permettendone la crescita. Come già anticipato, la tecnica utilizzata è quella del NOSql. Questo termine è stato coniato nel 1998, ma non in un primo momento non venne preso molto in considerazione. Solo dal 2009 c’è stata una crescita repentina nell’utilizzo di questa nuova tecnica, che venne adottata da molte aziende. Secondo sondaggi del 2014 riportati da Accenture Analytics, le aziende che adottano i Big Data riscontrano grandissimi risultati e riportano il decollo di questi software, i quali portano grandi prestazioni e l contempo soddisfano le esigenze delle aziende; il 94% è soddisfatto delle prestazioni mentre il 92% è soddisfatto anche delle esigenze desiderate. Questi risultati sono relativi a circa 1000 aziende che sono attive nel mercato europeo nei campi più disparati: dai servizi sanitari ai servizi assicurativi,bancari, ecc.... Il maggior numero di consensi viene proprio da manager italiani. 7 1.1 Caratteristiche dei Big Data 1.1.1 Volume Rappresenta la dimensione effettiva dell’insieme di dati; Il numero di dati che è possibile raccogliere ad oggi potrebbe rappresentare una problematica data la sua ampiezza. Tuttavia questo è un falso problema, in quanto esistono nuove tecniche, come cloud e virtualizzazione, le quali ne agevolano la gestione del grosso volume, semplificando i processi di raccolta, di acquisizione e accesso agli stessi. 1.1.2 Velocità E’ la velocità con la quale avviene la generazione dei dati; in genere si cerca di fare un analisi in tempo reale o quasi. 1.1.3 Varietà E’ una caratteristica che si riferisce all’assortimento dei dati e alle fonti da cui essi provengono. 1.1.4 Complessità Come in ogni applicazione del campo informatico, il concetto di complessità è presente anche qui. Nel caso dei Big Data è che maggiore è la dimensione della collezione dei dati e più è difficile collegare le informazioni tra di loro. 1.1.5 Veridicità Per quanto riguarda un oggetto della base di dati, trovandosi in un sistema distribuito, si possono avere molteplici informazioni che riguardano quest’ultimo; è allora necessario che non vengano prese tutte, quindi, scartando quelle inutili, devono essere considerate quelle che rappresentano l’oggetto, ossia quelle che danno una rappresentazione veritiera e reale. 8 1.2 Tecniche per manipolare i “Big Data” Ovviamente vanno definite delle tecniche per lavorare su questi dati perché è chiaro che non basta un approccio classico. Secondo un report del 2011, per lavorare su questi si scelgono particolari soluzioni basate su algoritmi di ricerca e agenti intelligenti. Al riguardo possiamo elencare : 1-Algoritmi Genetici 2-Agenti Intelligenti 3-Crowdsourcing 1.2.1-Algoritmi Genetici Utilizzati anche nell’intelligenza artificiale. Dato un insieme di geni(nodi) con un certo numero associato, sono algoritmi adoperati per farne generare di nuovi. Si sceglie di accoppiare due geni ‘promettenti’ e questa promettenza è data da un numero chiamato di «fitness», generato da una funzione. Ogni nodo ha una certa probabilità ‘p’ di essere scelto e questo numero è proporzionale al valore di fitness. La conseguenza di questa soluzione è che, accoppiando due geni promettenti, il figlio generato probabilmente sarà più promettente e permetterà di semplificare un ampio dataset. 1.2.2- Agenti intelligenti Sono agenti, ossia macchine ideate per simulare l’essere umano razionale. Ovviamente, considerando l’impossibilità di realizzare un modello perfetto che faccia tutto quello che deve fare e accontenti tutti gli obiettivi, per progettare un agente intelligente si cerca un compromesso tra l’obiettivo da raggiungere e le performance. All’inizio erano pensati come neuroni: singolo percettrone, percettrone multilivello, adaline. Tuttavia questi ultimi sono utilizzati come funzioni che minimizzano l’errore e non come classificatori. In seguito si sono generate altre soluzioni per classificare automaticamente dati degli ingressi tramite delle leggi. 1.2.2-Crowdsourcing Il crowdsourcing è una tecnica che sfrutta il collettivo; deriva dall’economia, dove un gruppo di persone collaborano volontariamente per un obiettivo comune. In internet questa è una cosa utile perché i collaboratori si riuniscono 9 sul web dove possono comunicare tra di loro. L’approccio è quello di problem solving. 1.3 Hadoop Hadoop è un esempio di Big Data per far capire l’importanza e l’applicabilità di questi ultimi. Hadoop è un ambiente di lavoro per gestire dataset molto grandi; E’ adoperato per elaborare dati di grosse dimensioni utilizzando un criterio di memorizzazione distribuito, ossia utilizzare un file system che gestisca pochi file di grosse dimensioni. Questo, a differenza dei classici file system, elabora i dati in parallelo. Il file system nacque grazie ai dati tecnici che Google pubblicò. Andiamo a vedere come Hadoop garantisce la gestione veloce di questi dati enormi. Il file system ideato da Hadoop si chiama HDFS. Il sistema Hadoop permette una lettura ed una scrittura più veloce rispetto ai database classici. Insieme al File System è stata poi definita una struttura di Hadoop che riportiamo brevemente di seguito: Hadoop Common: Uno strato software comune che fornisce funzioni di supporto agli altri moduli. HDFS: File system distribuito che fornisce un’efficace modalità di accesso ai dati. Garantisce che i dati siano ridondanti nel cluster rendendo le operazioni sugli stessi immuni dall’eventuale guasto di un nodo. HDFS accetta dati in qualsiasi formato, sia che siano strutturati che non. Map-Reduce: Un pattern che è implementato e permette di realizzare sistemi di computazione parallela e distribuita di grandi quantità lavorando secondo il principio del “divide-et-impera“, ossia si divide il problema in sottoproblemi 10 ricorsivamente fino a rendere il problema più piccolo possibile per agevolarne la soluzione e collegare il tutto tramite algoritmi. YARN: Un framework che consente di creare applicazioni o infrastrutture per il calcolo distribuito . Esso si occupa della gestione delle risorse del cluster (memoria/CPU/storage). 1.3.1 HDFS HDFS è un file system distribuito ideato per soddisfare requisiti, quali affidabilità e scalabilità, ed è in grado di gestire un numero elevatissimo di file, anche di grandi dimensioni. HDFS presenta i file organizzati in una struttura gerarchica di cartelle. Dal punto di vista dell’architettura, un cluster(insieme di macchine) è costituito dai seguenti tipi di nodi: NameNode: è l’applicazione che gira sul server principale. Gestisce il file system ed in particolare il namespace, cioè l’elenco dei nomi dei file e dei blocchi, e controlla l’accesso ai file, eseguendo le operazioni di apertura, chiusura e modifica dei nomi di file. Inoltre determina come i blocchi dati siano distribuiti sui nodi del cluster e la strategia di replica che garantisce l’affidabilità del sistema. Il NameNode monitora anche che i singoli nodi siano in esecuzione senza problemi. In caso contrario decide come riallocare i blocchi. Il NameNode distribuisce le informazioni contenute nel namespace su due file: il primo è fsimage, che costituisce l’ultima immagine del namespace; il secondo è un log dei cambiamenti avvenuti al namespace a partire dall’ultima volta in cui il file fsimage è stato aggiornato. Quando il NameNode parte effettua un merge di fsimage con il log dei cambiamenti così da produrre uno snapshot dell’ultima situazione. DataNode: applicazione/i che girano su altri nodi del cluster, generalmente una per nodo, e gestiscono fisicamente lo storage(memorizzazione) di ciascun di essi. Queste applicazioni logicamente eseguono le operazioni di lettura e scrittura richieste dai client e gestiscono fisicamente la creazione, la cancellazione e/o la replica dei blocchi dati. SecondaryNameNode: noto anche come CheckPointNode, si tratta di un servizio che aiuta il NameNode ad essere più efficiente. Infatti si occupa di scaricare periodicamente il file fsimage e i log dei cambiamenti dal NameNode, di unirli in un unico snapshot che è poi restituito al NameNode. 11 BackupNode: è il nodo di failover e consente di averne uno simile al SecondaryNameNode sempre sincronizzato con il NameNode. 1.4 Criticità Dei Big Data Ovviamente, anche essendo una buona tecnologia, quella dei Big Data presenta le sue criticità, tant’è che, se non valgono alcune proprietà, i vantaggi potrebbero vanificarsi. Secondo uno standard, ci sono i vincoli da rispettare per garantire le prestazioni ed il funzionamento dei Big Data. Andiamo a vederli brevemente: 1- Accuratezza : Il valore dei dati deve corrispondere al valore reale. 2- Consistenza: Non ci deve essere ambiguità sui dati. Nessuna contraddizione. 3- Completezza: Ogni dato deve essere perfettamente rappresentato,quindi bisogna individuare quegli elementi che permettano ciò. 4- Assenza di duplicazioni: Un dato presente nella raccolta dati,deve essere unico e non devono esserci ripetizioni; si deve presentare lo stesso dato anche in sistemi diversi. 5- Freschezza: Il dato presente deve essere quello più aggiornato. Dopo aver visto le generalità e la validità dei Big Data, andiamo a vedere come è fatto un sistema NOSql su cui questi si basano. 12 Capitolo 2: Sistemi NOSql Definite le esigenze che hanno portato a trovare una nuova soluzione per gestire collezioni di dati, mostriamo varie tecniche dei sistemi NOSql. L'origine del termine risale al 1998 da un italiano ed era stato creato per una basi di dati open source, la quale non utilizzava un'interfaccia SQL. Il termine NOSql sta per Not Only SQL. 2.1 ACID Con la crescita dell'utilizzo dei sistemi NOSql si è pensato di dare una definizione più precisa e rigorosa nell'utilizzo dei dati. Il principio ACID è un acronimo così definito: Atomicità, Consistenza, Isolamento, Durabilità. Questo acronimo prevede che i dati nei sistemi NOSql non abbiano tutte le proprietà scritte. 2.2 Teorema del CAP La "proprietà" descritta sopra è racchiusa secondo uno standard , che definiremo teorema e che adesso andremo a definire. Enunciamolo: In un sistema distribuito, non è possibile garantire simultaneamente queste tre proprietà sui dati: Consistency Availability Partition Tollerance Consistency(Consistenza): Tutti i nodi del sistema vedono gli stessi dati nello stesso momento. Availability(Disponibilità): Per ogni richiesta, il sistema è in grado di dare una risposta. 13 Partiton Tollerance: Il sistema deve continuare a funzionare anche se si interrompono due o più punti della rete. Il teorema del CAP sostiene che in un sistema distribuito non possono valere contemporaneamente le tre proprietà sopra, tutt’al più ne valgono due. Si potrebbe pensare allora che non esiste una soluzione perfetta e che il teorema del CAP affermi che abbiamo tutto, ma non possiamo utilizzare niente; Tuttavia dipende tutto dal contesto in cui la base di dati verrà utilizzata. I database tradizionali, ad esempio, applicano la teoria del CAP, ossia la consistenza a disponibilità, ma non la tolleranza sulle partizioni. Infatti il tutto è memorizzato su una macchina proprio per evitare il fenomeno di Partition Tollerance. Possiamo vedere meglio dal grafico: 14 2.3 Classificazione Sistemi NOSql I database NOSql sono di tipo : 1- Key/values 2- Documented Oriented 3- Column Oriented 4- Graph Oriented 5- Multimodel Oriented 6- Object Oriented 7- Multidimensional 8- Multivalue 1- Key / Values Per identificare i dati sono usate delle hash tables , ossia una coppia di chiave/valore, quindi la memoria sarà una tabella, molto usata per le applicazioni di caching e web caching. 2- Document Oriented In questo tipo di database, i dati sono organizzati in "Documents" scritti in vari linguaggi: JSON, XML, JBSON. Per l'accesso ad essi si utilizza un API che interroga un dizionario. 3- Column Oriented Come dice la parola, i dati sono organizzati in colonne con l'identificativo: chiave/valore. Sono tabelle ma la particolarità è che non esiste il concetto di JOIN (unione) di più tabelle. 4- Graph Oriented Abbiamo una rete di nodi e per la ricerca dei dati si utilizzano algoritmi pensati proprio per questi. Ogni nodo e ramo ha un proprio valore. 15 5- Multimodel Oriented Basi di dati che possono memorizzare dati di tipo diverso sotto forma di tabelle. Hanno un identificativo univoco per essere letti/ scritti (come Key /values) e forniscono le query per questi tipi diversi di dati. 6- Object Oriented Sono basi di dati con informazioni memorizzate tramite la programmazione tradizionale orientata agli oggetti (C++ ecc...) e la più grande base di dati adotta questo prototipo. 7- Multidimensional E' una base di dati che mostra gli stessi in un array multidimensionale dove ogni dato è accessibile tramite un indice. 8- Multivalue E' una base di dati che più somiglia ad una DBMS relazionale, ma ha la differenza che in ogni campo si può memorizzare un sottocampo e così via. 2.4 Esempio di database NOSql 2.4.1 Big Table by Google Data la necessità di organizzare file di dimensioni grandi, Google anche ha dovuto trovare una soluzione per gestirli. La memorizzazione dei dati è fatta sia per colonne che per righe. Il file system è basato su Google File System che vediamo a breve; questo sistema è stato implementato per gestire le enormi dimensioni dei dati e per far aggiungere facilmente nuove macchine nel cluster. E' importante perché questa implementazione è utilizzata nei servizi più famosi di Google(Maps,Gmail, ecc...). Come già visto in Hadoop, vediamo come gestisce il file system Google per questo sistema distribuito. Google memorizza file, molti per la ricerca, e lo fa in parti da circa 100GB, quindi ci vuole una tecnologia non convenzionale per memorizzarli. Questi file in genere sono in sola lettura ed è necessario mantenerli e conservarli perché difficilmente sono dati che vengono eliminati o sovrascritti. La prima caratteristica di questo file system è quella di facilitare l'avvio ai cluster 16 fondamentali della rete Google, che sono i nodi più semplici dato che quelli meno importanti possono fallire più facilmente. Abbiamo due tipo di nodi: 1- Chunk. 2- Master. I nodi Chunk sono di tipo Server che conservano i file di dati. Ognuno è 64Megabyte. Ogni file "chunk" viene replicato nella rete periodicamente in ogni parte di quest'ultima e devono esserci almeno tre copie. I file chunk sono mappati e permettono una risposta più veloce. I nodi Master sono nodi sempre di tipo Server ma conservano i metadati (informazioni additive dei files) relativi a determinati chunk come la mappatura in memoria dei file che, per esempio, registrano la posizione del chunk . La cosa curiosa è che non è nel kernel del sistema operativo, ma è fornito come libreria. Vediamo come indicizza i dati questo sistema . I dati sono identificati da : 1-Chiavi di riga 2-Chiavi di colonna 3-Time Rest 1- Chiavi di riga Sono stringhe univoche che in fase di lettura/ scrittura sono atomiche, ossia le operazioni non sono interrompibili. Ciò vuol dire che ogni riga viene scritta/letta senza essere interrotta. 2- Chiavi di colonna Sono chiavi organizzate in "set" ed ognuno contiene lo stesso tipo di dato. Ogni dato è identificato con un codice colonna tramite una famiglia di colonne. 3- Time Rest Poiché nella rete potrebbero girare dati non aggiornati,questo campo identifica univocamente il dato . 17 2.5 BASE Abbiamo definito cosa non vale a pieno nei NOSql database, adesso vediamo cosa deve valere; un sistema NOSql che rispetta il teorema del CAP, deve attenersi ai seguenti vincoli sui dati: 1- Basically Available : Anche se i dati non sono in uno stato consistente, devono essere comunque disponibili le informazioni. 2- Soft State : La base dati non deve garantire la consistenza dei dati in ogni istante. Può cambiare stato anche se non c’è un input. 3- Eventual Consistency : La fase di inconsistenza deve avere una durata transitoria e il sistema deve tornare subito consistente. 2.6 Garanzie delle tecniche di tipo NOSql per i Big Data Le tecniche NOSql garantiscono delle semplificazioni: 1- Schemaless: La memorizzazione dei dati non ha uno schema fisso e/o prefissato; non usando le tabelle si possono gestire meglio dati semi strutturati o non strutturati. 2- Leggerezza Computazionale: Per analizzare delle informazioni inerenti ad un dato, si farà riferimento ad un unico documento evitando operazioni di aggregazione tra tabelle, come si fa nei database relazionali. 3- Scalabilità Orizzontale: Dato che la base di dati è divisa su macchine differenti che agiscono in parallelo, fa delle basi di dati NOSql delle piattaforme scalabili orizzontalmente, mentre invece nei database classici la scalabilità è orizzontale perché si può sì aggiungere hardware, semplicemente per aumentare la capacità di storage della base di dati e non dell’elaborazione. 18 Capitolo 3 : MongoDB In questo capitolo ci concentriamo sull’architettura ed utilizzo di un sistema NOSql basato sui documenti. 3.1 Architettura Base e con Replica L’architettura MongoDB è una del tipo : Client – Server, ovvero c’è una macchina Server che fornisce servizi e dati, e la macchina Client richiede questi ultimi. Il Client ha una shell in javascript per comunicare col Server oppure un’altra scritta in un diverso linguaggio di programmazione. La struttura iniziale di MongoDB era molto semplice: 19 Guardando questo schema si è pensato di creare una ridondanza dei dati così da averne più copie. Il dato prima è memorizzato sul server principale e poi replicato tramite il “log” delle modifiche nel sistema distribuito con una sincronizzazione asincrona e, quando viene ricevuto il log, la macchina effettua la modifica sul dato in suo possesso. Il Client potrebbe anche leggere dal “Secondary” ovvero la macchina che ha ricevuto il log ,ma potrebbe fornire un dato non aggiornato,infatti si può impostare la lettura da Secondary ma non è di default. 3.1.1 Failure Server principale, come si risolve Che soluzione adotta l’architettura MongoDB se il Primary fallisce? E’ implementato un meccanismo di automatic election che provvede a scegliere il nuovo server Primary tra i Secondary disponibili. Il meccanismo è quindi molto semplice e viene illustrato in figura: Può essere inserito un’istanza “Arbiter” che viene utilizzata SOLO nel caso di votazione per scegliere il nuovo “Primary”. 20 3.1.2 Limitazioni del modello Base e con Replica La semplicità del modello sopra spiegato è pari alla semplicità con la quale questo può perdere di efficienza.. Sono stati rilevati tre fondamentali problemi: 1- All’aumento delle query richieste si può esaurire la capacità della CPU del Primary. 2- Con l’aumento delle dimensioni dei dati, può esaurirsi la capacità di memorizzazione. 3- Lavorando con dati molto più grandi della RAM, si può rallentare molto il l’I\O sui dischi significativamente. Ovviamente sono state trovate anche delle soluzioni al riguardo: 1- Aumento capacità fisiche (Dischi, CPU e RAM). Tuttavia questa è più una soluzione dei classici database, ed è una soluzione di scalabilità verticale. 2- Scalabilità Orizzontale: tecnica sharding (“sbriciolamento”). Ci concentreremo sulla seconda tecnica, che introduciamo nel paragrafo successivo. 3.2 Tecnica Sharding Questa tecnica rende scalabile l’architettura MongoDB orizzontalmente. Il sistema sharding viene suddiviso in tre parti : 1- Shards: Immagazzina i dati, ne crea delle repliche dette Sets e viene garantita la consistenza e diponibilità dei dati. 2- Istanze Mongos o query routers: Si occupano di soddisfare direttamente le richieste dei client dei MongoDB, reindirizzano le richieste allo shard corretto e restituendo il risultato della richiesta. 3- Config Servers: Contengono i metadati e descrivono il mapping tra dati e shards. Nella pagina seguente mostriamo in figura come è strutturata una richiesta client in un sistema MongoDB e come viene servita: 21 Vediamo come il client fa una richiesta e come si attivano i mongos per soddisfare la richiesta del client. 3.2.1 Partizionamento e Bilanciamento Ora mostriamo in breve come vengono memorizzate le informazioni in un mongoDB. Osserviamo lo schema. 22 I dati sono organizzati in “chunk”, settori da 100GB, ed identificati da una Key. Possiamo decidere come suddividere questi chunks: possiamo scegliere di suddividerli in partizioni di range di chiavi oppure mapparli tramite una funzione Hash ed accedere al chunk. Dopo aver visto tutte le informazioni teoriche inerenti ai Big Data ed ai sistemi NOSql,vediamo come si crea e gestisce una base di dati con un database MongoDB. 3.3 Casi d’uso in MongoDB 3.3.1 Avvio Il processo ha inizio avviando il processo “mongod.exe”, che è il server e si trova nella cartella dove è stato installato il software. Vengono così istanziati dei threads che agiscono nell’applicazione. Collegatosi al porto 27017 è pronto. 23 Ora il Server è in attesa del Client. Lo si può far partire aprendo un altro terminale ed eseguendo il processo: “ mongo.exe” : Possiamo iniziare ad utilizzare il database, lo vediamo dal simbolo : > 3.3.2 Creazione di un db Creiamo un db con il comando: use . Chiamiamo il nostro db Moscato-Birra 24 Ci da conferma che stiamo usando quel db selezionato col comando use, con il messaggio: switched to Moscato-Birra. 3.3.3 Inserimento di un record Inseriamo un record nel database: 25 Abbiamo inserito un documento di tipo alunno con determinati campi; il server manda la conferma con il messaggio : WriteResult(“nInserted”:1) confermandoci che l’inserimento è andato a buon fine. 3.3.4 Ricerca Possiamo ricercare qualsiasi tipo di documento in qualsiasi db. Per prima cosa visualizziamo i db presenti nel disco col comando : show dbs ed avremo quest’input: Notiamo il nostro db di 0,0078 GB ,ci entriamo con il comando “use”. 26 La funzione per ricercare un file è di questo tipo: db.NOMEDOC.find(). Ciò significa che cercheremo oggetti del tipo NOMEDOC. Nel nostro caso cerco documenti di tipo alunno; effettuiamo il comando db.alunno.find ed abbiamo: Notiamo che il campo _id viene generato automaticamente ed è univoco per i documenti. Potevamo anche crearlo noi specificando nell’insert il campo : _id . Nella ricerca possiamo esprimere più criteri per affinarla negli argomenti della funzione find(). E’ chiaro che posso ricercare anche tipo di documento diverso e quindi notiamo l’elasticità con cui possiamo gestire dati diversi e db diversi utilizzando una semplice shell dei comandi . 27 Conclusioni Concludiamo il discorso col dire che i Big Data, soprattutto MongoDB, sono il futuro e vanno utilizzati al meglio per poter usufruire dei vantaggi che gli stessi offrirono. La crescita esponenziale della tecnologia, proporzionale a quella delle esigenze, rende sempre più utili questo tipo di architetture. In questo elaborato abbiamo descritto le limitazione dei database tradizionali per la loro struttura con scalabilità verticale (Aggiunta di hardware per esempio) e la poca efficienza nell’elaborare velocemente grosse quantità di dati, come operazioni di store e operazioni di read. Soprattutto i RDBMS tradizionali sono molto più lenti nell’inviare informazioni di un dato oppure il dato stesso, cosa che in Internet non è accettabile considerando che, come detto sopra, ad esempio Google riceve milioni di query in pochi minuti, pertanto deve rispondere velocemente a tutti gli utenti che usufruiscono del servizio. L’utilità dei sistemi NOSql è stata dimostrata dal fatto che le aziende di oggi adottano per lo più questo tipo di strutture, dimostrando di essere molto più efficienti rispetto ai RDBMS tradizionali , i quali non potranno raggiungere con nessuna tecnica l’efficienza dei sistemi Big Data. Basti pensare, come spiegato, che la base dati più grande è gestita con un sistema NOSql . La cosa molto importante è che il campo dei Big Data è tutt’ora frutto di ricerche e studi, ed è quindi destinato a governare il mercato delle basi di dati di grosse dimensioni per ancora molto tempo. Un altro aspetto fondamentale è anche il costo delle tecnologie implementate per rendere possibile la distribuzione dei dati in un grosso sistema formato da molte postazioni; sistemi di archiviazione che spesso sono locati in posti differenti, come ad esempio Hadoop, che abbiamo visto nell’elaborato. Infine, il fatto che il sistema sia di tipo “Open Source” da la possibilità di studiare al meglio queste architetture a chiunque fosse interessato al fenomeno dei Big Data. 28 Ringraziamenti In questa piccola sezione vorrei ringraziare la mia famiglia che mi ha sostenuto e mi ha consentito di raggiungere questo obiettivo per me molto desiderato. Ringrazio il gentilissimo prof. Moscato ,sempre dalla parte degli studenti,che ha reso possibile questo elaborato molto interessante e attuale e lo ringrazio soprattutto per la sua disponibilità nei miei confronti e come relatore e come professore . Ringrazio il prof. Natella con cui ho fatto l’ultimo esame e che non mi ha fatto perdere l’entusiasmo degli ultimi passi verso la fine del percorso con la sua gentilezza,disponibilità ed umiltà verso gli studenti ,atteggiamenti di una persona preparatissima. Ringrazio il mio amico Gabbo per avermi intrattenuto nei suoi pomeriggi di nullafacenza. Ringrazio il sig. Gazzaniga per avermi fatto capire come NON affrontare il percorso universitario. Ringrazio te S…. che mi hai dato l’input per credere di più in me stesso e che l’obiettivo è alla mia portata. Ringrazio Ludovica per la sua disponibilità e preparazione che mi hanno portate a costruire questo elaborato. E soprattutto ,in seguito a queste sollecitazioni, il grazie va a me stesso che non ho mai smesso di crederci anche contro tante avversità,critiche ostinandomi a continuare per completare il percorso rendendomi oggi entusiasta del mio futuro . 29 Bibliografia [1] https://it.wikipedia.org/wiki/Big_data03/2016 [2] http://www.html.it/guide/guida-mongodb 05/2016 [3] http://www.xenialab.it/meo/web/white/oracle/MongoDB.htm05/2016 [4] http://www.html.it/pag/52332/installazione-2/05/2016 [5] http://stackoverflow.com/questions/12514119/cannot-start-local-mongo-db 05/2016 [6] http://stackoverflow.com/questions/29403638/mongo-waiting-on-27017-even-afterreinstall 05/2016 [7] http://dassia.crs4.it/wp-content/uploads/2014/11/02_MONGO.pdf 05/2016 [8] https://www.mongodb.org/downloads#production 05/2016 [9] http://stackoverflow.com/questions/2404742/how-to-install-mongodb-on-windows 05/2016 [10] http://www.cloudtalk.it/big-data-esempi/ 04/2016 [11] http://www.html.it/pag/50728/architettura-di-hadoop/ 04/2016 [12] https://it.wikipedia.org/wiki/Cluster 04/2016 [13] http://www.html.it/pag/51231/file-system-shell-e-configurazione-di-hadoop/ 04/2016 [14] https://www.accenture.com/it-it/insight-big-success-big-data.aspx 03/2016 [15] https://www.accenture.com/it-it/company-accenture-ricerca-big-data-bigsuccess.aspx 04/2016 [16] https://it.wikipedia.org/wiki/Divide_et_impera_(informatica) 04/2016 [17] http://www.italiamac.it/forum/topic/165760-che-cose-un-framework/ 04/2016 [18] https://www.nephila.it/it/blog/2014/10/03/web-framework-definizione/ 04/2016 [19] http://www.html.it/tag/big-data/ 03/2016 [20] http://www.sas.com/it_it/insights/big-data/what-is-big-data.html 04/2016 [21] https://it.wikipedia.org/wiki/Crowdsourcing 04/2016 [22] http://www.fastweb.it/social/cos-e-il-crowdsourcing-nuova-frontiera-dei-rapportilavorativi/ 04/2016 [23] https://it.wikipedia.org/wiki/Base_di_dati_orientata_al_documento 04/2016 [24] https://it.wikipedia.org/wiki/MongoDB 03/2016 [25] https://it.wikipedia.org/wiki/NoSQL 03/2016 [26] https://it.wikipedia.org/wiki/Dataset 03/2016 [27] https://it.wikipedia.org/wiki/BigTable 04/2016 30