Elaborato Birra Giorgio N46000396

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