Sfatiamo i principali miti su MongoDB e i database relazionali

Recentemente ho parlato con un mio amico su quale database scegliere per un progetto futuro. Gli ho chiesto cosa ne pensasse di MongoDB. Mi ha detto che non pensava che avrebbe funzionato in base a ciò che sapeva al riguardo. L'unico problema è che tutto ciò che aveva imparato su MongoDB risaliva al 2013. Non si era tenuto al passo con più di un decennio di miglioramenti e aggiornamenti. Parlando con altri sviluppatori sembra essere una situazione piuttosto comune. Molti sviluppatori hanno avuto una prima impressione di MongoDB tra il 2012 e il 2014 e hanno preso le loro decisioni in base a questo. In questo articolo, ci addentreremo nella storia dei database e vedremo come MongoDB si confronta oggi con i relational database.

Come ripasso rapido, esistono diversi tipi di database, ma ci concentreremo sui relational database e sui database di documenti NoSQL, poiché sono due dei tipi più popolari oggi in uso. I relational database sono stati introdotti negli anni '70 e archiviano i dati nelle tabelle. Sebbene il termine NoSQL sia stato coniato nel 1998 da Carlo Strozzi, sono stati necessari ancora alcuni anni affinché i database NoSQL e il loro approccio più flessibile all'archiviazione dei dati prendessero piede. Nel 2009 MongoDB è stato lanciato con l'idea di archiviare i dati in documenti simili agli oggetti JSON. Quando spiego alla mia famiglia la differenza di base tra i relational database e quelli di documenti, di solito dico che uno è come un foglio di calcolo e l'altro è come un Google Doc. Non sono ancora sicuro di quanto mia nonna capisca cosa faccia di lavoro, ma almeno ora conosce la differenza tra i tipi di database.

Bene, ora che abbiamo coperto le nozioni di base, esamineremo i malintesi che sorgono nel confrontare MongoDB con i database relazionali.

Mito 1: MongoDB non ha uno schema

Gli schemi definiscono la struttura dei dati in un database. Con i database relazionali, in genere si progetta lo schema in base alla normalizzazione dei dati. Normalizzare significa suddividere i dati in tabelle diverse in modo da non duplicarli. Questi schemi definiti sono ottimi se è possibile prevedere tutte le future esigenze di dati e progettarli in modo elegante in anticipo. L'aggiornamento di questi schemi per aggiungere nuovi campi può comportare lavoro extra e tempi di inattività per l'applicazione.

Con MongoDB, lo schema dipende dalle esigenze dell'applicazione. Questo è un approccio più flessibile alla progettazione dello schema. Tuttavia, anche se c'è flessibilità, esistono comunque best practice come la regola secondo cui "i dati a cui si accede insieme devono essere archiviati insieme".

Ecco un esempio dei dati relazionali di cui sopra memorizzati in MongoDB:

È possibile vedere in questo esempio che si è in grado di ottenere tutti i dati su “Paul Miller” senza dover fare JOIN su tre diverse tabelle. È possibile effettuare JOIN in MongoDB, ma ne parleremo più avanti.

Grazie a uno schema flessibile, gli sviluppatori possono iniziare a creare applicazioni senza dover progettare in anticipo lo schema definitivo, per poi vincolarsi ad esso. È possibile aggiungere facilmente nuovi campi allo schema ogni volta che l'applicazione lo richiede. Se si desidera uno schema più strutturato, è possibile utilizzare la funzionalità di convalida dello schema di MongoDB. Se è necessario che lo schema si evolva nel tempo, è anche possibile implementare facilmente il modello di controllo versioni dello schema.

In definitiva, penso che questo mito di MongoDB senza schema dipenda da due cose. In primo luogo, all'inizio non disponeva di convalida dello schema (è stata aggiunta nella versione 3.6 nel 2017). L'altro motivo deriva dalla flessibilità che gli sviluppatori hanno nel creare il proprio schema in base alle esigenze delle proprie applicazioni. Libertà e flessibilità non significano non avere uno schema; significa solo che è importante seguire le migliori pratiche per creare uno schema elegante che faccia funzionare l'applicazione in modo ottimale.

Mito 2: MongoDB non è conforme ad ACID

I database hanno bisogno di modi per assicurarsi che le operazioni e i dati risultanti siano affidabili anche in presenza di errori o interruzioni dell'alimentazione. Il modo principale per farlo è l'implementazione di quattro proprietà: atomicità, coerenza, isolamento e durabilità, note anche come ACID.

MongoDB è conforme ad ACID. Ogni volta che si esegue un'operazione di creazione, lettura, aggiornamento ed eliminazione su un singolo documento, l'integrità dei dati viene preservata. MongoDB gestisce i dati un documento alla volta. Altrimenti, non sarebbe un database documentale. Sarebbe un database caotico e imprevedibile. Riesci a immaginare molti autori che tentano di sovrascrivere lo stesso documento contemporaneamente? Ho partecipato ad alcuni Google Docs con oltre 10 autori che contribuivano tutti contemporaneamente e, certamente, non sembra conforme ad ACID.

Questo copre i documenti singoli, ma cosa succede con le transazioni multi-documento? Le transazioni multi-documento sono utilizzate frequentemente nei relational database, poiché spesso è necessario accedere a più tabelle quando si eseguono operazioni come l'aggiornamento di un record cliente. MongoDB garantisce transazioni ACID multi-documento da e verso qualsiasi posizione nel tuo cluster MongoDB. Ha supportato questa garanzia dalla versione 4.0 nel 2018.

Infatti, la transazionalità è uno dei maggiori punti di forza di MongoDB. Molte aziende di servizi finanziari si affidano alle transazioni MongoDB per i principali casi d'uso bancari e di trading. La garanzia "tutto o niente" delle transazioni multi-documento di MongoDB è la tua spalla.

Mito 3: MongoDB non può eseguire JOIN per gestire i dati relazionali

In precedenza abbiamo mostrato come i relational database si basino sui dati suddivisi su più tabelle per un efficiente schema design. Per lavorare con i dati relazionali, è spesso necessario estrarre i dati da tali tabelle e combinarli utilizzando JOIN.

MongoDB può eseguire JOIN con il comando $lookup. Ma il fatto che tu possa fare qualcosa non significa che tu debba farlo. I dati MongoDB sono modellati in modo diverso rispetto ai dati relazionali. In MongoDB, i dati a cui si accede insieme vengono archiviati insieme. Con la maggior parte dei dati in un singolo documento anziché distribuiti su più tabelle, non sarebbe necessario eseguire alcun JOIN poiché i dati si trovano già nella posizione corretta. Questo passaggio dal modello relazionale al document model rappresenta un grande cambiamento di mentalità, ma una volta sperimentati i vantaggi, è difficile tornare indietro. Tuttavia, se hai ancora bisogno di eseguire JOIN con MongoDB, il comando $lookup è il tuo miglior alleato. Puoi anche creare una VIEW (aggiunta nel 2016) per unire due tabelle.

Il mito che i JOIN non siano possibili si riduce in definitiva alla differenza di base tra i modelli relazionali e quelli dei documenti. I dati a cui si accede nelle tabelle e quelli a cui si accede nei documenti richiedono approcci diversi, ma in genere, anche se è possibile eseguire JOIN in MongoDB, non sarà necessario se si è progettato bene lo schema per i propri documenti.