Facebook page Follow me on Twitter Follow on Linkedin Follow me on Flickr Read my Feed RSS

L’ecosistema NoSQL

by mirkobonadei on December 12, 2010

NoSQL è una “buzz-word” che dal 2009 ad oggi ha alimentato non poco movimento e discussione. Nonstante come vedremo poi il NoSQL sia un ecosistema in via di sviluppo nato molto prima del 2009, questo anno resta comunque di assoluta importanza per il movimento, dato che sancisce ufficialmente l’inizio dell’era in cui queste soluzioni vengono adottate non solo dai giganti del web.

Esatto, perchè i giganti del web sono stati i primi a trarre beneficio da questa nuova tecnologia che permette di archiviare i dati in database che non hanno nulla a che vedere con il modello relazionale e di conseguenza con il suo linguaggio chiave, l’SQL. Un esempio lampante è Facebook, il Social Network da 500 milioni di utenti, che si affida tra le altre tecnologie al database Cassandra; sempre restando in ambito Facebook, tutti avrete sentito parlare di Farmville, un gioco che ha annoverato tra le sue file un numero incredibile di utenti, bene, Farmville utilizza Membase, perchè con un database relazionale avrebbe dovuto pagare dei compromessi troppo alti in termini di esperienza utente.

Potrei continuare a citare soluzioni vincenti, ma mi fermo qui e ritorno al 2009, anno in cui diverse conferenze spiegarono il concetto che sta dietro a questi nuovi strumenti. Queste conferenze, scatenarono come spesso accade per una nuova tecnologia, una serie di guerre di religione. E’ una situazione abbastanza classica nel mondo dell’IT. Da una parte ci sono coloro che, entusiasti del nuovo movimento etichettano come morto il predecessore, mente dall’altra parte della barricata troviamo i sostenitori della vecchia tecnologia, quella rodata e testata, i quali cercano di dimostrarne flessibilità e potenza ad ogni costo.

Se vogliamo partire con il piede giusto per questo viaggio nell’ecosistema NoSQL, dobbiamo renderci neutrali ed osservare il tutto da una posizione privilegiata, evitando di schierarci o peggio ancora di limitarci ad utilizzare un nuovo strumento come panacea a tutti i nostri problemi.

Dobbiamo fin da ora entrare nell’ottica che il database è uno strumento di lavoro, e che per anni l’unico strumento che ci poteva aiutare a risolvere problemi di immagazzinamento dati era un database relazionale.

Non ci si è mai neppure posti il dubbio di verificare se fosse o meno uno strumento  idoneo alle nostre necessità, lo si utilizzava perchè si era abituati e soprattutto si sapeva che utilizzando un database relazionale, normalizzando decentemente i dati si poteva avere a disposizione un linguaggio di interrogazione (lo Structured Query Language) che permetteva al nostro database di soddisfare sempre ed in ogni momento le proprietà ACID (Atomicità, Coerenza, Isolamento e Durabilità).

Ora le cose sono cambiate, quando “apriamo” la cassetta degli attrezzi, per gestire l’immagazzinamento dei dati, non ci troviamo davanti solo Oracle, MySQL, PostgreeSQL, MS SQL e Co., ma anche i database della famiglia NoSQL.

Già, perchè NoSQL è un termine che può sembrare un No definitivo al SQL, ovvero al modello relazionale, ma in realtà non è così. NoSQL sarebbe meglio identificarlo come un “Not Only SQL” (Non solo SQL), ovvero un’ecosistema avversario si, ma non sostitutivo a quello relazionale.

Il concetto importante da sviluppare fin dall’inizio è quello di strumenti di lavoro, e l’ecosistema NoSQL ce ne da molti con cui progettare meglio i nostri sistemi.

Ma quando si sentì la necessità di andare oltre a quel modello relazionale che era tra noi da decenni?

Cenni storici
Come scritto all’inizio, il NoSQL è nato molto prima del 2009, ma andiamo con ordine. La reale necessità di trovare un’alternativa al modello relazionale viene dal mondo dei sistemi distribuiti. Più precisamente verso la metà degli anni 90, con l’avvento dei grandi sistemi basati su Internet, si iniziò a considerare la disponibilità di servizio da parte di un Sistema come un requisito importante. Fino a quel momento infatti, la cosa che più contava era la coerenza e la sicurezza dei dati, ma ora tutto ciò non bastava più. Internet stava alzando la posta in gioco e bisognava fare i conti con questo nuovo obbiettivo.

Cosa avrebbe comportato raggiungere il requisito di alta disponibilità da parte di un sistema distribuito? Si sarebbe dovuto rinunciare a qualcosa oppure sarebbe stato semplice raggiungerlo?

A far chiarezza ci pensò Eric Brewer, che in un KeyNote alla conferenza “Principle of Distributed Computing” del 2000 presentò il Teorema del CAP (CAP Theorem). Il teorema, si basa sulle tre lettere che formano la parola CAP, ed ogni lettera è una caratteristica del sistema distribuito su cui si sta lavorando.

  • Consistency (Coerenza): Dopo una modifica tutti i nodi del sistema distribuito riflettono la modifica.
  • Availability (Disponibilità): Ad una richiesta, il sistema è sempre in grado di dare una risposta, in altre parole, il sistema è sempre disponibile.
  • Partition Tollerance (Tolleranza al Partizionamento): Se le comunicazioni si interrompono tra due punti del sistema, il sistema non fallisce ma continua ad essere disponibile.

Secondo il Teorema, avere tutte e tre queste caratteristiche in un Sistema Distribuito in un detreminato momento è impossibile, ma si può segliere quale delle due avere a discapito della terza.

Il teorema, fu poi confermato nel 2002 dal WhitePaper di  Seth Gilbert e Nancy Lynch.

Con il passare del tempo, oltre alla Disponibilità di un Sistema un’altra caratteristica divenne fondamentale, ovvero la capacità di crescere e decrescere in base alle necessità richieste dagli utenti del sistema. Questa caratteristica è strettamente correlata alla Disponibilità di un Sistema, ma non è così intuitivo capirlo.

Con la Disponibilità e la Scalabilità come parole chiave andiamo ad analizzare il caso di Amazon, che nel 2007 pubblicò un WhitePaper molto interessante, nel quale si spiegava il motivo della nascita ed il funzionamento di Dynamo, un Key/Value Store ad Alta Disponibilità.

Leggendo il WhitePaper, e soprattutto il Blog di Werner Vogels (il CTO di Amazon, e colui che tramite il suo blog portò in pubblico questi concetti) si capisce come il modello relazionale non soddisfava affatto le sfide che stava affrontando Amazon, o meglio, si sarebbe potuto adattare il modello relazionale ad Amazon, ma questo avrebbe significato creare una soluzione inefficiente soprattutto dal punto di vista economico.

Tradizionalmente infatti, i sistemi di produzione immagazzinano il loro stato in database relazionali. Ma la maggior parte di questi sistemi immagazzina e legge dati partendo da un’unica chiave primaria e di conseguenza non richiedono tutta la complessità di interrogazione che un database relazionale può essere in grado di fornire. E’ quindi evidente come ci sia uno spreco di risorse, soprattutto riguardo all’ Hardware ed al personale specializzato.

La soluzione relazionale è quindi in questo caso sconveniente, ma lo diventa ancora di più quando una compagnia come Amazon deve scalare il proprio sistema, infatti, nonostante i passi in avanti fatti negli ultimi anni, resta complicato aggiungere o togliere un nodo ad un database relazionale distribuito, e questa complessità difficile da abbattere è figlia della potenza che il database relazionale garantisce nella gestione dei dati.

Amazon, reagì al problema nel modo migliore, ovvero creando una tecnologia apposita per risolvere un determinato tipo di problema, evitando quindi di snaturare un’altra tecnologia, che non era assolutamente nata pensando a questo tipo di problemi.

Amazon, aveva necessariamente a che fare con la Tolleranza al Partizionamento, e per garantire una migliore esperienza all’utente, scelse di privilegiare le caratterisstiche AP del CAP, rinunciando ad avere un sistema sempre consistente. Venne quindi introdotto il concetto di eventualmente consistente, ovvero, in un sistema altamente disponibile e tollerante al partizionamento dei dati, un aggiornamento arriverà eventualmente a tutti i nodi in un determianto lasso di tempo, in modo da non bloccare il sistema nel caso in cui tutti i nodi non abbiano la stessa versione dei dati. Per far questo ovviamente, la soluzione creata da Amazon è dotata di un efficiente sistema di gestione dei conflitti, dato che due nodi in un determinato momento, possono aver ricevuto aggiornamenti diversi tra loro.

Oltre ad Amazon poi, come non citare il caso di Google, che l’anno prima di Amazon, rese pubblico il WhitePaper che spiega il funzionamento di BigTable, il grande Database che sta dietro ai servizi di successo della compagnia di Mountain View. Anche BigTable fu creato per soddisfare i bisogni specifici di Google, ed anche BigTable non segue il modello relazionale.

Questi sono solo due dei casi più visibili di scelta del miglior strumento per un determinato lavoro. Ma rendono perfettamente il concetto del NoSQL.

Andiamo ora ad analizzare l’ecosistema attuale del movimento NoSQL.

La situazione attuale
La situazione attuale dell’ecosistema NoSQL è in continua evoluzione. Dopo gli esempi di Google ed Amazon infatti sono nati un numero incredibile di progetti, quasi tutti open source con lo scopo di creare nuovi strumenti di gestione dei dati che fossero a disposizione di tutti gli sviluppatori. In poche parole si è aperto un nuovo mercato, che sta ancora cercando di definire i propri confini, cosa molto difficile da fare in questo momento, dove il movimento sta guadagnando sempre più spazio e fiducia.

Sembra quasi che man mano che si evolve il web, si debba evolvere in qualche modo anche il mondo dei Database.

Prima mi riferivo agli anni 90, con la nascita dei primi sistemi distribuiti su Internet, mentre oggi non possiamo non aver notato l’esplosione dei siti di Social Networking. Questi siti hanno dovuto affrontare non solo i problemi affrontati da Amazon e Google ma anche altri problemi derivati dalla natura del loro business come ad esempio il gestire in modo semplice ed efficace le relazioni sociali. Per tutta risposta Facebook ha sviluppato Cassandra, rendendolo poi Open Source ed in modo tale che fosse poi utilizzato anche da altri grandi siti Social come Twitter e Digg (solo per citarne due). Twitter ha sviluppato FlockDB un Database Grafico per gestire al meglio le relazioni tra gli utenti della piattaforma. Man mano che passa il tempo vediamo nascere sempre più soluzioni indirizzate a problemi sempre più circoscritti.

L’ecosistema NoSQL viene tendenzialmente suddiviso in categorie, qui di seguito illustro le principali:

  • Orientati ai Documenti (CouchDB, MongoDB, IBM Lotus Notes Storage Format, ecc..)
  • Chiave/Valore (BigTable, Redis, SimpleDB, Tokyo Cabinet, Redis, Memcached, Project Voldemort, ecc..)
  • Grafici (FlockDB, AllegroGraph, DEX, Neo4j, ecc..)

A loro volta, alcune di queste categorie, vengono poi divise in base ad altre caratteristiche, che possono essere l’utilizzo della RAM al posto del Disco per registrare i dati, oppure in base al fatto che la coerenza sia raggiunta eventualmente invece che certamente… Si potrebbe continuare, ma mi fermo qua, perchè l’ecosistema è davvero eterogeneo, e forse, in questo momento una classificazione più approfondita non esiste neppure. Ogni strumento ha i suoi pro ed i suoi contro, andando a soddisfare delle nicchie che stanno trovando sempre più riscontro con la realtà delle applicazioni web che nascono ogni giorno.

Conclusione

In conclusione, è evidente che il modello relazionale sia stato usato ed abusato negli anni per cercare di soddisfare qualsiasi tipo di necessità. Probabilmente i Database dell’ecosistema NoSQL, col passare del tempo potranno dire la loro anche in ambiti non distribuiti. Il non dover obbligatoriamente avere uno schema rigido e predefinito ad esempio, in alcune situazioni può sicuramente essere un vantaggio sul modello relazionale, soprattutto in fase di sviluppo.

E’ anche vero che non tutti noi abbiamo le stesse necessità che hanno avuto Google, Amazon, Facebook e Co., ma è anche vero che i giganti del Web hanno fatto da apripista ad un modo di pensare che fino a pochi anni fa non era neppure contemplato.

La nascita del movimento NoSQL ci da gli strumenti giusti per riuscire a risolvere un gran numero di problemi. E questo non farà altro che affincare alla Polyglot Programming la Polyglot Persistence.

Sempre più spesso infatti, si avrà a che fare con sistemi composti da applicazioni scritte in diversi linguaggi di programmazione, che sfrutteranno diverse tecnologie per immagazzinare i propri dati, in modo da risolvere nel modo più efficiente le problematiche di questo web in evoluzione continua.

Ad ogni modo, questo non significa che i Database Relazionali siano morti, ma sicuramente man mano che passerà il tempo, vedremo ridursi il loro utilizzo indiscriminato.

Alla conferenza sul NoSQL tenutasi a Londra ad Aprile del 2010, si è posta molta attenzione sull’evitare facili entusiasmi, e non si è affatto screditato il modello relazionale, che anzi viene sempre considerato con grande rispetto, soprattutto dopo decenni di utilizzo e di soluzioni che ci hanno accompagnato fino ad oggi, ma si è mostrata una nuova via, al momento sconosciuta ai più che con il passare del tempo potrà portare vantaggio sia ad aziende consolidate che alle StartUp, le quali vogliono iniziare col piede giusto la loro avventura, e per far questo, non c’è modo migliore che utilizzare gli strumenti giusti.

Risorse ed approfondimenti

  • http://gsantomaggio.wordpress.com/ Gabriele Santomaggio

    L’articolo è molto interessante, in futuro sarebbe bello riportare anche esperienze dirette sull’utilizzo dei NoSQL.
    Concordo pienamente su “evitare facili entusiasmi”,prima di togliere un Oracle o similari ci penserei 1000 volte.

    Io ho provato MongoDB, e seguo Couchdb.
    MongoDB è molto performante ed è ad un buon livello di stabilità, CouchDB mi affascina perché scritto in Erlang.

    Consiglio anche:
    http://www.drdobbs.com/architecture-and-design/224900500?pgno=3

    Ciao
    - Gabriele

  • http://davidfunaro.com David Funaro

    Veramente Ottimo articolo. Ancora non mi ero interessato a questo settore ed ora mi sono incuriosito a tal punto che sto andando a scaricare MongoDB.

    Relativamente a questa tematica ci sarà a Brescia il NOSql Day:
    http://www.nosqlday.com/

  • http://nosqlday.it nosqlday
  • http://massimilianoarione.it Massimiliano Arione

    Non vorrei fare il rompipalle, ma consistency = coerenza, NON consistenza.

  • mirkobonadei

    Ciao Massimiliano, ottima puntualizzazione, provvedo subito a correggere. Grazie :)

  • mirkobonadei

    @nosqlday: Grazie per l’informazione.
    E’ un’ottima occasione per chiarire dubbi e sentire qualche esperienza reale e concreta sull’utilizzo delle Basi di dati NoSQL.

  • mirkobonadei

    Ciao Gabriele, grazie per il link. Se in futuro avrò l’opportunità di fare esperienze dirette, sicuramente scriverò un post da queste parti :)
    Ottimo sapere che sei affascinato da Erlang. Io lo sto studiando da qualche mese, presto spero di poter scrivere un post qui sul blog degli Indigeni.

  • http://gsantomaggio.wordpress.com/ Gabriele Santomaggio

    Ciao Mirko,
    Con Erlang ci ho lavorato un po’ quando ho utilizzato http://www.rabbitmq.com, che per curiosità di consiglio di vedere.
    Molto bello anche MNesia,
    http://www.erlang.org/doc/apps/mnesia/Mnesia_chap1.html#id60703, db scritto in Erlang.
    Attendo con ansia i post che parlano di Erlang :) )!!!

  • Mauro Pagano

    Parto dicendo che sono rimasto veramente affascinato da BigTable la prima volta che ne ho sentito parlare (non troppo tempo fa).
    Il motivo per cui i NoSQL secondo me non “cambieranno il mondo” delle basi dati e’ dovuto al fatto che sono essi stessi ancor piu’ specifici dei modelli relazionali, sono “bravissimi” a fare quello per cui sono stati progettati, meglio di un modello relazionale in quell’ambito…ma secondo me li restano, spiego il perche’ della mia affermazione.
    Google, Facebook, etc hanno esigenze decisamente al di fuori della norma, per svolgere compiti specifici adottare un modello relazionale (e un prodotto commerciale) potrebbe avere diverse limitazioni per il futuro.

    Dall’altra parte la combinazione di tali esigenze specifiche (BigTable non e’ fantastico perche’ gestisce bene esigenze chiave/valore ma perche’ lo fa per miliardi di combinazioni in maniera efficente e a basso costo) e’ piuttosto difficile da trovare in giro secondo me.
    Quante realta’ aziendali hanno tali necessita’?
    Quale sarebbe il costo per un’azienda nell’adottare una tecnologia simile ed utilizzarlo per i propri scopi?

    Dall’altra parte adottare un modello ben conosciuto (il relazionale e’ stato definito inizialmente circa 40 anni fa) ha il vantaggio di fornire un grandissimo bacino di conoscienza di tutte le metodologie utili per sfruttare il relazionale in diversi modi (ie. non solo forme normali ma denormalizzate che permettono di meglio gestire alcune necessita’, vedi star schema o snow-flake)

    Se a questo aggiungiamo che prodotti commerciali (ie. Oracle) forniscono in aggiunta al modello relazionale diverse altre forme di organizzazione / memorizzazione dati (ie. multidimensionale , XML DB, etc) tutto interrogabili attraverso SQL ecco che l’SQL sembra lontano dai suoi ultimi giorni o dal suo abuso :-)

    In conclusione penso che questi nuovi modelli riescano a coprire esigenze di nicchia che rischierebbero di essere forzatamente servite usando un modello relazionale, ma in questo non vedo una limitazione del relazionale stesso ma piu’ che altro un’evoluzione dei “requisiti” (piuttosto rara ad oggi, necessita’ tali forse saranno piu’ comuni in futuro) che porta alla necessita’ di introdurre nuovi approcci.

    Un po’ come accadde per le basi di dati ad oggetti, ad oggi non so quante ce ne siano in giro ma i framework di object-relational mapping spopolano di brutto :P

    Tutto questo ovviamente e rigorosamente IMHO!

  • mirkobonadei

    Il punto di vista che proponi è condiviso da moltissime persone ed io stesso sono d’accordo con quello che hai scritto.

    Io però vedo le basi di dati relazionali come uno strumento ottimo, che però ha preso negli anni un monopolio incontrastato per via delgli ottimi risultati che ha ottenuto in svariati ambiti (si insegna praticamente solo quello). Già l’Object relational mapping pone un livello in più per riuscire a far rientrare una logica ad oggetti in una logica relazionale.
    Tutto ciò funziona alla grande, ma l’esplosione di Internet, e di modi di creare applicazioni diverse dal passato ha in alcuni casi messo in difficoltà i relazionali. Vuoi perchè si debbano immagazzinare molti dati che di relazionale non hanno nulla, vuoi che si debba replicare il tutto per sicurezza e disponibilità del servizio (e qua tenere il relazionale in alcuni casi è deterrente), vuoi perchè una StartUp voglia tenere uno schema libero nel proprio DB per evitare di dover poi stravolgere il tutto in futuro.
    Questo ha portato alla nascita di nicchie che ovviamente non possono essere paragonate al modello relazionale, ma devono essere viste come strumenti di lavoro, e sta a noi che li usiamo saper scegliere quello adatto, evitando ovviamente facili entusiasmi per la nuova tecnologia (che potrebbero poi portare a problemi maggiori).

    Praticamente i nostri due commenti si completano a vicenda, ma il succo del discorso è quello. :)

  • Pingback: Buoni Propositi per il 2011 « David Funaro

  • Pingback: Mirko Bonadei » Blog Archive » NoSQL Day 2011 – Mirko Bonadei’s Blog

Previous post:

Next post: