La terra è piatta!... o forse no?!?! piccolo viaggio verso il NoSQL

I database rappresentano uno dei punti fondamentali della composizione di qualunque progetto o soluzione informatica. La capacità di raccogliere ed organizzare le informazioni è alla base dell'informatica - in quanto scienza dell'informazione (e quindi del suo trattamento)

Negli ultimi 20 anni il Database (per definizione) è sempre stato idealizzato con il modello relazione descritto negli anni 70 da CODD (http://en.wikipedia.org/wiki/Relational_database).

Un modello che introdusse una serie di concetti rivoluzionari per l'epoca, ad iniziare dal legame tra il valore dell'attributo e la relazione tra insiemi (in contrapposizione dal modello che prevedeva puntatori e legami posizionali)

Oggi però, a 40 anni dalla sua formulazione, il modello di Codd evidenzia alcuni limiti. Limiti che sono sempre stati presenti e conosciuti, ma che fino ad oggi erano stati superati maggiore potenza di calcolo e di archiviazione.

Però a differenza di quanto avvenne con l'avvento del modello relazionale di Codd, oggi non ci si trova davanti a delle rielaborazioni tali da mettere in discussione tale modello - come avvenne con i sistemi reticolari e gerarchici - eppure è in corso una contrapposizione quasi "filosofica" tra i i difensori del modello relazione e "gli altri".

Nel corso degli anni gli "altri" sono stati classificati come NoSQL (http://it.wikipedia.org/wiki/NoSQL), ma in effetti sono differenti soluzioni che non rinnegano i principi del modello relazione, ma ne evidenziano i limiti e le forzature d'uso.

Però pare che in molti ambienti Aziendali  - e non Enterprise perchè li R&D funzionano veramente - mettere in discussione i RDBMS ed il paradigma SQL pare essere equivalente a dire che la terra non è piatta e gira intorno al sole: si rischia di essere additati come eretici!

Eppure la terra è tonda! 

E non vuol dire che le mappe fino ad oggi utilizzate non sono corrette. Semplicemente che per alcuni scenari che vanno oltre gli orizzonti previsti dal modello relazionale, è necessario utilizzare altri paradigmi....

Ho da poco finito di leggere "Instant MongoDB" ( http://bit.ly/17RQbZ7 ), ed è un testo interessante e sufficientemente leggero per chi volesse iniziare ad affacciarsi sul mondo del NoSQL e di MongoDB.

Il testo è scritto con un inglese semplice e scorre velocemente, ed introduce ad alcuni concetti fondamentali del mondo NoSQL:

• SchemaLess: Schema for Read vs Schema for Write
• Modalità di interrogazione
• Cursori
• Operatori
• Attributi annidati
• Modalità di aggiornamento
• creazione
• $set e $unset
• aggiornamento del documento vs aggiornamento delle proprietà
• aggiornamenti di massa
• Indici
• Disegno di una soluzione: Modello Relazionale e Modello Document Oriented
• Aggregation Framework
• Map / Reduce

Innanzitutto si chiarisce un concetto che ultimamente è sempre più presente: la modellazione di un database è inadeguata a rappresentare i vincoli dettati dalle "regole di business", e sempre più spesso si tende a tralasciare i vincoli relazionali per concentrarsi sulla consistenza delle regole di business.

Da questo comportamento derivano due assunzione fondamentali per comprendere il modello NoSQL;

1. che è inutile fare il lavoro due volte: se l'applicativo dovrà controllare la consistenza di vincoli applicativi dovrà anche verificare la coerenza delle "relazioni"
2. lo storage ha un costo ed un valore di gran lunga inferiore rispetto ai costi di calcolo ed alla velocità di elaborazione: una ridondanza minima di informazioni (come la duplicazione di una etichetta) è da interpretare come una ottimizzazione di risorse e non come un errore di implementazione

Particolarmente interessante il capitolo "Designing the Collection". Avendo chiari i concetti sulle modalità di interrogazione e di inserimento, questo capitolo, facendo il paragone tra la creazione di un modello relazione e un modello documentale, chiarisce molte delle più comuni domande sulla mancanza di join, di schemi e di aggregazioni.

Alcuni appunti che mi sento di fare:

1. Si parla di Scalability all'inizio come uno dei punti forza di MongoDB, ma non se ne danno altri accenni, così come non si parla nè di nodi nè di cluster.
2. Introdurre il concetto di nodi e cluster renderebbe ancora più esplicita la potenza nascosta dietro il "Map/Reduce": potrebbe apparire una sorta di iteratore o di ciclo, ma la reale capacità è quella di poter essere eseguita parallelamente su differenti nodi del sistema.
3. il libro si chiude ricordando che difficilmente ci si troverà ad operare direttamente sul database, ma esistono driver specifici per i vari linguaggi di programmazione: un accenno dei principali progetti e driver sarebbe stato interessante (ma probabilmente sarebbe servito un altro libro)

Detto questo... Buona Lettura