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

Il primo corso di MongoDB gratuito in italiano! Vedremo le basi, lo schema dinamico e shema design ed infine il CRUD.
4.5 (86 ratings)
Instead of using a simple lifetime average, Udemy calculates a
course's star rating by considering a number of different factors
such as the number of ratings, the age of ratings, and the
likelihood of fraudulent ratings.
756 students enrolled
Instructed by Alberto Olla Development / Databases
Free
Start Learning Now
  • Lectures 23
  • Length 2 hours
  • Skill Level Beginner Level
  • Languages Italian
  • Includes Lifetime access
    30 day money back guarantee!
    Available on iOS and Android
    Certificate of Completion
Wishlisted Wishlist

How taking a course works

Discover

Find online courses made by experts from around the world.

Learn

Take your courses with you and learn anywhere, anytime.

Master

Learn and practice real-world skills and achieve your goals.

About This Course

Published 1/2016 Italian

Course Description

Ciao, io sono Alberto Olla per Mongodb Italia, benvenuto o benvenuta nel primo corso online in italiano completamente gratuito per imparare mongodb!

Ah la prima cosa che bisogna sapere è che il suo nome tecnicamente è mongodb ma per gli amici basta mongo.

Ha delle similitudini con i database relazionali quindi è l’ideale se vi state avvicinando al mondo nosql per la prima volta e non fatevi ingannare dal fatto che sia un databsae giovane perchè è molto performante, facilmente scalabile, ma sopratutto facile da usare ed è molto apprezzato anche dai più esperti, non per nulla è utilizzato da grandi aziende come Ebay, Expedia e anche il new york times!

Penso però, che la vera bellezza di mongo non stia nel fatto che è performante e quant’altro ma invece nel fatto che aiuti a vedere le cose in maniera diversa, a pensare in modo più creativo

Premetto che non mi reputo un esperto o un guru e non sono stato pagato da nessuno per fare questi video, sono semplicemente un appassionato, ho completato con successo 3 corsi nell’university online di mongodb e volevo condividere con voi le cose che ho imparato.

Non aspettatevi un corso formale tra insegnante e studente, è più una sorta di chiacchierata tra amici quindi non mancheranno considerazioni personali e un pizzico di ironia.

Uno dei motivi che mi ha spinto a realizzare questo corso è la possibilità di far conoscere e apprezzare mongo a più persone possibili sopratutto a chi ha difficoltà nell’inglese dal momento che la totalità dei corsi presenti sull’internet è in inglese e in italiano non esiste praticamente nulla, neanche un vero libro.

Qui sotto troverai un bel pò di video che rappresentano tutto il percorso da fare per conoscere mongo. Ti consiglio di seguirli in ordine anche se alcuni potrebbero sembrare più interessanti di altri. Precisiamo che i video non sono di ottima qualità ma ho fatto del mio meglio per renderli il più professionale possibile.

Spero che questo vi aiuti ad apprezzare veramente mongo, e che vi faccia venire la voglia, la curiosità, di saperne di più e di seguire quindi i veri corsi direttamente sull’university online di mongodb.

Ci vediamo online ;)

What are the requirements?

  • Familiarità con Javascript è d'aiuto, ma non essenziale
  • Familiarità con database SQL o NoSQl è d'aiuto, ma non essenziale

What am I going to get from this course?

  • Capire le basi e la filosofia alla base di MongoDB
  • Sfruttare al meglio l'assenza di join con le Pre-Join
  • Convertire un database da Relazionale ai Documenti
  • Imparare i concetti di schema design per creare i propri database su MongoDB
  • Imprare i diversi tipi di query e operatori
  • Conosce il CRUD (Create Read Update Delete)

What is the target audience?

  • Questo è un corso base pensato appositamente per chi vorrebbe fare i suoi primi passi, partendo proprio da zero, su un database nosql, come mongodb, che è tuttora il database no-sql più popolare del mercato.

What you get with this course?

Not for you? No problem.
30 day money back guarantee.

Forever yours.
Lifetime access.

Learn on the go.
Desktop, iOS and Android.

Get rewarded.
Certificate of completion.

Curriculum

Section 1: Capitolo 1: Introduzione e Basi
07:33

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.

06:42

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.

Un nuovo approccio

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.

Pre-Join in pratica

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!

Una vera figata e l’abbiamo soltanto introdotto! Ci sarebbe da dire in quali casi è consigliabile utilizzarlo e soprattutto con quale criterio va applicato ma è meglio rimandare questi argomenti a delle lezioni successive.
07:02

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.


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.


MongoDB in un applicazione

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.


Riga di comando e Drivers

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!

12:01

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.

Abbiamo un interprete javascript quindi possiamo scrivere somme o cicli.

Prendiamo confidenza con la Shell

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 ;)

04:17

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.


JSON: tipi e sintassi

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.


Molto semplice. Sono sicuramente familiari a tutti i programmatori a prescindere da quale sia il vostro linguaggio. Adesso vediamo alcune cose sul JSON che probabilmente vi siete dimenticati.


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.


Pochi e semplici punti da ricordare, ve li siete segnati? Non vi ho visto prendere appunti… mhh.. adesso vediamo cos’è il famoso BSON.


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.

04:34

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.


I vantaggi di uno schema dinamico

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.

Insomma, siamo liberi di scegliere la soluzione migliore perché è il database che si adatta alle nostre esigenze.
06:24

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.

Adesso vediamo come risulta su Mongo.

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.

Lo vediamo nella prossima puntata :D
08:50

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.

Andiamo a vedere quindi quali sono queste proposte di ottimizzazione delle performance.

Modellazione dei commenti: incapsulamento

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.

Per ovviare a questo si potrebbe provare un altro approccio, proviamo con le reference.



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.

In

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.

Mi spiego, immaginiamo che il nostro articolo sia un vero successone, che abbia raggiunto i 10.000 commenti...anzi no è troppo, facciamo 85!

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.


Collection dei Comments

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.

Section 2: Capitolo 2: CRUD
01:43

Una piccola introduzione al capitolo che riguarderà il CRUD e gli Operatori!

CRUD e Operatori

Quindi tutto quello che bisogna sapere per poter creare, leggere, modificare ed eliminare documenti all'interno delle nostre collections.

Come abbiamo già visto MongoDB non utilizza una sintassi o linguaggio SQL, ma per effettuare le query ci mette a disposizione differenti metodi. CRUD è l'acronimo di Create, Read, Update e Delete che su Mongo "traduciamo" con le seguenti funzioni: create diventa Insert, read diventa Find, update rimane ugualmente Update ed infine delete diventa Remove. Possiamo notare delle similitudini con l'SQL in quanto Insert e Update sono comuni, mentre Find equivale ad una Select e Remove a Delete, anche se cambiano i nomi dei metodi il concetto rimane sempre lo stesso.


In questo capitolo vederemo anche gli operatori, come ad esempio OR e AND, ma MongoDB ci offre una vastissima gamma. La cosa più importante che dobbiamo ricordarci è che tutti gli operatori su Mongo devono sempre essere preceduti dal simbolo del $ dollaro.

MongoDB ci mette a disposizione: $gt, $lt, $or, $and, $in, $nin, $type, $exists, $regex

Per query di update: $set, $unset, $inc

Per update su array: $push, $pop, $pull, $pushAll, $pullAll, $addToSet

Non preoccupatevi approfondiremo ogni operatore nelle successive lezioni di questo capitolo. Ho cercato di creare questi video il più settoriali e isolati possibile in modo tale che se un domani vi doveste dimenticare, ad esempio, come si effettua un update su Mongo potete andare a guardare direttamente e soltanto la lezione la specifica lezione sugli update, con minimi rimandi alle lezioni precedenti.

Bene, c'è molto da imparare quindi cominciamo subito!
03:07

Ecco come inserire nuovi documenti su MongoDB con il metodo insert.

Lezione su Insert

L’insert, come nei database relazionali, è usata per l’inserimento di un nuovo dato, nel nostro caso l’inserimento di un documento JSON. Vediamo di fare qualche prova e di prendere confidenza con la shell.

Creiamo un documento in javascript:

var doc = { name:”Alberto”, surname:”Olla”, city:”Cagliari” }

> doc

il comando

> db

ci mostra il database in cui siamo. Abbiamo detto che i documenti vivono all’interno delle collection situate in un particolare database.

Per inserire il documento nel database possiamo scrivere:

db.users.insert( doc )

vedete come collection sia una proprietà del database, mentre insert è un metodo della collection che riceve come argomento un oggetto javascript come il nostro doc.

db.users.find()

ci mostra tutti i documenti della collezione perchè, come potete vedere, è stata richiamata senza parametri. Nel nostro specifico caso verrà restituito un solo documento perchè non ne sono stati inseriti altri.


Possiamo notare che Mongo ha aggiunto un nuovo attributo _id di tipo ObjectID. Questo è un attributo obbligatorio che tutti i documenti devono avere e serve per identificare il documento, una sorta di chiave primaria.

La cosa più importante di _id è che è unico ed immutabile, unico perchè non possono esistere due documenti nella stessa collection con la stessa chiave e immutabile perchè non può mai essere modificata, ovviamente si può simulare la modifica eliminando il documento e ricreandolo impostando un diverso _id.

L’ObjectID viene generato automaticamente unendo tra loro alcuni dati, tra cui il tempo, l’identificativo della macchina, il processID che sta gestendo l’operazione, un contatore dei processi e altri dati simili, con l’obiettivo di creare in tempi rapidissimi un _id che abbia il maggior numero di probabilità di essere unico.

In questo modo possiamo inserire documenti senza specificare l’_id, senza nessun pericolo di collisioni.

Possiamo anche specificare noi l’id durante l’inserimento, usando stringhe o numeri, basti che sia unico per ogni documento della collection.

05:07

Tutto su come cercare i documenti: Find, FindOne, condizioni di ricerca e Field selection per escludere alcuni attributi dalla visualizzazione.

Lezione su FindOne

L’operazione basica dei database è la ricerca. Per ricercare un singolo documento si usa la findOne. Questa può essere richiamata senza argomenti per ricevere un documento random della collection, in questo modo:

>db.users.findOne()

Vi chiederete a che serve, beh diciamo che può essere utile per dare un’occhiata alla struttura dei documenti nelle collection molto grandi.


La findOne può essere invocata anche con un argomento che viene usato per fare un match con i documenti, diciamo che funziona come il WHERE nelle query SQL, quindi è una condizione. Vediamo un esempio:

>db.users.findOne( { name:”Alberto” } )

in questo caso viene restituito il primo documento che soddisfa il criterio di ricerca, ovvero la chiave nome deve avere il valore Alberto.

Adesso vediamo la funzione find che nonostante abbia delle similitudini con la findOne ci mostra più risultati.

Prima di tutto predisponiamo una collection per tutte le nostre prove, ci serve una collection bella grande cosi da fare vari test. Scriviamo:


for ( var i=0; i<1000; i++ ) { names = ["esame","prova","quiz"]; for(var j=0;j<3;j++){ db.scores.insert( { student: i, type: names[j], score: Math.round( Math.random()*100 ) } ); } }

Se volete copiare il codice lo trovate sotto il video nella pagina della lezione sul sito mongodbitalia.it.


Spieghiamo cosa fa questo codice perchè non essendo indentato si ben capisce poco, essenzialmente popola una nuova collection con dei punteggi di varie prove o esami per 1000 studenti.

Più precisamente abbiamo un primo ciclo che viene eseguito 1000 volte, per tutti gli studenti, all’interno di questo abbiamo un secondo ciclo che viene eseguito solo 3 volte, l’indice di questo secondo ciclo viene utilizzato per scegliere il tipo di prova/esame. Quindi per ogni ciclo viene salvato il numero dello studente, che corrisponde all’indice del primo ciclo, il tipo di prova e un numero casuale che rappresenta il voto.

Proviamo a visualizzare la nostra collection:

> db.scores.find()


Dal momento che abbiamo molti documenti non può di certo restituirci tutto assieme, e figuriamoci che adesso ne abbiamo solo 3000; ma immaginate se ce ne fossero stati 10.000 o 100.000 e pure più elaborati dei nostri, avremmo avuto sicuramente un picco di carico. Per evitare questo problema ci viene limitata automaticamente la query.

Per scorrere e visualizzare i risultati successivi possiamo scrivere IT, in questo modo il cursore andrà avanti.

Però così facendo i risultati sono poco leggibili, per avere una visualizzazione più pulita meglio scrivere:

> db.scores.find().pretty()

Field Selection: selezione attributi da visualizzare

Come abbiamo visto per findOne, anche nella funzione find possiamo specificare delle condizioni:

> db.scores.find( { type:”prova” } )

oppure:

> db.scores.find( { student:19 } )

Volendo possiamo anche combinare più condizioni insieme concatenandole con la virgola:

>db.scores.find( { type:”prova”, student:19 } )


In questo caso la virgola funge da AND perchè il documento deve soddisfare entrambe le richieste nello stesso momento.


Possiamo anche specificare il secondo argomento che serve per dichiarare esplicitamente quali attributi deve restituirci la query


>db.scores.find( { type:”prova”, student:19 }, { score:true } )



Di default ci verrà restituito anche l’_id in quanto attributo speciale, se non lo vogliamo dobbiamo specificarlo.

03:49

Vediamo finalmente i nostri primi operatori, $gt e $lt, come si applicato e le loro potenzialità.

Lezione sugli operatori $gt e $lt

Solitamente su Mongo gli operatori hanno tutti la stessa struttura, ad eccezione di AND e OR che vedremo più avanti, una volta capita la logica applicare gli operatori ci verrà naturale. $gt e $lt sono i primi operatori che vediamo.

Non sono due strane sigle, gt vuol dire greater than, ovvero maggiore di, mentre lt vuol dire lower than quindi meno di, vediamoli nella pratica:

> db.scores.find( { score: { $gt:95 } } )


Specifichiamo prima l’attributo al quale voler applicare l’operatore, poi apriamo un sottodocumento in cui inseriamo l’operatore come coppia chiave-valore. In questo caso cercherà tutti i documenti che hanno un punteggio maggiore di 95.

Possiamo anche aggiungere anche altre condizioni, ad esempio vogliamo vedere solo le prove, quindi scriviamo:

> db.scores.find( { score: { $gt:95 }, type:”prova” } )

L’operatore $lt funziona in modo analogo, solo che restituirà i documenti con un punteggio minore del valore specificato.

Proviamo

invece a considerare un intervallo, ad esempio tutte le prove maggiori

di 95 e minori di 98. Dobbiamo usare entrambi gli operatori sullo stesso

attributo “score” quindi possiamo semplicemente aggiungere $lt nel

sottodocumento in cui è presente l’operatore $gt, in questo modo:

> db.scores.find( { score: { $gt:95, $lt:98 }, type:”prova” } )


Gli operatori semplici $gt e $lt non considerano gli estremi dell’intervallo, se vogliamo gli estremi inclusi ci basterà aggiungere la e di equal, uguale, quindi $gte e $lte.


Abbiamo visto come utilizzare gli operatori con i numeri, e con le stringhe si può fare? in realtà si anche se non è proprio raccomandato, facciamo qualche prova nella collection users. Prima però aggiungiamo qualche utente che ci servirà per le prove. Ora che li abbiamo aggiunti proviamo a fare una ricerca:

>db.users.find( { name: { $lt: “D” } } )

>db.users.find( { name: { $lt: “D”, $gt: “B” } } )

Notate qualcosa di strano? Qualcosa di insolito?
Magari a qualcuno potrebbe sembrare strano che visualizzi Bob dato che abbiamo scritto $gt e non $gte, giusto?

Adesso vi spiego il perchè, quando usiamo gli operatori su delle stringhe Mongo utilizza l’ordinamento in base alla rappresentazione dei byte dell’UTF-8. Quindi ci visualizza anche Bob perchè Bob è a tutti gli effetti considerato maggiore della lettera B. Se al posto di B scrivessimo Bob vedreste che viene escluso, a meno che non inseriate anche l’uguale nell’operatore gt, ma questa prova la lascio fare a voi così fate pratica.


MongoDB ha uno schema dinamico quindi possiamo aggiungere nell’attributo name, che attualmente contiene solo stringhe, anche dei numeri ad esempio:

>db.users.insert( { name: 20 } )


Possiamo comunque effettuare le nostre query senza intralci, dato che quando usiamo $gt ed $lt precisiamo la lettera iniziale come stringa.

04:47

Alcuni operatori utili sono sicuramente $exists,

$type ed infine $regex per le espressioni regolari, impariamo ad usarli

con qualche esempio.

Lezione su $exists e $type

Nell’altra lezione abbiamo visto $gt ed $lt e se avete capito come applicarli non avrete nessuna difficoltà neanche con quelli che vedremo oggi: $exists, $type e $regex.

Lanciamo:

>db.users.find()

Come possiamo vedere all’interno di questa collection abbiamo strutture differenti quindi vogliamo selezionare solo i documenti che hanno una città, per farlo ci serve l’operatore $exists che ci permette di verificare l’esistenza di un attributo all’interno dei documenti. Vediamo come usarlo:

> db.users.find( { city:{ $exists:true } } )

Come per $gt e $lt specifichiamo la chiave sul quale vogliamo applicare l’operatore, apriamo un sottodocumento e inseriamo quindi l’operatore come coppia chiave-valore.

Possiamo anche scrivere l’inverso, quindi tutti i documenti che non hanno una città:

> db.users.find( { city:{ $exists: false } } )

Con l’operatore $type invece possiamo chiedere se un attributo sia di un tipo specifico, questo lo userete di rado ma vediamo come funziona:

> db.users.find( { name:{ $type: 2 } } )

I tipi, dobbiamo scriverli come numero in base alle specifiche BSON, infatti nel BSON le stringhe hanno il valore 2, possiamo vedere la lista di tutti i tipi supportati sul sito bsonspec.org, sotto la voce specifiche.

Lezione su $regex

Ora passiamo al pezzo forte: la $regex, usata per le espressioni regolari. Diciamo che Mongo ci offre strumenti di query migliori di questo ma per adesso è il più potente che vedremo.

Per chi non conosce le espressioni regolari diciamo che permettono di effettuare controlli in base a regole o modelli sulle stringhe, cioè possiamo cercare tutte le stringhe che iniziano con una determinata lettera oppure che finiscono con un’altra e volendo possiamo creare regole complesse ed elaborate.

Non posso soffermarmi a parlare a lungo delle espressioni regolari perchè ci sarebbe veramente troppo da dire, e non sono neanche così esperto a dirla tutta. In questo corso vedremo come si usano su Mongo con qualche esempio che possa essere utile a tutti. Iniziamo:

> db.users.find( { name:{ $regex: “a” } } )

Con questo comando abbiamo chiesto di cercare tutti i nomi che contengono una a minuscola, attenzione non maiuscola ma solo minuscola.

Questo è un utilizzo banale delle espressioni regolari proviamo a sfruttarle meglio:

> db.users.find( { name:{ $regex: “e$” } } )

Attenzione il dollaro all’interno delle virgolette fa parte della simbologia delle espressioni regolari e indica la fine della stringa. Quindi in questo caso ci verranno restituiti tutti i documenti con nomi che finiscono con la lettera minuscola e.

$regex è sicuramente un operatore molto potente ma il suo utilizzo non è consigliato.

Attenzione, non voglio sminuire in nessun modo questa funzione ma le performance sono molto influenzate dalla complessità del pattern e dalla struttura dei dati, quindi se non da le certezze che servono in un sistema scalabile è preferibile non utilizzarlo.

Ovviamente Mongo ha tante risorse e ci offre ottime soluzioni per effettuare ricerche su testi in maniera molto performante, possiamo usare: gli indici appositi, detti Text Index, e l’operatore $text, purtroppo noi non vedremo nessuno dei due in quanto argomenti avanzati, mi dispiace...

Per il momento accontentiamoci di $regex che dovrebbe andar bene per il 90% dei normali database.

L’unica espressione regolare performante è questa:

> db.users.find( { name:{ $regex: “^A” } } )

il simbolo ^ nell’espressione regolare ci permette di ottenere tutti i documenti che iniziano con una determinata lettera. In realtà la query è considerata performante perchè viene convertita meccanicamente in un range, nel caso dell’esempio va da A a B con B esclusa.

Beh abbiamo visto un sacco di cose nuove: $exists per verificare se un attributo esiste o meno, $type (che non userete quasi mai) per verificare se un attributo è di un tipo specifico e poi $regex per le espressioni regolari o pattern matching, tante belle cose :) divertitevi!

02:29

Impariamo ad usare correttamente gli operatori di $or e $and per combinare più condizioni in un unica query.

Lezione su $or

In questa lezione parleremo degli operatori AND e OR che servono per combinare più condizioni tra loro, per creare query più complesse.

Fino ad ora abbiamo visto gli operatori usati come sottodocumento del nostro attributo, mentre questi due sono gli unici che si utilizzano in maniera diversa, vediamo come, partiamo dall’OR:

>db.users.find( { $or:[ { COND1 }, { COND2 } ] } )

La prima cosa che dobbiamo specificare nel nostro documento è l’operatore che sarà un array contenente le varie condizioni da combinare. Ad esempio:

>db.users.find( { $or:[ { name:{ $regex:”a$” } }, { city:{ $exists:false } } ] } )


in questo caso ci sono due condizioni separate che vengono unite dalla clausola OR, per ottenere un risultato basta che solamente una delle due sia soddisfatta.

Scrivendo query elaborate potremo avere problemi a districarci con le parentesi, fortunatamente la shell stessa ci viene in aiuto. Infatti, se ci spostiamo con il cursore su un simbolo di gruppo, come la parentesi tonda, quadra o graffa, possiamo vedere che la sua corrispondente viene illuminata di blu.

Se dovessimo dimenticarci di chiuderne qualcuna la shell ci avviserà scrivendo tre punti …

È il suo modo per dirci che il documento non è concluso, per andare avanti ci basterà cliccare invio.

Lezione su $and

Passiamo all’operatore $and, la struttura è del tutto simile a quella dell’$or, vediamo:

>db.users.find( { $and:[ { name:{ $gt:”C” } }, { city:{ $exists:false } } ] } )

Funziona ma equivale semplicemente a scrivere:

>db.users.find( { { name:{ $gt:”C” } , city:{ $exists:false } } )


Di norma si consiglia l’utilizzo della seconda struttura in quanto risulta più performante dal momento che con l’operatore $and le condizioni vengono valutate separatamente l’una dall’altra.

01:52

Vediamo come interagire con gli array quando dobbiamo effettuare delle ricerche.

Ricerca su array

Sino ad ora abbiamo utilizzato documenti con strutture abbastanza semplici; proviamo qualcosa di leggermente più complicato, come ad esempio ad interagire con gli array.


Creiamo due articoli con diversi tags, per poter fare qualche prova di ricerca in entrambi inseriamo un tag comune che nel nostro sarà “query”.

Se l’attributo tags fosse stato una semplice stringa per cercarlo avremo potuto scrivere:

> db.articles.find( { tags:”array” } )

però noi sappiamo che è un array, ma come avvertiamo Mongo? In realtà non serve, perchè è furbo e lo capisce da solo.

Anche le query si adattano al polimorfismo quindi, lanciando questa ricerca, Mongo analizzerà come al solito tutti i documenti: se troverà l’attributo tags come stringa verificherà se è uguale a quella cercata, se invece l’attributo da analizzare sarà un array controllerà tutti gli elementi dell’array per cercare una corrispondenza con la stringa, nel nostro caso la stringa “array”.

Proviamo.

Usiamo anche un altro tag.


Questo è un comportamento normalissimo per Mongo in quando è pensato per avere uno schema dinamico. La ricerca,però, non è ricorsiva e si ferma al primo livello di profondità dell’array, cioè se noi avessimo più array uno dentro l’altro Mongo effettuerebbe la ricerca solo nel primo livello.


Precisiamo che Mongo non offre nessun operatore per la ricerca ricorsiva oltre il primo livello di profondità e personalmente mi sembra del tutto logico per questioni legate alle performance.


Essendo una query completamente normale possiamo combinare anche altre condizioni, senza alcun tipo di problemi.
01:59

Restiamo sempre in tema di array e vediamo invece come utilizzarle nella ricerca con gli operatori $all, $in e $nin.

Lezione su $all, $in e $nin

In questa lezione parleremo degli operatori $all e $in che hanno la caratteristica di ricevere in ingresso, non un semplice valore come gli altri operatori che abbiamo visto sinora ma bensì, degli array.

Aggiungiamo qualche altro articolo per avere varie combinazioni di tag.


Immaginiamo di voler cercare tutti i documenti che hanno sia il tag “mongodb” sia “array”, per farlo possiamo usare l’operatore $all in questo modo:

> db.articles.find( { tags: { $all : [ “mongodb”,”array” ] } } )

Precisiamo che noi gli abbiamo scritti senza pensare all’ordine ed infatti neanche Mongo lo tiene in considerazione.


Infatti, guardando i risultati possiamo notare che i documenti trovati possono avere anche altri tag oltre quelli cercati ma l’importante è che quelli specificati nella query siano presenti, anche se con ordine inverso.

L’altro operatore che vedremo oggi è $in, qualcuno di voi potrebbe conoscerlo perchè nell’SQL ce n’è uno simile, beh questo ci permette di specificare una lista di valori, esattamente come $all ma con la differenza che basta semplicemente che sia presente anche un solo degli elementi ricercati, vediamolo:

> db.articles.find( { tags: { $in : [ “mongodb”,”query” ] } } )

Ci mostra tutti i documenti che contengono il tag mongodb oppure query o anche entrambi, l’importante è che almeno uno dei due sia presente.

L’operatore $in possiamo utilizzarlo anche con le stringhe dato che si adatta ai tipi di dato, ad esempio:

> db.articles.find( { title: { $in : [ “primo”,”secondo” ] } } )


Ah,quasi dimenticavo...c’è anche l’operatore $nin ovvero la negazione di $in, ma questo ve lo lascio scoprire da soli, fate qualche prova!
02:31

Come comportarsi quando vogliamo ricercare all'interno di un sottodocumento? In questa lezione

Ricerca su sottodocumenti

Nelle precedenti lezioni abbiamo visto come effettuare query con gli array, le stringhe e i numeri, quindi per esclusione ci rimangono solo i sottodocumenti, vediamo come usarli.


Innanzitutto creiamo una collection di contatti apposita per i nostri test, dove salviamo qualche contatto socials tipo nick ed email di twitter.

Bene, se ora volessimo interagire con il sottodocumento che contiene twitter (ossia il nick) ed email come facciamo?

Andiamo per grandi, proviamo a fare la cosa più banale che ci viene in mente, io personalmente scriverei questo:

> db.contacts.find( { socials: { twitter : "yourAlbertoOlla",email : "info@mongodbitalia.it" } } )

Cerchiamo l’attributo socials e riscriviamo esattamente il sottodocumento preciso identico, proviamo a cercare.

Funziona! Ottimo, ma il fatto di averlo dovuto riscrivere precisamente identico fa venire qualche dubbio… proviamo ad invertire l’ordine di twitter ed email senza usare nessun operatore.

In effetti non trova nulla, questo perchè effettua un confronto byte per byte con il BSON del documento ed essendo un ordine diverso anche i byte sono diversi pertanto non trova nulla.

Possiamo provare a scrivere:

> db.contacts.find( { socials: { twitter : "yourAlbertoOlla" } } )

Però anche questo non va bene, perchè in realtà cerca tutti i documenti il cui attributo socials è un sottodocumento che contiene twitter"yourAlbertoOlla", nulla di più e nulla di meno.

Ma allora come facciamo ad accedere agli attributi di un sottodocumento?

Beh, Mongo ci mette a disposizione una sintassi speciale ed è il punto .

In effetti ripensandoci potevo anche arrivarci da solo, d’altronde stiamo parlando di documenti chiamati anche oggetti quindi non è strano dover usare il punto.

Vediamo come usarlo.

> db.contacts.find( { socials.twitter : "yourAlbertoOlla" } )


Scrivendo questo Mongo cercherà in tutti i documenti l’attributo socials, vedrà se è un sottodocumento e se contiene l’attributo twitter, solo in caso positivo farà un controllo tra le stringhe.


Come sempre possiamo anche combinarlo con altre condizioni.
03:58

MongoDB ha alcuni similitudini con l'SQL come il Limiti, il Sort, lo Skip ed il Count, vediamo come utilizzarli ma prima parliamo del Cursore.

L'oggetto Cursore con Limit,Sort e Skip

Abbiamo visto come effettuare inserimenti, interrogazioni e ricerche di diverso tipo ma vorrei soffermarmi un attimo per spiegarvi cosa succede dietro le quinte quando noi lanciamo una query, parliamo quindi del cursore.

Quando noi lanciamo il comando find:

> db.contacts.find()

viene costruito un oggetto di tipo cursore che contatta il database ed immagazzina la risposta, immaginiamocela come una lista di documenti, la shell è impostata per iterare il coursore e quindi mostrare tutti gli elementi.

Volendo possiamo scorrere il cursore manualmente, scrivendo:

> var cur = db.contacts.find(); null;

dobbiamo aggiungere null alla fine della riga perchè altrimenti la shell lancerebbe la query e ci rovinerebbe i piani.

La variabile cur è un oggetto di tipo cursore che ovviamente ha i suoi metodi, comunemente abbiamo hasNext e next. HasNext verifica se è presente l’elemento successivo alla posizione del cursore e nel caso restituisce true, altrimenti false, in questo modo:

> cur.hasNext()

La next funziona in modo analogo ma restituisce l’elemento successivo spostando il cursore.

Questi due metodi sono molto utili nella programmazione per creare soluzioni personalizzate.

Possiamo anche scrivere un ciclo per scorrere completamente il nostro cursore, ottenendo lo stesso risultato della shell:

> while( cur.hasNext() ) printjson( cur.next() );

Vediamo qualche altra funzionalità del cursore, ridichiariamo la variabile cur:

> var cur = db.contacts.find(); null;

Possiamo utilizzare il metodo limit per limitare i risultati del cursore, un po’ come nelle select dell’ SQL:

> cur.limit(5); null;

Se rieseguiamo il ciclo possiamo vedere come i risultati siano limitati a 5.

Con quest’azione abbiamo modificato il cursore anche se in realtà non è stato inviato ancora nessun dato al server, quindi l’oggetto cursore per il momento è solo nella nostra shell.

Non c’è solo limit ma anche skip e sort. Ripristiniamo la variabile cur e proviamo:

> var cur = db.contacts.find(); null;

Il sort è come l’order by delle select in SQL.

> cur.sort( { name: -1 } ); null;

Il sort ha bisogno di un sottodocumento dove inseriamo l’attributo con il quale vogliamo ordinare i risultati e il tipo di ordinamento, 1 è inteso come crescente mentre -1 come decrescente, ovviamente possiamo aggiungere anche altri attributi di ordinamento in ordine di priorità.

Skip invece è simile alla limit e permette di saltare N risultati.

> cur.skip( 2 ); null;

In questo modo i primi due documenti dei nostri risultati verranno saltati e non ci verranno restituiti.

Visto che sono tutti metodi del cursore possiamo anche combinarli assieme e scriverli in un unica riga ad esempio:

> cur.sort( { name: -1 } ).skip( 2 ).limit(5); null;


Una cosa importante da sapere riguarda l’ordine: Mongo non considera l’ordine con il quale noi li dichiariamo ma, quando deve applicarli, usa un suo ordine molto rigoroso che è:

sort,

limit e skip. Quindi noi possiamo dichiararli in qualsiasi posizione

dal momento che il cursore esiste solo lato client e il server lo riceve

solo quando è già stato dichiarato.Lezione su Count

Per rimanere in tema di similitudini con l’SQL, Mongo ci offre anche la funzione count che restituisce il numero di elementi corrispondenti alla condizione.

>db.scores.count( {} )

Ha le stesse proprietà del find, quindi possiamo inserire un documento vuoto per ottenere il totale di tutti i documenti nella collection oppure inserire delle condizioni per contare solo quelli che la soddisfano.
05:19

L' upload su MongoDB può essere utilizzato con vari approcci diversi, in questa lezione approfondiremo le prime due.

Primo Approccio: sostituzione completa

Finalmente siamo arrivati alla parte più importante ovvero l’update. Questa funzione su Mongo può essere usata con quattro diversi approcci, che spiegheremo nel dettaglio.

Possiamo fare: una sostituzione completa, un’aggiunta o modifica in un documento (una modifica se esiste, un’aggiunta se non esiste), un upsert e un update multiplo.

Partiamo dal primo approccio ovvero la sostituzione completa. Il metodo update riceve in ingresso 2 argomenti obbligatori e sono una condizione (come quelle usate nella find) e un nuovo documento:

>db.users.update( { name:”Bob” }, { name:”Bob”, city:”Roma” } )


In questo caso Mongo cercherà il primo documento che soddisfa la condizione e lo sostituirà completamente con il documento precisato nell’update, quindi se avessimo 100 attributi e ne volessimo modificare solo uno dovremmo riscriverli tutti.

L’unico attributo che rimane invariato sarà _id che essendo immutabile non può essere sovrascritto.


Diciamo che questa pratica è un po’ pericolosa, perchè se ci dimenticassimo di specificare qualche attributo nel documento durante l’update questi verrebbero persi per sempre.

Può essere utile nella programmazione dove di solito si cerca un elemento nel database, lo si modifica nell’app e poi lo si risalva nel database già modificato, ma così facendo non teniamo conto di modifiche concorrenti quindi a meno che non serva questo specifico approccio consiglio di non usarlo.

Secondo Approccio: operatori $set, $inc e $unset

Abbiamo appurato che il primo approccio della sostituzione completa può essere pericoloso in base al tipo di app. Vediamo allora il secondo approccio, quello della modifica di uno specifico attributo. Ad esempio se volessi modificare solo l’attributo city:

>db.users.update( { name:”Bob” }, { name:”Bob”, city:”Milano” } )


Questa non sarebbe sicuramente la soluzione migliore quindi Mongo ci introduce un nuovo operatore apposito per gli update ovvero $set:

>db.users.update( { name:”Bob” }, { $set: { city:”Milano”} } )

A differenza degli operatori di find dove bisognava specificare prima l’attributo e poi l’operatore come sottodocumento, nell’update dobbiamo fare il contrario ovvero prima indichiamo l’operatore e poi come sottodocumento gli attributi e i valori.


Questa query cerca un documento con nome Bob e modifica l’attributo city in Milano, se non trova l’attributo indovinate cosa fa...lo crea perchè tutto è pensato per adattarsi, quindi $set serve sia per aggiungere un nuovo attributo sia per modificarlo in caso già esista. Facciamo qualche prova, inseriamo un’età ad Enrico, ad esempio 24.


Se volessimo aggiornarla a 25 potremmo sempre fare un’update con l’operatore $set e sostituire un numero con un altro, è molto efficiente su Mongo ma questo presuppone che dobbiamo già conoscere la sua età prima di modificare il documento.

Ovviamente non è sempre così, infatti Mongo ci propone un altro operatore: $inc, che come suggerisce il nome serve per incrementare o decrementare a step.


Quindi se volessimo incrementare l’età di Enrico di un anno senza conoscere con precisione quanto anni ha ci basterebbe scrivere:

>db.users.update( { name:”Enrico” }, { $inc : { age:1 } } )

Con l’operatore $inc dobbiamo specificare lo step di incremento e dal momento che noi vogliamo incrementare di uno, scriviamo 1.


Come $set anche $inc è molto versatile infatti se provassimo ad usarlo in un documento che non ha l’attributo età come ad esempio Carlo, cosa pensate che accadrebbe?

>db.users.update( { name:”Carlo” }, { $inc : { age:1 } } )

Mongo lo creerebbe mettendo come valore lo step da incrementare...io ve l’avevo detto che è furbo.


Ovviamente la spiegazione di questo secondo approccio non sarebbe completa se non vi facessi vedere anche come eliminare un attributo specifico e quindi fare l’opposto dell’operatore $set che con molta fantasia hanno chiamo $unset:

>db.users.update( { name:”Carlo” }, { $unset: { age:1} } )


È simile ma si applica in maniera leggermente diversa, quando usiamo $unset non dobbiamo specificare il valore corretto dell’attributo da eliminare… ok pessimo esempio in questo caso sono uguali, ma in realtà l’1 di $unset è da considerarsi come un true, al posto di 1 avremo potuto scrivere true.

Quindi farà questo: cercherà un documento con nome uguale a Carlo, controllerà se esiste un attributo di nome age e a prescindere dal suo valore lo eliminerà, lasciando ovviamente invariati gli altri attributi del documento.


Ahh abbiamo visto tutto quello che serve per l’update… no non è vero manca ancora tutta la divertentissima parte degli array!
03:22

Approfondimento sull'update e gli array, useremo gli operatori $push, $pull, $pop, $pushAll, $pullAll, $addToSet

Tanti nuovi operatori

Mongo ci offre molti operatori appositi per modificare gli array, cerchiamo di vederli tutti.

Innanzitutto creiamo una collection apposita per l’impresa in cui usiamo valori numerici per rendere più facile la comprensione.

>db.arrays.insert( { _id: 0, a : [ 1, 2, 3, 4 ] } )

L’attributo a è di tipo array e come ben sapete, gli array, hanno un loro indice decimale interno. Ovviamente questo è presente anche su Mongo, quindi possiamo scrivere qualcosa come:

>db.arrays.update( { _id:0 }, { $set: { “a.2”: 5 } } )

Quindi abbiamo usato il punto come se avessimo voluto accedere ad un attributo di un sottodocumento e gli abbiamo settato un nuovo valore. L’indice interno degli array parte da 0, di conseguenza modificando l’elemento in posizione 2 in realtà modifichiamo il terzo.

Questo era solo il riscaldamento, adesso vediamo gli operatori specifici che ci mette a disposizione per la manipolazione.

Abbiamo $push che serve per inserire un nuovo elemento in coda, quindi estende l’array, tenendo conto dell’ordinamento:

>db.arrays.update( { _id:0 }, { $push: { a: 6 } } )

Se volessimo eliminare un elemento senza conoscere la sua posizione possiamo usare $pull:

>db.arrays.update( { _id:0 }, { $pull: { a: 5 } } )

In questo caso Mongo cerca il valore specificato in tutte le posizioni dell’array e se lo trova lo elimina. Se invece volessimo eliminare elementi in base alla loro posizione e non al loro valore, ad esempio eliminare i primi o ultimi elementi di un array, potremmo usare $pop:

>db.arrays.update( { _id:0 }, { $pop: { a: 1 } } )

A $pop dobbiamo passare il numero degli elementi da eliminare, in questo caso eliminerà il primo elemento presente nell’array qualsiasi esso sia, se invece inserissimo un valore negativo partirebbe dalla fine, ad esempio con -1 eliminerebbe l’ultimo elemento.

Abbiamo anche alcune variati come ad esempio $pushAll e $pullAll che ci permettono di fare la stessa cosa dell’operatore classico ma per liste di valori.

$pushAll si occuperà di aggiungere una lista di valori ad un array, in questo modo:

>db.arrays.update( { _id:0 }, { $pushAll: { a: [ 5, 6, 7, 8 ] } } )

Questo operatore non controlla se ci sono doppioni o simili, aggiunge semplicemente in coda la lista degli elementi passati.

$pullAll invece si occupa di eliminarli, quindi con:

>db.arrays.update( { _id:0 }, { $pullAll: { a: [ 7, 8 ] } } )

Possiamo eliminare i valori 7 e 8 dall’array a prescindere dalla posizione in cui si trovano.

Abbiamo anche un ultimo operatore particolare che serve per quelle liste dove non vogliamo che nessun valore sia ripetuto, quindi array senza duplicazioni, ed è chiamato $addToSet, aggiungi nel set.

Questo è l’unico operatore che si preoccupa della presenza del valore in un array prima di fare qualcosa.

>db.users.update( { _id:0 }, { $addToSet: { a: 7 } } )

Infatti, se il valore non è presente nell’array come in questo caso lo aggiunge come se fosse un $push mentre se il valore è già presente non fa assolutamente nulla.


Adesso abbiamo finalmente visto tutti gli operatori che offre Mongo per manipolare gli array e siamo in grado di usare quelli più adatti alle nostre esigenze.

03:47

Gli ultimi due approcci dell'update su MongoDB: upsert e multiupdate.

Lezione su Upsert

Finalmente dopo tanta fatica siamo arrivati al terzo approccio chiamato upsert, non spaventatevi non è nulla di strano. È da considerarsi un’opzione facoltativa della funzione update, che ci permette di modificare un elemento anche se questo non esiste o meglio prima lo crea in automatico e poi lo salva “modificato”. Basta parlare vediamo come funziona.

Nella nostra collection utenti abbiamo tante persone diverse, Alberto, Marta, Felice, 20 e altri come Carlo, se scriviamo:

>db.users.update( { name :”Carlo” }, { $set: { city:”Venezia” } } )

Abbiamo già visto come Mongo aggiunga senza problemi l’attributo City ma se volessimo aggiungerlo a Mario? Noi sappiamo bene che Mario non c’è nella collection, ma se non lo sapessimo cosa succederebbe? Proviamo insieme:

>db.users.update( { name :”Mario” }, { $set: { city:”Venezia” } } )

Niente ovviamente… dato che non viene trovato nessun documento con nome Mario!

Ok, allora siamo costretti ad aggiungerlo per poi modificarlo, per non fare due operazioni diverse Mongo ci propone un’opzione facoltativa di update chiamata upsert, da inserire come terzo argomento.

>db.users.update( { name :”Mario” }, { $set: { city:”Venezia” } }, { upsert:true } )

Come abbiamo visto in altre funzioni per passare delle opzioni ci basterà semplicemente aggiungere un nuovo documento alla fine, con in questo caso upsert: true.

In questo modo stiamo dicendo a Mongo: “se non dovessi trovare nessun documento che corrisponda alla condizione, aggiungilo e applica anche la modifica”.

Quindi il documento aggiunto avrà sia come nome Mario sia come città Venezia.


Ovviamente

Mongo ha potuto inserire gli attributi perchè abbiamo specificato un

valore concreto, diverso sarebbe stato se come condizione avessimo messo

ad esempio un intervallo con $gt e $lt, avrebbe comunque effettuato

l’upsert ma senza impostare il nome dato che non sarebbe stato un valore

concreto.Lezione su Multi-update

Ah finalmente il quarto e ultimo approccio dell’update: il multi-update.

Multi-update? Qualcuno rimarrà perplesso, si perchè non so se ve ne siete accorti ma gli update su Mongo vengono applicati ad un solo documento, come se avessero limit 1.

Fateci caso, tutti quelli che abbiamo visto sinora in realtà servivano per modificare uno specifico documento, se avessimo voluto applicare la modifica a più documenti avremmo dovuto aggiungere l’opzione { multi: true }.

Nel caso ci sia una condizione in cui rientrino più documenti lui modificherà il primo che gli capita sottomano fermandosi subito dopo.


Se volessimo applicare l’update a tutti i documenti che rientrassero nella condizione allora dovremo aggiungere l’opzione chiamata multi, quindi multi:true. Proviamo:

>db.users.update( { city:{ $exists:true } }, { $set: { city:”Roma” } }, { multi:true } )

Perfetto, ha modifiato tutti i documenti che avevano l’attributo città sovrascrivendolo con Roma.


Per applicare una modifica a tutti i documenti ci basterà semplicemente mettere come condizione un documento vuoto, in questo modo:

>db.users.update( { }, { $set: { city:”Roma” } }, { multi:true } )


In qualche driver vi potrà anche capitare di trovare l’update e il multi-update come due funzioni diverse, in realtà sapete che non è cosi.


Abbiamo finito quest’odissea :) adesso conosciamo tutti i 4 approcci con cui utilizzare il metodo update.
02:14

Ecco i due metodi che ci mette a disposizione MongoDB per eliminare sia documenti che collection: Remove e Drop.

Lezione su Remove e Drop

Ultima lezione velocissima per vedere come eliminare documenti e collection. Mongo ci da a disposizione due funzioni diverse remove e drop.

Remove è simile al find, infatti possiamo specificare delle condizioni per i documenti da eliminare, ad esempio:

>db.users.remove( {name: { $gt: “B” } } )

Ovviamente è già prediposto per eliminare più elementi quindi non ha limitazioni come l’update.

Per rimuove tutti gli elementi di una collection possiamo usare il remove con un documento vuoto.

>db.users.remove( {} )

Remove elimina un documento alla volta, con pochi documenti risulta velocissimo e non ci accorgiamo di nulla ma se avessimo una collection molto grande per eliminare tutti i documenti noteremo l’attesa.

Per eliminare in maniera più efficace intere collezioni si utilizza drop, che elimina proprio tutto in blocco, senza condizioni.

>db.users.drop()


La differenza tra drop e remove è che se dovessimo eliminare 10.000 documenti, la remove impiegherebbe qualche secondo perchè mentre elimina i documenti uno alla volta il database può ricevere comunque letture e scritture per quelli non ancora eliminati.

Chiariamo che non può mai capitare di leggere un documento mentre questo viene eliminato, e quindi di vederne solo un pezzo. Quando la lettura non può avvenire o il documento è stato eliminato o è in attesa di eliminazione.


Benissimo, ora conoscete tutti gli strumenti per le query base della shell di Mongo :) non vi resta che fare tanta pratica e applicarli ai vostri personali database.
Section 3: Capitolo 3: Congratulazioni!
01:04

Un salito per concludere un bellezza il corso!

Ciao! Non mi ripresento perché se sei arrivato sino a questo video vuol dire che hai già visto tutti gli altri quindi ci conosciamo, si è creato un certo rapporto.

hai finito tutti i video del capito uno e due, quindi conosci le basi, il CRUD e gli operatori da utilizzare e puoi già fare qualcosa con MongoDB avendo queste nozioni.

Ho cercato di creare questo corso per stimolarti ad andare oltre, ad andare a seguire i veri corsi offerti dall'university online di MongoDB, che sfortunatamente sono in inglese, per approfondire tutti quegli argomenti più avanzati quindi gli Index di ricerca, il Replica-set e lo Sharding, che risultano sicuramente gli argomenti un pò più complicati ma avendo delle buone basi come le tue non dovresti avere problemi.

Questo è semplicemente un video per salutarci! Sai dove trovarmi, qui su mongodbitalia.it, c'è il mio nick di twitter @YourAlbertoOlla, puoi cercarmi se vuoi e spero che ci vediamo prossimamente online da qualche parte.
Buona fortuna! (con MongoDB)

Students Who Viewed This Course Also Viewed

  • Loading
  • Loading
  • Loading

Instructor Biography

Alberto Olla, Premium Udemy Instructor

Ciao! Io sono Alberto Olla e mi occupo di programmazione da più di 8 anni :)

Qui su Udemy puoi trovare i miei migliori corsi creati con amore e passione, ecco cosa ho realizzato:

Il più recente è "Imparare a programmare: Corso Javascript", una serie di video lezioni per insegnare la programmazione, partendo dai concetti base sino ad arrivare a creare veri e propri mini-programmi funzionanti.

In molti corsi di programmazione online (e non) lo studente si limita a copiare il codice scritto dall'insegnante senza capire realmente cosa scrive, e finito il corso, quando si ritrova ad affrontare un problema nella vita reale non sa da dove cominciare...
Questo capita molto spesso e per evitare che capiti anche ai miei studenti ho pensato a due delle soluzioni più efficaci: tantissimi esercizi pratici e dare il giusto supporto.

Ho totalmente basato il corso su esercizi pratici che è lo studente a dover risolvere, è lui che deve scrivere i codici, ed è lui che esercizio dopo esercizio assimilerà e apprendere nuove competenze, solo in questo modo potrà realmente imparare a programmare.

L'altro punto in cui credo molto è dare un giusto supporto, anche dopo aver visto una lezione possono restare dei dubbi o delle curiosità, per questo ho creato una pagina Facebook apposita in cui tutti gli studenti possono porre le proprie domande :)
Questo non è l'unico strumento di supporto, ne ho inserito diversi anche all'interno del corso completo.

L'altro corso è "Corso MongoDB" decisamente più "avanzato".

È il primo e unico corso online in italiano che insegna ad utilizzare MongoDB, il database noSQL più utilizzato al mondo che purtroppo non non si è diffuso in Italia come negli altri paesi, credo che uno dei problemi principali sia il fatto che la maggior parte

dei corsi e delle risorse presenti in internet siano in lingua inglese.

Per questo motivo ho deciso di realizzare non solo un corso completamente gratuito su MongoDB ma anche la community italiana di MongoDB, per dare un punto di riferimento a tutte le persone interessate a questo database.

Se hai problemi o dubbi sulle lezioni non esitare a contattarmi.

Ci vediamo all'interno delle lezioni! ;-)


Ready to start learning?
Start Learning Now