Cos’è MongoDB, PRO e CONTRO

In questo breve articolo analizziamo le principali differenze tra MongoDB e MySQL ponendo l’attenzione sulle differenze tra le tecnologie a livello di organizzazione dei dati, replicabilità e scalabilità.

 

Cos’è MongoDB?

MongoDB è un DBMS (DataBase Management System) non relazionale che ha come principale struttura di contenimento i document al posto delle tabelle. I document utilizzati da MongoDB sono memorizzati in BSON (Binary JSON), una tipologia di rappresentazione di dati in formato JSON caratteristico per la sua capacità espansiva.

Questa tipologia di modello dei dati infatti permette la manipolazione di molteplici tipologie di dati in un solo documento, a differenza della sua controparte MySQL che ha bisogno di più tabelle e di stabilire relazioni tra di esse.

La caratteristica principale di MongoDB è lo schema-less ovvero non c’è bisogno di definire uno schema del DB utilizzando la coppia chiave-valore all’interno di ogni documento.

Un valore all’interno di MongoDB può assumere valori:

 

• Numerico o stringa
• Oggetto
• Sequenza

Un esempio pratico può essere:

 

{
    "nome": "Giovanni",
    "cognome": "Pace",
    "eta": 35,
    "hobby": ["Musica", "Droni", "Astronomia"],
    "documento": {
        "tipo": "Patente",
        "codice": "AB1234
    },
    "veicoli": [
        {
            "tipo": "Automobile",
            "targa": "AA111AA"
            "cilindrata": 1500
        },
        {
            "tipo": "Motocicletta",
            "targa": "BB222BB"
        }
    ]
}

Nel frammento di codice precedente possiamo vedere come nelle righe 2,3 e 4 il tipo di dato è semplice, sotto forma di stringa (caratterizzato dalle virgolette o quotes) o numerico.

Le cose si fanno interessanti quando introduciamo nella riga 5 una sequenza di stringhe, si tratta di un vero e proprio array come in JavaScript.

La necessità di immagazzinamento di un dato strutturato viene sopperita dalla possibilità di associare ad una chiave, un valore di tipologia oggetto (riga 6). Questa tipologia di approccio in MySQL può essere esplicitato solo introducendo una nuova tabella ed un JOIN a supporto della relazione.

A dimostrazione della eterogeneità dei contenitori Array di JavaScript, MongoDB nella riga 7 introduce la possibilità di utilizzare Array di oggetti eterogenei, infatti vediamo una sequenza di oggetti che possono non corrispondere esattamente ad una struttura precedentemente definita.

Vedremo più avanti che le potenzialità di questo approccio sono elevatissime ma tutta questa libertà potrebbe scontrarsi con il concetto di vincolo strutturale introdotto dalla maggior parte dei linguaggi di programmazione.

Ogni document in MongoDB è una struttura indipendente, ciò significa che potrebbe esserci una totale discrepanza tra le document dello stesso tipo, ad esempio caratterizzanti un’anagrafica.

Un raggruppamento di document in MongoDB è definita come collection, a livello concettuale equiparabile ad una tabella ma con colonne definite in modo arbitrario e solo se valorizzate.

 

Per cosa viene usato MongoDB?

L’utilizzo principale di MongoDB è destinato a soluzioni in cui la variabilità dello schema è elevata e soprattutto in quelle situazioni in cui sarebbe molto complicato creare una struttura a priori.

Utilizzato per il salvataggio di Big Data, l’equivalente di un record (un document) può avere dimensioni anche enormi (diversi GB) senza influire sulle caratteristiche di ricerca e manipolazione dati.

Mentre MySQL crea uno o più DataBase File per lo storage dei dati, in MongoDB ogni document è una unità indipendente che non degrada le prestazioni del DBMS.

L’utilizzo più comune è l’analisi di dati non omogenei (dati di ricerca, sottoposti a novità, aggiunte o rimozioni di campi caratterizzanti), analytics o dati relativi al geo-fencing. Proprio a supporto della geolocalizzazione MongoDB introduce il tipo di dato geo-spatial le cui ricerche sono ottimizzate e rapidissime a supporto di applicazioni che utilizzano dati geografici (app di food delivery, ecc…).

 

In cosa MongoDB è limitato?

 

Non supporta i JOIN

Croce e delizia della struttura schema-less è l’indipendenza di ogni document, proprio questa tipologia di approccio però rende impossibile l’incrocio dei dati ed il rispetto di eventuali vincoli di integrità referenziale tipici di MySQL.

Ciò non toglie che possiamo effettuare dei collegamenti tra document diversi ma eventuali eliminazioni o modifiche che coinvolgono queste relazioni, devono essere verificate a mano o a livello più alto a livello software.

 

Ridondanza dei dati

A causa dell’indipendenza dei document, non è possibile creare delle relazioni tra di essi e quindi mettere in comune stessi dati senza replicarli.

Rischiamo in questo modo di replicare dettagli all’interno di documenti dello stesso tipo, questo comporta uno spreco di spazio e di prestazioni della macchina su cui viene elaboriamo il dato.

 

Dimensione limite di un documento

Introdotto nelle ultime versioni di MongoDB, un documento può avere una dimensione massima di 16MB per evitare un degrado nelle prestazioni di manipolazione dei dati che vengono (a causa dell’atomicità del document) caricati tutti in RAM per essere manipolati.

 

Le Stored Procedures non sono supportate

Questo significa che, a differenza di MySQL, non possono essere implementate delle operazioni automatiche al salvataggio o manipolazione del dato. Questo è molto rilevante poiché si tratta di operazioni logiche a livello di DBMS che scaricano la Business Logic (software che utilizza il DB) di alcuni controlli molto importanti

 

Alcune caratteristiche ACID non sono rispettate

MongoDB non è in grado di rispettare contemporaneamente le caratteristiche di Atomicità, Consistenza, Isolamento e Durabilità del dato.
Successivamente amplieremo questo concetto a supporto.