Corso MongoDB: basi del database no-sql più usato al mondo

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.

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à.

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.

Capiremo perché mancano le Join e le Transaction su MongoDB e vedremo qual'è l'alternativa che ci offre, ovvero le Pre-Join.

Join e transaction in un ambiente distributo

Abbiamo detto che MongoDB non supporta né joins e né transactions e questo è considerato qualcosa di inconcepibile da chi viene dai database relazionali, cerchiamo di fare chiarezza e vediamo perché effettivamente non le supporta. Facciamo uno sforzo di fantasia e proviamo ad immaginare come distribuire il nostro database classico, con tabelle e tutto il resto, in un ambiente distribuito, ossia in un insieme di server collegati tra loro.

La prima domanda che sorge spontanea è: con quale criterio distribuisco le mie tabelle nei vari server? E come faccio a fare le joins una volta che queste sono distribuite?

Qualcuno potrebbe rispondere in modo classico: “mettendo tutte le tabelle in tutti i server così da supportare le joins”, ma questo in realtà non realmente è scalabile.

Qualcun altro potrebbe pensare di dividere la tabella più grande su più server e quelle più piccole copiarle in tutti i server, tanto sono piccole...un po’ come lo star schema. È vero, è una soluzione scalabile e supporta le joins, ma c’è un piccolo problema: lo star schema parte dal presupposto che abbiamo un’unica tabella grande ma, questo non è applicabile a tutte le situazioni, noi possiamo avere più tabelle grandi da voler dividere, quindi lo star schema non è applicabile.

Dividendo le varie tabelle sui servers dobbiamo ricordarci che una query di join molto probabilmente coinvolgerà più server, quindi i tempi di attesa per avere un risultato aumenteranno. Se quando effettuo una join le tabelle che vado a richiamare sono distribuite solo su due server può andarmi anche bene, e magari la query risulta veloce, ma dal momento che, siamo in un sistema scalabile posso avere 2 come posso avere 20 o 30 servers coinvolti! E in questi casi avremo dei tempi d’attesa secolari.

Se con le join c’è qualche difficoltà proviamo a pensare a quei rari casi in cui usiamo le transactions, sono sicuramente utili ma immaginiamocele in un ambiente distribuito, dobbiamo considerare gli eventi di commit e rollbak in tutti i server coinvolti senza dimenticarci che sono soggette alle proprietà ACID (Atomicity, Consistency, Isolation, Durability).

Ah mi raccomando occhio ai tempi di attesa! Nessuno vuole un database con delle pessime performance!

Insomma diventa veramente molto complicato implementare joins e transactions in un ambiente distribuito, questo però non è un problema solo di Mongo ma bensì di tutti i database che vogliono essere realmente scalabili.

Mi piace pensare che tra Dwuit ed Eliot ci sia stata una conversazione di questo tipo e che abbiano scelto molto semplicemente di usare un altro approccio ai dati.

Abbiamo visto che ci sono dei reali problemi pratici nell’applicare queste due funzionalità in un ambiente distribuito e MongoDB non può di certo rinunciare alla scalabilità dato che è il suo primo obiettivo, quindi ha dovuto per forza rinunciare a queste due funzionalità.

Però immaginarsi un database senza joins non è cosi semplice, quindi cerchiamo di capire qual è stato l’approccio di Mongo per creare comunque un qualcosa di utile e potente.

Pensiamo all’ambiente relazionale, le joins sono essenziali e senza è impossibile creare qualcosa di meglio quindi dobbiamo sicuramente cambiare l’approccio: ci serve qualcosa che sia potente, agile e flessibile!

Ci sarebbero i key value store, con set e get, però serve qualcosa di più come ad esempio il Document Oriented in cui i singoli record sono memorizzati come documenti. Precisiamo cosa si intende con Documento perchè spesso si crea confusione, il termine documento si utilizza quando si parla di database ed equivale ad un oggetto della programmazione ad oggetti, quindi dire oggetto e dire documento in realtà è la stessa cosa.

Abbiamo, così, una corrispondenza diretta tra la programmazione ad oggetti e i dati presenti nel database che rende il Document Oriented agile e flessibile cosicché le aziende possano adattarsi ai cambiamenti più velocemente.

Ora ci manca solo la codifica ed è ovviamente il JSON! È familiare, nel senso che è umanamente leggibile al contrario dell’XML, è una codifica indipendente e ha il suo standard.

Adesso abbiamo tutto quello che ci serve per risolvere il problema delle joins, ovvero le pre-join o embedding, o incapsulazione, o denormalizzazione...chiamatelo come volete!

Essenzialmente il concetto è questo: quando noi effettuiamo una join tra due tabelle ci aspettiamo che i dati vengano uniti in un unico risultato e fin qui è semplice. Le pre-join usano il processo inverso, partono dal risultato già unito cioè: già prima di salvare nel database il nostro dato noi includiamo al suo interno anche altre informazioni, un po’ come se fosse il risultato di una join.

Qualcuno ha capito? Forse spiegato in questo modo risulta un po’ confusionario anche se in realtà è veramente semplice, meglio vedere subito un esempio pratico.

Immaginiamo di essere in un database relazionale e di avere due tabelle: clienti e veicoli.

Nella tabella cliente ogni riga è un cliente con il suo ID, mentre nella tabella veicoli abbiamo la lista di vari veicoli di diverse marche e una chiave esterna per identificarne il proprietario. Con una normale join possiamo ottenere tutti i veicoli per ogni cliente.

Vediamo ora cosa ci propone Mongo. Non avendo le joins dobbiamo unire le informazioni già prima di salvare il dato nel database, proviamo a fare l’esempio di Alberto: creiamo un nuovo documento, copiamo i dati cliente (Alberto, Olla, ecc.), adesso dobbiamo includere i dati dei veicoli di Alberto al suo interno quindi creiamo un array di oggetti dove ogni oggetto è un diverso veicolo, mettiamo la Smart, la Ferrari, ognuno con i suoi attributi. In Mongo non ci servirà più la tabella veicoli perché quelle informazioni saranno incluse in quelle di ogni proprietario.

Guardate com’è molto più leggibile, è diventato immediato! Abbiamo unito i dati di due tabelle all’interno di un solo documento che contiene tutte le informazioni che vogliamo.

Nel documento di Alberto possiamo aggiungere tutto quello che ci pare, ad esempio un punto gps utile per le query geospaziali, ovviamente se volessimo inserire un altro cliente, come Marta, dovremo creare un nuovo documento che avrà una struttura del tutto simile a questa.

Questo approccio è veramente figo e assicura a Mongo delle ottime performance, con una semplice query di selezione otteniamo gli stessi risultati che avremmo con una join relazionale!

Riassumiamo le caratteristiche principali di MongoDB, vedremo la sua nuova terminologia e introdurremo la shell e i drivers.

Cos'è MongoDB?

Cerchiamo di riassumere le caratteristiche principali di Mongo e nel mentre vediamo qualche esempio.

Abbiamo detto che MongoDB è un database non relazionale orientato agli oggetti che usa la codifica json, fin qui nulla di nuovo, non fatevi spaventare da BSON, tra poco vedremo cos’è.

Facciamo un rapido esempio, convertiamo una comune tabella degli animali su MongoDB.

Mongo è “schemaless” ovvero senza schema, per essere più precisi diciamo che ha uno schema dinamico in cui ogni documento ha una sua struttura che può essere modificata in qualsiasi momento. Questo vuol dire che se volessimo aggiungere qualche attributo in più al delfino, come ad esempio in quali oceani vive, non dovremmo far altro che aggiungere una nuova lista di stringhe con i vari oceani.

Questo passaggio così banale è allo stesso tempo fortemente innovativo, se fossimo in un database relazionale avremmo dovuto creare due nuove tabelle, una per inserire i vari oceani e l’altra per inserire la relazione tra oceani e animali, che però sarebbero state inutili per la pantera!

La flessibilità di Mongo ci permette di avere attributi diversi per ogni singolo documento, cosa impensabile nei database relazionali! Possiamo, quindi, aggiungere liberamente alla nostra pantera attributi più caratteristici come il numero di zampe o le nazioni in cui vive, senza dare alcun fastidio agli attributi del delfino, che si trova in un altro documento.

In ogni lezione ripetiamo che il primo obiettivo di Mongo è la scalabilità quindi, ovviamente, ci deve offrire degli strumenti per sfruttarla; ce ne offre due, uno più importante dell’altro, e sono la Replication e lo Sharding.

Con Replication intendiamo la replica fisica dei dati tra un server primario e dei server secondari. Mongo si preoccupa di tenere i dati sincronizzati e nel caso il server primario risulti irraggiungibile elegge automaticamente un server secondario per prendere il suo posto.

Sharding deriva da shard che vuol dire frammento, scheggia, lo sharding ci permette di separare il nostro database su più server, e sarà Mongo stesso a preoccuparsi di distribuire e tenere costantemente bilanciati i dati.

Inoltre abbiamo detto che Mongo è ricco di funzionalità tra le quali gli indici di ricerca, le query geospaziali, il map reduce, gli strumenti per effettuare ricerche sul testo e un sistema di aggregazione dei risultati.

Ci offre davvero tantissimi strumenti che non possiamo approfondire come vorrei. Queste lezioni sono solo un esperimento, una guida basica e introduttiva al magico mondo di MongoDB, quindi mi dispiace ma non vedremo nulla di “avanzato”, niente replication, niente sharding e niente strumenti per i particolari tipi di query! Ma non vi preoccupate c’è tanto di cui parlare ugualmente.

Fino ad ora abbiamo sempre usato il termine tabella ma in realtà Mongo introduce una nuova terminologia.

Il database continuiamo a chiamarlo database, le tabelle invece vengono ribattezzate collections, le righe delle tabelle vengono chiamate documenti o oggetti, in base alle vostre tendenze, gli index ovvero gli Indici di ricerca rimangono uguali, ci consentono di recuperare più velocemente i dati di una collection evitando la lettura dell’intero contenuto, mentre le joins come abbiamo visto non ci sono ma abbiamo comunque le pre-joins o embedded documents ed infine le chiavi esterne su Mongo non esistono nel senso che non non c’è un meccanismo per gestirle ma nulla ci vieta di usare dei riferimenti.

Quindi usando una terminologia più adatta a Mongo, il database non è altro che un insieme di collezioni di documenti.

Adesso vediamo una panoramica di un’applicazione per dare un’idea generale di come usare MongoDB.

Abbiamo la nostra applicazione, che sarà scritta nel linguaggio che più preferiamo (node, scala, php, quello che volete…) e ovviamente non possono mancare gli utenti, che possono contattarla in qualsiasi modo (da desktop, api, applicazioni mobile e quant’altro).

Se la nostra applicazione sarà un minimo utile avrà sicuramente l’esigenza di avere un database per poter salvare i dati in maniera permanente, ed è qui che entra in scena Mongo. È dotato di una shell amministrativa in cui possiamo eseguire delle query da riga di comando ma ora come ora è separato dall’applicazione e questo non ci permette di farli comunicare, per fare questo ci servono i drivers.

Quindi installiamo i drivers appositi del linguaggio che stiamo utilizzando per poter lanciare interrogazioni al database direttamente dalla nostra applicazione.

Abbiamo detto che MongoDB utilizza la codifica JSON, però lo fa solo quando parla con noi essere umani: cioè quando deve mostrare qualcosa a video. Internamente, invece, salva tutti i dati in forma binaria, per questioni di storage e performance, convertendoli in BSON ovvero Binary JSON, è un procedimento che fa in automatico quindi non spaventatevi, per noi non cambia nulla.

Il BSON lo usa solo tra server (come ad esempio tra il database e l’app) mentre il JSON diciamo è per l’umano (come nella shell).

Quando lanciamo una query tramite i drivers il risultato che ci restituisce è in formato BSON e viene allocato direttamente in RAM, quando poi viene passato al driver in attesa di risposta non viene convertito in JSON ma bensì nella struttura dati nativa del linguaggio che state utilizzando, se usate node.js o PHP sarà un array mentre se usate python sarà un oggetto, ogni linguaggio ha il suo tipo di dato.

Questo schemino era giusto per darvi un idea di come interagisca Mongo all’interno di un’applicazione. Abbiamo detto che i modi per interrogare Mongo sono due: la shell amministrativa e i drivers; vediamoli molto brevemente.

La shell è esattamente quello che ci aspettiamo, ovvero una console a riga di comando, al suo interno abbiamo un interprete javascript che ci permette di interrogare direttamente il database. È utilissima per effettuare test e attività amministrative.

Quando invece è la nostra applicazione a voler comunicare con il database allora dobbiamo usare i drivers; vanno installati e sono pronti all’uso, ormai sono presenti i drivers per tutti i linguaggi più popolari e sicuramente anche per il vostro preferito.

Noi ovviamente in queste lezioni approfondiremo solamente la shell, non useremo mai nessun linguaggio e di conseguenza non vedremo nessun driver.

È pur sempre un corso base quindi è meglio non andare troppo oltre con gli argomenti altrimenti non mi basterebbe il tempo per girare tutti i video!

MongoDB può essere installato su tutti i più famosi sistemi operativi: Windows, Linux, MAC OS X

Installare MongoDB

Ahh era ora, abbiamo parlato un sacco di quanto è bello Mongo teoricamente ma non sappiamo ancora nulla di come funziona nella pratica, finalmente in questa lezione possiamo vederlo; ma ovviamente prima dobbiamo installarlo, quindi procediamo :)

Cominciamo subito con l’andare su google, scriviamo “MongoDB download” ed entriamo nel primo risultato organico, quindi non su eventuali pubblicità.

Ci troveremo di fronte una pagina come questa. Attualmente è disponibile la versione 3.0.6, selezioniamo il nostro sistema operativo e scarichiamo il file.

Io uso Windows quindi vedremo come si installa MongoDB su Windows 10. Per tutti gli altri che usano Mac e Linux…beh confido nella vostra intelligenza, suppongo riuscirete comunque nell’impresa, se poi doveste avere problemi qui trovate le istruzioni o chiedete pure sul forum.
Torniamo a Windows, selezioniamo il file nella versione 64bit e clicchiamo download. Per fare dei test si potrebbe usare anche la versione a 32 bit, ma ha delle limitazioni quindi è da escludere per la produzione.

Ora che abbiamo scaricato l’eseguibile, apriamolo e avviamo l’installazione: avanti, accettiamo la licenza, installazione completa, installa e attendiamo...eee...fatto!

È stata dura…andiamo a frugare le cartelle e vediamo cosa ha installato.

Andiamo su C, programmi, MongoDB, server, versione 3, bin. In questa cartella abbiamo una serie di eseguibili, quelli che andremo ad usare più spesso sono mongo e mongod, mongo è la shell mentre mongod è il server.

Prima di poterli usare dal nostro prompt dei comandi di windows dobbiamo fare una cosa, copiamo il percorso della cartella bin e andiamo su sistema, impostazioni di sistema avanzate, clicchiamo su variabili d’ambiente e nel riquadro variabili del sistema cerchiamo Path. Clicchiamo su modifica, andiamo alla fine, aggiungiamo il punto e virgola, e incolliamo qui il percorso.

Ok, ok e ok, adesso possiamo lanciare gli eseguibili presenti nella cartella bin direttamente dal prompt dei comandi di Windows, proviamo subito.

Apriamo il prompt e scriviamo

mongo --version

Se anche voi avete una scritta come questa possiamo continuare altrimenti avete sbagliato qualcosa nel passaggio precedente.

Ok, creiamo una nuova cartella per salvare i nostri dati del database, copiamo il path

e adesso possiamo lanciare mongod. Per farlo usiamo l’opzione

--dbpath PERCORSO

Eccolo qui, il server è partito e rimane in esecuzione fintanto che non chiudiamo la finestra.

Questi sono i vari log di mongod, se guardiamo meglio possiamo leggere che il server è in ascolto alla porta 27.017, che è la porta di default, e che per i dati utilizza la cartella XXX.

Adesso apriamo un altro prompt e da qui lanciamo la shell amministrativa e vedere se cambia qualcosa nei log del server.

Prima abbiamo lanciato mongod per il server quindi ora lanciamo mongo per la shell, tenterà di connettersi al localhost alla porta 27017. Perfetto, siamo dentro e adesso possiamo interagire direttamente con il database. Se guardate i log del database possiamo vedere il nostro accesso.

Ovviamente la shell funziona perché è connessa al server, se dovessimo chiudere la finestra di mongod la shell perderebbe la connessione.

Benissimo abbiamo completato correttamente l’installazione su Windows. Le proprietà di MongoDB sono comuni in tutti i sistemi operativi quindi tutto quello che faccio io tramite la mia shell potete farlo anche voi a prescindere dal sistema che state usando.

L’abbiamo installato ma non l’abbiamo ancora veramente usato quindi vediamo subito di fare qualche prova pratica.

Innanzitutto quando lanciamo mongod possiamo specificare delle opzioni, abbiamo già visto --dbpath PERCORSO

per indicare la cartella in cui salvare il database. In produzione probabilmente aggiungeremo anche --fork che mantiene il processo aperto anche dopo aver chiuso la finestra oppure --logfile specificando un percorso per poter salvare i file di log, però dato che qui siamo in locale ed è per scopo dimostrativo va benissimo anche solo specificare --dbpath.

Adesso apriamo un altro prompt e colleghiamoci al server, per farlo ci basterà scrivere mongo per lanciare la shell amministrativa che si connetterà di default in locale al database di test. Perfetto, siamo dentro, vediamo ora qualche comando:

DB

ci mostrerà in quale database ci troviamo mentre con

Show DBS

possiamo avere la lista di tutti i database. Possiamo spostarci in altri database usando:

USE nome_database

ad esempio USE demo, questo database non c’era nella lista perché in realtà non esisteva ancora, anche adesso che ci stiamo spostati al suo interno non è realmente stato creato poiché viene creato automaticamente quando tentiamo di usarlo.

Proviamo a fare un operazione nel database, scriviamo:

db.animals.find()

db è un oggetto speciale all’interno della shell e identifica il nostro database, users è il nome della collection che ovviamente ancora non esiste e find è il comando che equivale a una Select, quindi è una ricerca. Quando scriviamo questo comando stiamo dicendo a Mongo: “vai, prendi il database in uso (in questo caso demo), considera la collection Animals e cerca tutti i documenti al suo interno”.

Ovviamente il risultato è vuoto perchè non abbiamo mai usato prima questa collection che materialmente non esiste, ma viene creata automaticamente quando si inserisce il primo oggetto. Ok, adesso vediamo nel lato pratico i vari esempi che abbiamo fatto sugli animali, proviamo ad inserirne uno, il delfino:

db.animals.insert( { name:”delfino”,color:”grigio”})

Ricordiamoci che tutti i documenti JSON devono essere tra parentesi graffe {}, aggiungiamo anche gli oceani, oceans, come un array [“atlantico”,”pacifico”,”indiano”].

Per vedere tutti i nostri documenti scriviamo:

db.animals.find()

Possiamo vedere che è stato aggiunto _id di tipo ObjectID, questo è un attributo speciale che viene inserito automaticamente da Mongo quando non viene specificato durante l’inserimento.

Proviamo ad inserire un nuovo documento JSON, ad esempio aggiungiamo la pantera:

db.animals.insert( { name:”pantera”,color,”nero” } )

Ci ha dato un errore di sintassi perchè il nostro documento è scritto male, nel primo elemento abbiamo chiave name e valore Pantera ed è corretto, poi abbiamo la virgola che indica di passare all’elemento successivo. Nel secondo elemento abbiamo soltanto color ma non abbiamo precisato se chiave o valore e subito dopo abbiamo un’altra virgola che ci indica di passare all’elemento successivo “nero”, sbagliatissimo, ogni elemento JSON deve avere sempre una chiave ed un valore quando questi non ci sono ovviamente la shell ci segnala l’errore. Correggiamolo:

db.animals.insert( { name:”pantera”,color:”nero” } )

Proviamo ora ad aggiungere qualcosa di più complesso, ad esempio in quale zoo la possiamo trovare. Facciamo un array di sottodocumenti dove ognuno è l’indirizzo di un diverso zoo:
zoos: [
{

name:”Zoo di Dublino”,

address: {

street:”Phoenix park, Dublino 8”,

city: “Dublino”,

country:”Irlanda”

}

}
]

Vediamo come si presenta nostra collection:

db.aniamsls.find()

quando usiamo find possiamo mettere delle condizioni sempre in formato JSON, ad esempio possiamo dire {name:“pantera”} in questo modo cercherà tutti i documenti in cui la chiave nome corrisponda al valore Pantera.
Cosi si legge un po’ male quindi usiamo

db.animals.find().pretty()

adesso si vede decisamente meglio, abbiamo due documenti con strutture diverse e qui in zoo ogni zoo è un sottodocumento.

Bene, adesso facciamo un’altra prova:

db.animals.findOne({name:”pantera”})

findOne a differenza di find ci restituisce solo 1 risultato. Proviamo, perfetto.

Ricordiamoci che siamo su javascript quindi possiamo scrivere qualcosa come

var p = db.animals.findOne({name:”pantera”})

ora in p abbiamo il nostro documento. Proviamo a modificarlo aggiungendo un altro attributo:

p.legs = 4

db.animals.save(p)

db.animals.find().pretty()

Vedete? È stato salvato. Per fare la modifica abbiamo usato la funzione save che è una sorta di scorciatoia per un update o per una insert. Se scriviamo db.animals.save senza parentesi Mongo ci mostra il codice della funzione...guardate, qui c’è una condizione che controlla se la variabile ricevuta possiede l’attributo _id, se lo possiede fa un update altrimenti un insert dal momento che non esiste un identificativo. Sembra difficile ma non preoccupatevi, lo vedremo meglio nella seconda parte del corso.

Per vedere la lista di tutti i comandi disponibili possiamo digitare il comando:

help

Possiamo anche lanciare l’help per ogni oggetto speciale, come ad esempio per i database e le collection:

db.help()

db.nome_collection.help()

ma può essere anche lanciato per lo sharding o per il replica set.

Un altro comando utile è il comando show che consente di mostrare le liste dei database:

show dbs

e delle collection:

show collections

Insomma, ci sono davvero tantissimi comandi che vi consiglio di scoprire ;)

Tutto ciò che bisogna sapere sul JSON e sul BSON (Binary JSON) per utilizzare MongoDB.

JSON: dati object-style facilmente leggibili

Il JSON non è l’unica codifica o linguaggio orientato ai documenti, c’è anche l’XML, il suo fratellastro brutto. L’XML tende ad essere più pesante nell’interpretazione, nel parsing e poi è proprio umanamente meno leggibile, guardate!

Questo è un piccolo esempio di documento XML, non si capisce praticamente niente, bisogna proprio sforzarsi parecchio per capire cosa rappresenta.

Se guardate invece il documento JSON non c’è paragone in fatto di semplicità, è leggero e senza grassi quindi JSON tutta la vita.

Adesso facciamo un piccolo ripasso della sintassi e dei tipi di dato, JSON ne supporta ben 6:
abbiamo le stringhe, sempre tra le virgolette, valori numerici (quindi senza virgolette), booleani (true o false), NULL per i valori nulli, gli array: delle liste ordinate di valori caratterizzate delle parentesi quadre, non ci sono restrizioni per i valori della lista, quindi può contenere sia numeri che stringhe o qualsiasi altra cosa, ed infine il sesto tipo sono gli oggetti o documenti: intesi come mappe associative chiave-valore caratterizzati dalle parentesi graffe, al loro interno possiamo inserire quello che ci pare: altri attrbuti e anche altri oggetti.

JSON: alcune cose da ricordare

Innanzitutto, il JSON è formato da una lista di chiave e valore, mentre i valori possono essere di sei tipi diversi, quelli che abbiamo appena visto, la chiave può essere solo e sempre una stringa.

Lo standard consiglia di usare sempre le virgolette per le chiavi ma in realtà nella shell di Mongo possiamo ometterlo a patto che la chiave inizi con una lettera, in questo caso capirà da solo che si tratta di una stringa, mentre se iniziasse con un numero allora ovviamente le virgolette diventerebbero obbligatorie.

In caso lo stesso documento abbia due chiavi ripetute viene considerato il valore dell’ultima dichiarazione; cioè se noi stiamo salvando un oggetto dove l’attributo Nome è settato con due valori diversi, quando lo salveremo nel database sarà presente solo l’ultimo valore assegnato.

Nel JSON abbiamo solo due strutture dati basilari che possiamo combinare in tutti i modi che ci vengono in mente: gli array e i dizionari (in sostanza gli oggetti o documenti).

Se ci fate caso tutti i documenti JSON che abbiamo visto sino ad ora erano a loro volta dei dizionari.

BSON (Binary JSON)

Il BSON è la rappresentazione binaria del JSON, questa frase fa sorgere altri dubbi? Non importa, tanto il BSON viene utilizzato internamente, in maniera totalmente automatica, per questioni di efficienza, praticamente a noi non cambia proprio niente, viene gestito tutto da Mongo e dai drivers.

Il BSON permette a Mongo di effettuare scansioni dei documenti molto veloci. Pensiamo ad esempio ad un lungo articolo con un testo che da solo pesa 200 KB. Se a noi servisse l’attributo successivo ai 200 KB, senza una scansione intelligente dovremmo analizzare tutti i suoi attributi precedenti con uno sforzo inutile invece il BSON consente a Mongo di saltare tutto e andare dritto all’attributo che ci serve.

Questi sono tutti meccanismi interni, a noi basta sapere che il BSON consente a Mongo di estendere i 6 tipi del JSON aggiungendone qualcuno nuovo. Abbiamo il tipo Date, che come potete facilmente immaginare serve per le date, il tipo BinData che viene usato per i sorgenti di immagini, file e simili quindi dati binari, ed infine forse il più importante che vi capiterà di usare più spesso è l’ObjectID, ogni documento su Mongo deve obbligatoriamente avere l’attributo _id quindi hanno pensato di creare un tipo apposito per ottenere uno storage più compatto.

Questo è tutto quello che bisogna sapere sul JSON e sul BSON per usare Mongo.

Vedremo cosa si intende effettivamente con Schema Dinamico e i maggiori vantaggi che porta.

Senza schema, più precisamente a schema dinamico

Spesso si legge in giro che MongoDB è “schemaless”, letteralmente senza schema, ma in realtà non è proprio così.

Infatti ha un suo schema interno, praticamente è come un catalogo: una lista di database dove ogni database contiene le sue collections, ogni collection ha i suoi indici interni e contiene i suoi documenti.

In ogni documento se non è presente l’attributo _id viene implicitamente creato e ogni collection ha già un indice di ricerca proprio sull’_id. Volendo possiamo creare anche degli altri indici su altri attributi per velocizzare le nostre query. Ad esempio, ipotizziamo di avere una collection con molti documenti, lanciare una query su un attributo senza indice è poco performante perché bisogna accedere ad ogni singolo documento mentre, una query su un attributo con l’indice è molto più veloce perché è come effettuare una ricerca in una mini-collection formata solo dai valori del nostro attributo.

In aggiunta tutta la parte a schema dinamico offre enormi vantaggi: diversi documenti nella stessa collection possono avere differenti schemi supportando quindi il polimorfismo, che tra poco vedremo, inoltre possiamo avere una corrispondenza diretta tra i dati nella programmazione ad oggetti e il database. Questo facilita molto la programmazione e ovviamente le aziende possono adattarsi più velocemente ai cambiamenti, basti pensare a tutte le metodologie come agile, scrum o extreme programming dove si rilasciano nuove release molto frequentemente.

Vediamo questi vantaggi nel lato pratico, quindi polimorfismo e corrispondenza dei dati tra programmazione ad oggetti e database.

Immaginiamo di avere una superclasse Forme nel nostro linguaggio preferito, abbiamo anche delle sottoclassi come Punto, Cerchio e Triangolo, ognuna con le sue caratteristiche.

Proviamo a pensare a come trasporre questa struttura in un database relazionale.

La soluzione più semplice ed immediata sarebbe quella di creare una tabella Forme e al suo interno mettere ad esempio le prime due forme, così però non consideriamo gli attributi delle sottoclassi.

Il primo è un punto quindi dobbiamo aggiungere x e y e dovremmo modificare la tabella per aggiungere le nuove colonne, stesso discorso per il raggio del Cerchio.

In questo modo la tabella può salvare correttamente gli attributi corretti sia per i Punti sia per il Cerchio però abbiamo dovuto modificare la tabella. Inoltre, le colonne aggiunte per il Punto rimangono vuote per il Cerchio e viceversa.

Non mi sembra un ottima soluzione. Un’altra potrebbe essere creare tabelle diverse per ogni sottoclasse ma diventa ancora più complicato, quindi meglio lasciar perdere...

Vediamo, invece, come risulta su Mongo.

Creiamo una nuova collection chiamata Forme e al suo interno creiamo un documento per salvare un oggetto di classe Punto, mettiamo quindi i suoi attributi x, y e salviamo, corrisponde perfettamente alla classe.

Possiamo aggiungere anche un altro documento nella stessa collection magari di classe Cerchio che quindi a differenza del punto avrà il raggio, anche qui abbiamo una corrispondenza diretta con la classe.

Insomma una soluzione ottima, facile e veloce.

Pensate a quelle situazioni in cui si richiedono tempi brevi per modifiche o aggiornamenti, lo schema dinamico è perfetto!

Ad esempio, se dopo il lancio del nostro nuovo e personalissimo social network ci accorgiamo di esserci dimenticati alcuni attributi degli utenti, ad esempio lo stato sentimentale, dobbiamo essere velocissimi a porre rimedio.

Non dobbiamo per forza fare una modifica enorme su tutti gli utenti già iscritti; ad esempio potremmo renderlo obbligatorio a tutti i nuovi iscritti, in questo modo chi si iscrive dopo la modifica avrà il campo.

Per chi invece si è iscritto prima, possiamo o lasciarlo facoltativo e aspettare che l’utente lo compili oppure potremmo anche inserirlo forzatamante dal database con un valore di default.

Un esempio pratico di come passare da un database relazionale a una struttura in documenti su MongoDB.

Un blog in database relazionale

Fino ad ora abbiamo parlato di un sacco di cose interessanti ma per lo più erano teoriche, in questo video vedremo una cosa che per qualcuno può essere banale ma per me fu illuminante: la prova evidente della superiorità di Mongo. Vediamo un esempio più pratico che mai di come poter “convertire”, di come passare da una database relazionale ai documenti nel caso di un blog.

Non immaginiamoci un blog complicato con mille funzioni, ovviamente è un blog semplice ma sempre valido. Abbiamo sicuramente una tabella dei Post, quindi degli articoli, presumibilmente ogni articolo avrà il suo ID, il titolo, il testo, la data, e una chiave esterna per l’autore, molto comune. Avendo una chiave esterna per gli autori, abbiamo sicuramente un’altra tabella Autori con i dati che preferite, nome e password ad esempio.

Ok, articoli e autori, ogni blog che si rispetti deve dare la possibilità ai propri visitatori di commentare. Quindi, dobbiamo aggiungere una tabella per i commenti con la chiave esterna agli articoli, avremo il nome del visitatore, il corpo del commento e un’eventuale email, un sistema di commenti molto semplice.

Tra la tabella articoli e quella dei commenti c’è una relazione uno a molti, nello specifico un articolo può avere più commenti e un commento può appartenere ad un solo articolo.

Benissimo, se abbiamo tanti articoli ci serve qualcosa per organizzarli, magari un sistema di tag o categorie, quindi creiamo anche questa tabella con solo id e nome.

Le categorie però hanno una relazione con gli articoli di molti a molti, ovvero un articolo potrebbe appartenere a più categorie e una categoria può essere utilizzata da più articoli di conseguenza dobbiamo creare un’altra tabella che faccia da tramite per il collegamento e che quindi avrà sia l’ID del post sia quello del tag.

Benissimo, questo è come potrebbe essere il database relazionale di un blog molto semplice, adesso vi pongo una semplice domanda. Immaginiamo di aver già scritto anche il codice del blog nel vostro linguaggio preferito, quindi ci sarà un homepage, una pagina di dettaglio per il singolo articolo dove poter lasciare un commento e una pagina per ogni categoria. Benissimo, la mia domanda è questa: immaginiamo di voler leggere un singolo articolo, clicchiamo sul titolo e ci viene caricata la pagina ma, per poter mostrare questa pagina a quante tabelle bisogna accedere?

Provate a pensarci un attimo, immaginate la pagina davanti a voi e pensate a quali dati dovete mostrare, mettete pure in pausa il video per pensarci meglio.

Le avete contate?

Sicuramente dobbiamo mostrare titolo e testo dell’articolo quindi dobbiamo accedere alla tabella Articoli e siamo a 1, ovviamente dobbiamo scrivere il nome dell’autore e non il suo ID quindi dobbiamo accedere anche alla tabella Autori, e siamo a 2.

Alla fine dell’articolo mostriamo i commenti quindi accediamo ad un’altra tabella e siamo a 3.

Se fa parte di qualche categoria o se ha dei tag dobbiamo mostrarli, quindi non solo dobbiamo accedere a post-tag la tabella di collegamento ma anche alla reale tabella dei tag quindi siamo a 4 e 5.

Per mostrare la pagina di un singolo articolo abbiamo effettuato l’accesso a 5 tabelle.

Nulla di nuovo, questo è come funziona un blog in un database relazionale, per fortuna che ci siamo tenuti leggeri e avevamo poche “funzionalità” altrimenti avremo dovuto accedere a molte più tabelle.

Un blog in documents

Dobbiamo creare sicuramente una collection per gli articoli. La struttura del documento potrebbe essere più o meno così: il titolo, il corpo dell’articolo, la data e un riferimento per l’autore.

Mancano però i commenti, cerchiamo di mettere in pratica la tecnica delle pre-join. Creiamo un array per i commenti, dove ogni commento non è altro che un documento con i suoi attributi: Nome del visitatore, corpo del commento e un’email; non ci servono chiavi esterne, sappiamo già che è riferito al nostro post perché è incapsulato al suo interno.

Ricordiamoci che l’array è una lista ordinata quindi i commenti hanno già un loro ordinamento.

Per i tags o categorie non c’è nulla di più semplice su Mongo, possiamo creare un altro array dove inseriamo i tags come stringhe, non ci serve un’altra collection, già così possiamo effettuare query per ogni singolo tag.

Ci sarà sicuramente un’altra collection per gli Autori però, questa volta, come id non usiamo un numero ma mettiamo direttamente l’username dell’utente, così facendo non abbiamo bisogno di frugare la collection per mostrare a video il nome, è già l’id.

Quindi, proviamo a ripensare alla domanda di prima questa volta usando Mongo, a quante collection accedo per mostrare la pagina di un singolo articolo? La risposta è solo 1!

Abbiamo già tutto quello che ci serve, ovviamente i dati dell’articolo, dell’autore ci basta l’username ed è già pronto, i commenti son tutti qui e anche i tags, tutto quello che ci serve in un solo documento.

Quando avevo visto questa lezione nel corso sull’university di MongoDB mi ero illuminato; cioè in un database con pochi dati e poche richieste al secondo ovviamente non percepiamo la differenza ma pensate di avere un blog molto seguito con tanti dati e con tante visite simultanee, nella migliore delle ipotesi accedo a 5 tabelle per ogni refresh!

Invece con Mongo basta un niente per eliminare i tempi di attesa per le joins e abbassare il carico del server. Un solo documento per avere tutto quello che ci serve, la struttura proposta è sicuramente già una buona soluzione ma potrebbe essere ancora molto ma molto più performante! Volete sapere con quale magica tecnica possiamo fare tutto questo? Sempre con le pre-join ma applicate con il giusto criterio.

Come strutturare un database su MongoDB per migliorare le performance in lettura, parliamo di schema design.

Quando effettuare l'embedding?

Le pre-join o embedding possono essere potentissime se usate nel modo giusto e d’altra parte per chi non ne comprende l’approccio possono essere completamente inutili, come ad esempio quelli che cercano di usare MongoDB ricreando pari pari la struttura di un database relazionale.

Quindi quando è meglio usarle e quando no? In quali casi e come? Se sappiamo questo anzi se capiamo questo possiamo creare delle soluzioni personalizzate e ultra performanti.

Quindi, cerchiamo di capire in quali casi è consigliabile usarle e perchè.

Riprendiamo l’esempio della lezione precedente, vi ricordate? Avevamo una collection per gli articoli con tag e commenti.

Per i tags potrebbero sorgere alcune criticità come ad esempio il problema delle ripetizioni, potremo avere molti tag duplicati, ovviamente con pochi articoli è irrilevante ma dobbiamo sempre pensare di avere tanti articoli. Se in tutti gli articoli fosse presente uno stesso tag bello lungo avremo una ripetizione e quindi spazio occupato inutilmente dalla stessa informazione. L’alternativa sarebbe usare degli indici numerici per ognuno, in questo modo proprio quel tag così lungo (ad esempio 64caratteri) sarebbe stato un 1 o un 100.

Un altro problema potrebbe essere che avendoli cosi sfusi non possiamo avere un controllo immediato. Immaginiamo di voler sostituire un tag, per un errore di battitura o semplicemente ci siamo accorti che era meglio un altro termine, per farlo dobbiamo fare un replace su ogni documento che ha quel tag; invece con gli indici ci sarebbe bastato modificare il valore una sola volta.

Se usassimo gli indici, però, le performance verrebbero influenzate negativamente, quindi come facciamo? Ci accontentiamo, meglio avere una lettura veloce anche se con dei tag duplicati. Anche il replace non rappresenta un grosso problema dato che la modifica dei tag è un operazione poco frequente, ovviamente rimane sempre possibile sostituirli in modo meno immediato.

Diciamo che la nostra scelta di usare l’embedding è comunque valida perchè è molto raro accedere solo ai tag di un singolo post senza accedere anche al post stesso e lo stesso vale per la lettura dei commenti.

Capire meglio questo concetto è fondamentale e fa un enorme differenza quando si deve strutturare un database, quindi cerchiamo di spiegarlo meglio.

È importante capire quando fare o non fare l’embedding e per farlo ci basta seguire una semplice regola:
“Se il flusso d’accesso ai dati seguirai, l’embedding non sbaglierai”

Vi starete chiedendo cos’è il flusso d’accesso ai dati, in realtà l’abbiamo già usato senza saperlo.

Immaginiamo di dover caricare la pagina in cui viene mostrato un singolo post, ci servono le sue informazioni quindi: titolo, testo, e autore, di solito alla fine dell’articolo troviamo anche i commenti quindi li mostriamo e ovviamente mostriamo anche i tags o categorie dell’articolo.

Proviamo ad individuare il flusso di accesso ai dati, come prima cosa ci servono i dati del post, poi la lista dei commenti ed infine i tag.

Tener conto del flusso d’accesso ai dati quando si struttura un database assicura delle ottime performance.

Quindi possiamo dire che, quando accediamo ai dati di un Post solitamente dobbiamo accedere nello stesso momento sia ai commenti sia ai tags. Quando si verifica questa situazione ha senso fare l’embedding perché fa tutto parte dello stesso flusso d’accesso.

Un’altra cosa molto importante da considerare è il limite di 16 MB su ogni documento. Non possiamo mai superare questa soglia, ovviamente non parliamo di sorgenti di immagini o simili che possiamo salvare con una diversa configurazione ma parliamo di normali documenti come tutti quelli che abbiamo visto sinora.

Se pensate di superare questo limite, magari a causa dei commenti, non potete usare l’embedding ma dovete appoggiarvi ad una collection separata.

Non spaventatevi, per siti normali non c’è nessun pericolo, si parla di casi estremamente rari.

In breve, ricordiamoci sempre di seguire il flusso d’accesso ai dati e del limite di 16 MB per documento.

Come vi sembra? Dubbi?

Vi avevo detto che avremo visto come migliorare la struttura degli articoli, soprattutto la parte dei commenti, per rendere tutto più performante. Adesso vedremo come.

Questi esempi fighissimi li ho presi dalla seconda puntata del Webinar tenuto da Massimo Brignoli, Senior Solution Architect MongoDB, il video è su youtube ma inspiegabilmente ha appena 300 visualizzazioni eppure è in italiano e lui è bravissimo; vi lascio il link https://youtu.be/r0em6qZmYhM perché sicuramente spiega meglio del sottoscritto.

Allora una proposta noi l’abbiamo già vista e ne abbiamo già parlato: prevede di incapsulare i commenti nel documento dell’articolo quindi abbiamo il vantaggio di ottenere tutti i dati con una sola query ma allo stesso tempo l’array che contiene i commenti non ha limiti, quindi potrebbe crescere in qualsiasi momento e superare i 16 MB.

Modellazione dei commenti: reference

Questo è più banale, abbiamo sempre il nostro array per i commenti ma dentro salviamo una semplice referenza quindi un l’ID di ogni singolo commento, che invece andremo a salvare in una collection separata.

questo modo sicuramente non c’è il rischio di sforare i 16 MB ma

perdiamo in termini di performance perché dobbiamo eseguire una query

per il singolo articolo, ottenere la lista di tutti gli id dei commenti e

solo a questo punto richiedere i commenti eseguendo una query per

ognuno, insomma non è per niente ottimizzato quindi meglio andare

avanti.

Modellazione dei Commenti: approccio ibrido
Collection dei Posts

Nel webinar viene proposto un approccio ibrido molto figo e super interessante: teniamo i commenti incapsulati ma li teniamo in un array a dimensione fissa, quindi incapsuliamo solo gli ultimi 20 commenti inseriti; quando andremo a fare la query per avere i dati dell’articolo possiamo già mostrare gli ultimi 20 commenti senza eseguire altre query ed essendo quello dei commenti un array a dimensione fissa non rischiamo di sforare il limite.

Per avere un array con dimensione fissa possiamo usare un particolare operatore durante l’inserimento del nuovo commento cosicché Mongo tagli gli elementi in eccesso.

Così facendo abbiamo solo gli ultimi 20 commenti a disposizione, tutti gli altri invece vengono divisi in gruppi e messi in una collection separata.

Dato che qui abbiamo solo gli ultimi 20 commenti e gli altri sono separati è consigliabile aggiungere nella nostra app un piccolo codice per il conteggio nell’inserimento e nella rimozione dei commenti stessi, così da non dover rifare ad ogni refresh gli stessi conti.

Quindi teniamo il conto del numero totale di tutti i commenti ma non solo, andiamo oltre e teniamo il conto anche del numero totale delle pagine dei commenti.

Ovviamente non li mostreremo tutti in una sola pagina, faremo una paginazione magari in gruppi di 40 come fa youtube.

Nell’articolo abbiamo 20 commenti che mostriamo subito nella pagina, se l’utente però fosse un gran curiosone e ne volesse di più allora andrebbe alla pagina successiva e solo a questo punto effettueremo la query per chiederne altri 40.

Questa è la nostra collection per i commenti, li salviamo in gruppi quindi in differenti documenti dove ognuno ne raggruppa 40, avremo: un riferimento all’id dell’articolo, il numero della pagina di cui fanno parte e quanti commenti effettivamente contiene la pagina (sarà un intervallo tra 1 e 40).

Abbiamo costruito la struttura seguendo il flusso dei dati, abbiamo l’articolo velocissimo in lettura già con 20 commenti inclusi e abbiamo le singole pagine per i gruppi di commenti pronte ad essere visualizzate.

Praticamente rendiamo leggermente più complicata la scrittura, aggiungendo i contatori e dividendo i commenti già in gruppi, ma allo stesso tempo ottimizziamo drasticamente le performance in lettura che è poi l’operazione più frequente.

Non posso far altro che ringraziare immensamente Massimo Brignoli per i suoi webinar perché queste soluzioni di ottimizzazione non vengono proposte nei corsi dell’university di Mongo quindi senza i suoi insegnamenti io stesso sarei arrivato molto ma moooolto lentamente a trovare certe soluzioni, quindi grazie mille Massimo e visto che ci sono… e mettile le ultime 4 puntate del webinar che le stiamo tutti aspettando.