In campo accademico l’approccio più comune per quanto riguarda la gestione delle basi di dati è quello del DB relazionale. Questo perché i DB relazionali sono impiegati in svariati campi dell’informatica e si adattano alla maggior parte dei casi d’uso più comuni.

Uno dei punti di forza dei database relazionali sono le transazioni che godono di determinate proprietà di cui i DB non relazionali sono sprovvisti: le famose proprietà ACID.

• Atomicity: l’intera transazione è riconducibile ad un’operazione atomica.
• Consistency: una transazione inizia in uno stato consistente e finisce in uno stato consistente, ovvero o viene eseguita con successo, o fallisce e conseguentemente è come se nessuna delle sue operazioni fosse stata eseguita (rollback).
• Isolation: dal momento che le transazioni vengono eseguite in parallelo, il loro scheduling ha una versione sequenziale.
• Durability: una volta che una transazione è stata eseguita con successo, il risultato che ne deriva è persistente anche in caso di errori di sistema.

La proprietà di atomicità in genere è rispettata su entrambi i tipi di DB. Eric Brewer invece (professore di informatica all’università di California, Berkley) ha parlato delle proprietà che i DB non relazionali devono rispettare, le proprietà BASE:

• Basic Availability: è garantita una risposta ad ogni richiesta, sia che sia conlusa con successo che con fallimento.
• Soft state: lo stato del sistema può cambiare nel corso del tempo, anche senza intervento dell’utente.
• Eventual consistency: dal momento che si ha soft state, possono verificarsi casi di mancata consistenza, la quale va gestita manualmente dallo sviluppatore.

Parliamo ora di alcuni aspetti e differenze tecniche dei due tipi di DB più utilizzati: MySql di tipo relazionale e MongoDB di tipo non relazionale.

Per quanto riguarda il data modeling, su MySql dobbiamo creare la struttura del database fin dal principio: ci si occupa di creare le tabelle (che rappresentano le strutture dati) definendo il tipo di dato per ogni colonna della tabella e il tipo di relazioni tra esse.

Su MongoDB invece parliamo di collezioni che sono delle raccolte dati simili a delle tabelle che contengono all’interno i vari documents (le righe delle tabelle per intenderci in MySql). Ogni document può avere una struttura diversa e avere o meno lo stesso numero di campi (colonne in MySql). Quindi si può dire che MySQL lavora con uno schema fisso, mentre MongoDB con uno schema flessibile.

La ricerca dei dati all’interno di questi database è differente: per quanto riguarda MySql si usa il lunguaggio di interrogazione SQL che costruendo delle query ci fornisce i risultati estraendo i dati dal DB tenendo conto dei vincoli di integrità. Il supporto delle join aiuta a combinare dati da più tabelle e le foreign key consentono di creare relazioni tra dataset mantenendone l’integrità.

Su MongoDB invece non ci sono join: questo perché essendo i documents nidificati ci si aspetta di trovare tutti i dati che servono direttamente dentro di essi. MongoDB quindi non ha vincoli sul tipo di dato nei campi, infatti, gli sviluppatori che lavorano su MongoDB tendono a usare molto gli ORM nei framewirks che utilizzano.

Sul discorso della scalabilità invece ci sono differenze sostanziali: MySql scala verticalmente mentre MongoDB orizzontalmente.

Scalare verticalmente significa che se ho una piattaforma web con accessi che crescono in modo scalare, ho bisogno di un hardware più potente ogni volta che ne ho l’esigenza. Quindi a causa della monoliticità della struttura dei DB MySql che per funzionare hanno bisogno dell’intera struttura dati su un’unica macchina non riesco a scalare orizzontalmente un sistema.

Invece scalare orizzontalmente significa che posso distribuire il carico di lavoro su più macchine (nodi) che posso replicare senza errori così da evitare carichi eccessivi su una singola macchina e in modo da evitare che il downserver possa portare discontinuità per un servizio.

Qual’é il migliore?

La risposta è nessuno dei due. Dipende dagli obiettivi del progetto, dal tipo di dato da gestire, da cosa si deve realizzare e soprattutto dalla stima dei dati di crescita di una piattaforma web. Infatti a volte in alcune applicazioni si tende ad usare entrambi.

Riassumendo

MySQL è altamente organizzato per la sua flessibilità, alte prestazioni, protezione dei dati affidabile e facilità nella gestione dei dati. Una corretta indicizzazione dei dati può risolvere il problema per le prestazioni, facilitare l’interazione e garantire solidità.

Ma se i tuoi dati non sono strutturati e complessi da gestire, o la pre-definizione del tuo schema non ti sarà facile, dovresti optare per MongoDB. Inoltre, se è necessario gestire un grande volume di dati e archiviarli come documenti, MongoDB ti aiuterà molto!

E tu? Mentre programmi cosa usi di solito? Fammelo sapere nei commenti qui sotto!