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’è MySQL?
MySQL è un DBMS (DataBase Management System) relazionale che ha come principale struttura di contenimento dati le tabelle organizzate in righe (dati da immagazzinare) e colonne (campi di pertinenza del campo riga).
Il linguaggio utilizzato per interagire con questa tipologia di DBMS è il SQL (Structured Query Language) suddiviso ulteriormente in DDL, DML e QL, per un approfondimento faccio riferimento a questa sezione: CLICCA QUI.
La relazione tra dati salvati su tabelle diverse avviene tramite JOIN, dei costrutti logici introdotti al momento della creazione della tabella che permettono di correlare una riga con una o più di tabelle eterogenee.
MySQL è sempre stato un DBMS molto stabile e tollerante a enormi quantità di dati senza perdite sostanziali di prestazioni. Questo ci viene garantito dal MultiThreading e dalla possibilità di installare MySQL in cluster, ovvero una installazione condivisa su macchine diverse che collaborano per sembrare all’esterno una singola macchina operante.
Per cosa viene usato MySQL?
La sua presenza sul mercato da oltre un decennio e la facilità di utilizzo grazie alla sempre presente Community Edition Server (che lo rende gratuito per scopi non commerciali) e la sua versione OpenSource gli ha fatto aggiudicare una fetta di mercato molto importante tra sviluppatori in erba e per lo sviluppo di progetti Low Budget.
In ambito operativo troviamo MySQL in quasi tutti gli spazi Hosting dove possiamo sviluppare il nostro Sito Web, E-Commerce, è la base di WordPress, Drupal e Joomla e come possiamo immaginare la larga diffusione lo ha fatto diventare il punto di riferimento di sviluppatori di tutto il mondo.
Possiamo includere MySQL come riferimento per progetti con le seguenti caratteristiche:
- Salvataggio di dati strutturati e con campi standard come in un e-commerce o impieghi che hanno mutabilità delle colonne pressoché nulla (è molto improbabile che una tabella che contenga nome, cognome e data di nascita abbia una variazione nel nome delle colonne.
- Salvataggio di dati sequenziale per impieghi di consultazione temporale. In un blog o in una testata giornalistica l’ordine di arrivo delle notizie è molto importante e la presenza di valori “auto incrementali” e le performance nel riordinare le righe all’interno della tabella sono estremamente comode.
- Time-to-market rapido, la maggior parte dei service provider o rivenditori di Hosting hanno già a disposizione piani con MySQL installato e non c’è bisogno di competenze sistemistiche per la messa online.
In cosa MySQL è limitato?
Come ogni altro DBMS di tipologia “relazionale” soffre in alcuni punti fondamentali che negli anni altri DBMS hanno cercato di risolvere:
Un DataBase distribuito su più macchine è molto difficile da gestire
Immaginiamo di dover salvare i dati anagrafici dell’Europa intera dal 1900 ad oggi, è molto improbabile che tutti questi dati riescano ad essere immagazzinati su un solo PC. La soluzione più ovvia potrebbe essere quella di creare un archivio basato per data di nascita all’interno di un cluster (un agglomerato di PC) suddivisi secondo una politica restrittiva sull’anno di nascita o altro algoritmo.
Immaginiamo di voler salvare i dati su due PC a seconda della data di nascita, un possibile algoritmo di partizionamento e salvataggio dei dati potrebbe coinvolgere la data ti nascita. I nati dal 1900 al 1950 verranno salvati sul PC1 e coloro che sono nati dal 1950 al 2000 verranno salvati sul PC2.
- Il bilanciamento del carico: a causa dello squilibrio delle nascite dal 1900 al 1950 e dal 1950 al 2000 potremmo avere un carico maggiore sul primo blocco di date anziché il secondo.
- La ricerca per data di nascita potrebbe diventare molto onerosa poiché coinvolgerebbe due computer diversi che attiverebbero delle routine non “Climate pledge friendly”.
Alla ricerca di un nato nel 1922 si attiverebbero due ricerche in parallelo su entrambe le macchine, un aumento di prestazioni molto elevato ma uno spreco di energia inutile poiché la ricerca partirebbe anche sul PC2.
Un DataBase grande significa minori prestazioni
Come tutti i DataBase Relazionali, salvando i dati nelle tabelle, ci si espone ad una crescita verticale ovvero ad una tabella che cresce nel numero di righe in maniera spropositata.
Il sistema che più si avvicina ad un RDBMS è un foglio Excel, più dati vogliamo salvare sul nostro file e più le dimensioni di esso (a livello di Hard Disk) aumentano. Immaginiamo ora di voler effettuare una ricerca all’interno di questo file con delle “query” complesse, non possiamo ovviamente aspettarci le stesse performance con la presenza di 1.000 record (righe strutturate in campi tabellari) e 1.000.000 di record.
Il problema è proprio relativo al fatto che il “DataBase File” (il file o gruppo di file dove vengono salvati i dati dal DBMS), cresce in maniera proporzionale al numero di record da gestire.
Quando ricerchiamo un dato dobbiamo sempre pensare al “caso peggiore” ovvero il caso in cui il record interessato sia l’ultimo della lista e di conseguenza dobbiamo necessariamente scansionare tutto il file.
Salvataggio di dati sotto forma tabellare
Come già anticipato nei punti precedenti, uno dei contro del DBMS Relazionale è la tipologia di salvataggio dei dati, una forma tabellare implica un certo livello di immutabilità.
Se immaginiamo una tabella dove salvare l’anagrafica cliente composta dai campi Nome, Cognome, Telefono e Codice Fiscale all’aggiunta di un campo aggiuntivo come ad esempio Indirizzo Email dobbiamo fare il re-design dell’intera tabella.
Il re-design implica che tutti i precedenti record inseriti avranno a disposizione questo campo ovviamente non popolato a meno della definizione di un valore di default.
