Capitolo 1

Introduzione database no-SQL


Capitolo 1: Introduzione e Basi


Introduzione database no-SQL
Join, Transaction e Pre-Join
MongoDB in un'App
Come installare MongoDB
JSON e BSON
Schema Dinamico
Da Relazionale ai Documenti
Schema Design

Introduzione database no-SQL

Con quali obiettivi è nato MongoDB, cosa si intende per scalabilità orizzontale e verticale e dove si posiziona MongoDB nel mercato dei database.

Introduzione

Solitamente i database no-sql nascono per soddisfare un bisogno molto specifico, per risolvere un problema particolare, per cui i database relazionali non riescono ad offrire delle soluzioni adeguate.

È stato proprio questo il caso di mongodb. I suoi creatori Eliot Horiwix e Duit Merriman, scusate ma sicuramente ho sbagliato la pronuncia, che all’epoca lavoravano entrambi nell’azienda DoubleClick: una sorta di Google AdSense dove i dati sono quindi statistiche sui visitatori come la nazionalità, il tempo di permanenza nella pagina e così via, con la piccola differenza che DoubleClick viene utilizzato nei siti dei principali brand mondiali come può essere la CocaCola, la Nike o la Microsoft.


Proviamo ad immaginare per un secondo l’enorme quantità di dati che possono generare i visitatori di questi grandi siti, è stato proprio in questa situazione che Eliot e Dwuit si sono accorti che diventava sempre più complicato gestire quest’enorme quantità di dati in continua crescita con i database relazionali, ed è stato proprio da questo limite dei database relazionali che è nata l’idea di creare qualcosa di diverso.


MongoDB nasce con tre obiettivi principali, anzi in realtà l’obiettivo principale è soltato uno: la scalabilità! Oggi si parla sempre di più di core paralleli, di server paralleli e di cloud, ecco loro volevano creare qualcosa che potesse sfruttare tutto questo hardware evoluto.

Ovviamente la scalabilità è legata ai BigData tra virgolette, immaginiamoceli semplicemente come una grande quantità di dati in continua crescita, volevano creare un sistema che potesse essere utile per questa tipologia di dati.


Il secondo obiettivo è la facilità nello sviluppo in modo tale da poter abbracciare tutte le nuove metodologie, magari qualcuno di voi ha sentito parlare di agile o di scrum.


Il terzo obiettivo è quello di avere una rappresentazione dei dati intuitiva in cui poter salvare strutture dati complesse e dati non strutturati, non spaventatevi in realtà non è nulla di complicato. Possiamo immaginare i dati semi-strutturati come un documento XML, che ha una sua struttura interna, ma non è fissa, mentre i dati non strutturati, molto banalmente, sono file: come immagini, musica e simili.

Inoltre doveva supportare il polimorfismo tra i dati, del tutto simile a quello che c’è nella programmazione ad oggetti, ma lo approfondiremo successivamente.


Benissimo, abbiamo visto quale problema cerca di risolvere e l’obiettivo principale di Mongo, conoscete i suoi creatori, le loro facce e i loro nomi, quindi potete andare a stolkerarli su twitter, e adesso cerchiamo di spiegare meglio cosa ti intende con scalabilità e differenziamola tra verticale e orizzontale.

Scalabilità orizzontale e verticale

Parliamo prima della scalabilità verticale. Immaginiamo di avere un piccolo server dove mettiamo un sito appena creato, man mano che il sito cresce riceverà sempre più visitatori e il piccolo server non riuscirà più a soddisfare tutte le richieste quindi ci servirà qualcosa di più potente. Quindi dismettiamo il piccolo server e acquistiamo un server medio. Il sito continua a crescere, diventa sempre più famoso e anche il server medio ci starà stretto, quindi passeremo a qualcosa di più: un super mega server! Solitamente i singoli server molto potenti sono anche molto costosi.


In questo modo abbiamo fatto crescere il server da piccolo, a medio, e poi al grande quindi è cresciuto in verticale, per questo si chiama scalabilità verticale.

Ora vediamo invece la scalabilità orizzontale. Immaginiamo di avere un mini server dove mettiamo sempre il nostro sito appena creato, man mano che il sito cresce il mini sever non basterà più per soddisfare tutte le richieste quindi ci servirà più potenza ma, non andremo ad acquistare un server più potente da sostituire al nostro, andremo ad acquistare un altro mini server.


Essenzialmente il concetto è questo: collegando tra loro 10, 20, 30 mini server noi possiamo soddisfare le stesse richieste di un server medio o addirittura di uno grande. In questo modo abbiamo una reale scalabilità perché possiamo  in qualsiasi momento regolare la quantità dei server all’interno del sistema, aggiungendoli o togliendoli in base alle esigenze e, tenendo attivi solo quelli che ci servono realmente, senza sprechi, questo è un vantaggio enorme in termini di costi.


Altri vantaggi sono il failover, l’alta disponibilità e il disaster recovery. Senza entrare troppo nel tecnico, ma spiegato in maniera molto semplice, immaginiamo di avere il nostro database in entrambe le configurazioni:

- nella scalabilità verticale noi abbiamo un unico server, se dovesse succedere un qualsiasi problema al server o al data center (un incendio, un inondazione...qualsiasi imprevisto) il server andrebbe giù, e quindi anche il nostro database, e i dati non sarebbero più disponibili;

- nella scalabilità orizzontale, invece, noi abbiamo più server, possiamo quindi fare delle copie del nostro database su ciascuno di essi o solo su alcuni; immaginiamo di copiarlo su tre server, se dovesse succedere qualche problema al server 1 i dati risulterebbero comunque sempre disponibili nei servers 2 e 3 dove ci sarebbero le repliche sincronizzate.


La scalabilità orizzontale è nettamente superiore a quella verticale, il problema nasce da un punto di vista pratico: quando tutti questi server devono comunicare tra loro, devono scambiarsi informazioni, ma soprattutto devono essere veloci!


Ecco, MongoDB cerca di darci tutti gli strumenti per poter distribuire la nostra base di dati su più server, cercando di soddisfare anzi, soddisfando a pieno il suo obiettivo principale ovvero la scalabilità.


Adesso vedremo come si configura MongoDB nel mercato dei database. Facciamo un piccolo grafico dove mettiamo nell’asse delle x le funzionalità e nell’asse delle Y la scalabilità e le performance.

Panorama dei database

Pensando a scalabilità e performance ci vengono sicuramente in mente i key-value store, come Memcached che è molto scalabile e molto performante.

Dall’altra parte invece abbiamo le funzionalità, quindi ovviamente gli rdbms classici come Oracle, SQL Server e ovviamente MySQL.


Tra questi due punti abbiamo tutti i database NoSQL, ci sono i wide column come ad esempio Cassandra mentre Mongo si posiziona strategicamente qui. Dico strategicamente perchè tracciando la linea delle performance e della scalabilità questa risulterà molto alta vicino ai key/value store e man mano decrescerà sino ad arrivare agli RDBMS, possiamo notare come Mongo cerchi una sorta di equilibrio, posizionandosi poco prima che la curva inizi a decrescere vertiginosamente, questo poiché vuole essere ricco di funzionalità senza rinunciare alle performance e alla scalabilità.


Si, si, Alberto è tutto molto bello ma se fosse cosi facile non l’avrebbero fatto tutti i database tradizionali? Non proprio, perché nel tratto di funzionalità che va da Mongo agli RDBMS si perde qualcosa, ci sono delle funzionalità che mancano, Mongo ha dovuto rinunciare a qualcosa per essere in quella posizione e ha rinunciato alle joins e alle transactions.

Per chi non ha mai avuto il piacere di usarle, per transaction si intende una sequenza di operazioni che possono concludersi con un evento di successo detto commit o insuccesso detto rollback.


“Momento, momento, momento, momento… un database senza join? E soprattutto senza le utilissime transactions? Questo è impossibile!” Questo è quello che direbbe chi viene dal mondo relazionale. In realtà Mongo ci offre un approccio diverso ai dati, molto più intuitivo e a mio parere anche più creativo, che non ci fa sentire per niente la mancanza di queste funzionalità.

Nella prossima lezione approfondiremo perchè queste funzionalità mancano ma soprattutto quale alternativa ci offre Mongo.