Quando dovremmo usare MongoDB?

MongoDB è un database NoSQL che ho trovato abbastanza facile da usare. Di recente ho dovuto sviluppare una semplice applicazione che doveva raccogliere alcuni dati utilizzando le richieste HTTP e archiviare alcuni risultati dopo l'elaborazione dei dati, e ho provato a utilizzare MongoDB.

Da questa esperienza l'ho trovato molto più piacevole da usare rispetto ai tradizionali database relazionali e dato che sono uno sviluppatore e non un DBA, il mio lavoro è stato notevolmente semplificato.

Tuttavia, a volte non sono sicuro di quando dovrei usare MongoDB invece di un tradizionale database relazionale, come SQL Server o MySQL.

In tal caso, quando possiamo usare MongoDB invece di database relazionali? C'è qualche avvertimento veramente grande su MongoDB che lo rende inadeguato per alcune situazioni?

Fondamentalmente:

• Se riesci a rappresentare i tuoi dati sotto forma di un mucchio di documenti, MongoDB potrebbe essere una buona scelta.

• Se preferisci immaginare i tuoi dati come un insieme di tabelle interconnesse, MongoDB potrebbe non essere una buona scelta.

Ecco due esempi che trovo illustrativi:

• Alcuni anni fa, ho creato un motore di blog. Il suo scopo è di ospitare articoli del blog e, per ogni articolo, memorizzare le diverse versioni, alcuni metadati, statistiche sulle visite, ecc.

  Questo potrebbe essere memorizzato come un gruppo di tabelle, ma quando si tenta di creare un modello, cresce molto rapidamente fino a una dozzina di tabelle, se non di più. Alcune query SQL potrebbero diventare brutte con un sacco di joins, e ... beh, ottieni l'immagine.

  Il problema qui è che c'è un elemento centrale, un articolo di blog, e c'è tutto ciò che circonda l'articolo, il che lo rende adatto per un database basato su documenti. Con MongoDB, modellare il database è stato estremamente semplice: una raccolta contiene gli articoli del blog e una seconda raccolta contiene l'elenco degli utenti autorizzati a scrivere articoli. Ogni documento all'interno della prima raccolta conterrebbe tutte le informazioni di cui ho bisogno durante la visualizzazione di un articolo, sarebbe il nome dell'autore o i tag.

• Ora immagina un progetto molto diverso. Ci sono alcuni utenti che possono scrivere e condividere contenuti scritti da altri utenti. Su una pagina di un utente, ti aspetteresti di trovare sia le cose che questo utente ha scritto sia quelle che ha condiviso. C'è un vincolo: quando qualcuno modifica ciò che ha scritto in passato, il cambiamento appare ovunque dove è stato condiviso il testo originale.

  Con un approccio basato su documenti, è difficile trovare quale sarebbe il documento. Un utente forse? Bene, è un buon inizio. Un documento utente conterrebbe tutto ciò che questo utente ha scritto. E le cose che ha condiviso?

  Un modo possibile è mettere quelle cose nello stesso documento. Il problema con questo approccio è che se qualcuno modifica una voce, l'applicazione dovrebbe scorrere tutti i documenti utente nel database al fine di modificare ogni occorrenza della vecchia voce. Senza contare la duplicazione dei dati.

  Un'alternativa sarebbe quella di mantenere nel documento dell'utente solo l'elenco delle voci condivise da questo utente (con l'ID dell'utente e la voce indicati). Ma ora si verificherebbe un problema diverso: se un utente condividesse migliaia di voci da migliaia di utenti, richiederebbe l'apertura di migliaia di documenti per ottenere tali voci.

  Oppure possiamo modellare la nostra raccolta attorno alle voci stesse, ciascuna delle quali fa riferimento al suo autore e con un elenco di utenti che l'hanno condivisa. Anche in questo caso, i problemi di prestazioni potrebbero diventare evidenti quando sarà necessario esaminare tutti i documenti per mostrare quelli pubblicati da un determinato utente.

  Ora, di quante tabelle avresti bisogno se stessi utilizzando un database relazionale? Giusto, tre. Sarebbe semplice da modellare e anche semplice da usare.

Ogni tecnologia ha i suoi vantaggi.

I vantaggi dei database relazionali sono che RDBMS fa alcune cose per te, come:

• Applicazione dell'integrità referenziale (non consentire l'inserimento di un dettaglio della fattura se la fattura a cui appartiene non esiste)
• Evita la ridondanza: le cose vengono archiviate una sola volta.
• Le query complesse possono essere eseguite con un linguaggio dichiarativo (SQL) che è maturo, comprovato e ampiamente diffuso.

Tutto ciò si riduce al fatto che devi scrivere meno codice perché RDBMS fa rispettare le cose per te.

Inoltre, indipendenza dei dati: spesso se si utilizzano strutture SQL standard e non quelle specifiche del fornitore, è possibile migrare i dati da un RDBMS a un altro con una seccatura minima, mentre i database NOSQL non sono affatto standardizzati.

D'altro canto, uno dei vantaggi dei database NOSQL è che si adattano meglio mantenendo le prestazioni per milioni di righe. Sono più adatti per l'archiviazione basata su documenti, ovvero dati non strutturati. Ma la maggior parte delle applicazioni non necessita di queste funzionalità.

Per il tuo caso particolare, MongoDB sembra una buona scelta, ma ci sono molti scenari (probabilmente la maggior parte di essi) in cui non sarebbe la scelta migliore.

MongoDB è più adatto in scenari che richiedono la lettura / scrittura di molti dati, senza molta enfasi sulla sicurezza delle transazioni (se alcuni dati si perdono occasionalmente in un arresto del server, non è un grosso problema), si aspettano di ridimensionare e non hanno davvero uno schema stabile.

MongoDB non è adatto per scenari che richiedono:

1. Forti garanzie ACID: MongoDB consente di memorizzare dati duplicati, letture incoerenti e persino perdita di dati. Queste cose vanno bene in alcune applicazioni, ma non nella maggior parte.
2. Transazioni multi-oggetto: MongoDB supporta transazioni ACID, ma solo per un singolo oggetto / documento. Questo non lo taglierà per operazioni più complesse come bonifici bancari, prenotazione, ecc.
3. BI tradizionale: ci sono molti strumenti di BI che funzionano bene solo con SQL tradizionale.
4. SQL: MongoDB ha un linguaggio di query molto specifico, mentre SQL è molto conosciuto da molte persone (potrebbe essere un aspetto importante da considerare), può fare molte cose complesse (mentre con MongoDB avresti problemi a eseguire un semplice join) ed è trasferibile attraverso molte implementazioni.

MongoDB è più veloce e ti consentirà di ottenere più prestazioni dal sistema eliminando molte cose che RDBMS applica per impostazione predefinita, come i controlli di integrità (nota che puoi anche modificare RDBMS per tali scopi, comunque), ma la verità è, nella maggior parte degli scenari, non è necessario. Inoltre, il compromesso è affidabilità e flessibilità (avrai problemi se, in seguito, deciderai di dover eseguire operazioni più complesse con i dati esistenti).

Tutto dipende dalle esigenze dell'applicazione che stai creando. Velocità e disponibilità o sicurezza, affidabilità e flessibilità. Devi sapere dove si trovano più valore nei tuoi dati (e nelle loro connessioni). Se non lo sai ancora, probabilmente è meglio scegliere qualcosa che in futuro non ti dipingerà e ti consentirà di aggiungere funzionalità ed eseguire le operazioni di cui l'applicazione ha bisogno.

MongoDB è fantastico quando puoi rappresentare i tuoi dati come "pacchetti" indipendenti di informazioni. Hai codici postali di google maps, integrati nel codice postale sono aziende e all'interno delle aziende sono impiegati. Tutti i codici postali sono indipendenti l'uno dall'altro e puoi ottenere tutte le informazioni in modo semplice, carino e veloce. Questo è un buon scenario per una soluzione non SQL.

Detto questo, non sono assolutamente d'accordo con l'attuale tendenza che sto osservando, il che implica che MongoDB è una specie di posta e una soluzione superiore a RDBMS e noSQL deve essere la soluzione predefinita. Tutto ciò è assurdo. MongoDB è un database di nicchia e il 90% dei progetti è relazionale e necessita di un'opzione RDBMS perché si desidera una potente soluzione di query come SQL per generare report e cercare dati dispersi: i "join" sono un pro, non un contro. Inoltre, i moderni RDBMS supportano le raccolte BSON e l'integrazione geospaziale, quindi forse la nicchia di noSQL ora è ancora più stretta.

MongoDB è utile per archiviare tutti i dati strutturati necessari per creare una determinata istanza di una pagina Web. È possibile recuperare i dati per una determinata pagina, passarli all'applicazione client che può quindi renderizzarli.

In tale contesto, MongoDB è molto veloce e affidabile. Ma non dimenticare mai che non hai informazioni relazionali nel tuo database. Ciò significa che se cambi qualcosa nella struttura della tua pagina web, potresti non essere in grado di colmare i buchi nelle pagine già memorizzate perché non hai i dati necessari per farlo. Maggiori informazioni qui: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/