Quando dovremmo usare MongoDB?

In sostanza:

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

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

Ecco due esempi che trovo illustrativi:

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

  Questo potrebbe essere memorizzato come un mucchio di tabelle, ma quando si tenta di costruire un modello, cresce molto velocemente fino a una dozzina di tavoli, se non di più. Alcune query SQL potrebbero diventare brutte con un sacco di join s, e ... beh, si ottiene l'immagine.

  Il problema qui è che esiste una cosa centrale - un articolo sul blog - e c'è tutto questo nell'articolo, che lo rende adatto per un database basato su documenti. Con MongoDB la modellazione del database è stata 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 conterrà tutte le informazioni di cui ho bisogno durante la visualizzazione di un articolo, sarebbe il nome dell'autore o dei tag.

• Ora immagina un progetto molto diverso. Ci sono alcuni utenti che possono scrivere cose e condividere le cose scritte da altri utenti. In una pagina di un utente, ci si aspetterebbe di trovare entrambe le cose scritte da questo utente e 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 quello che sarebbe il documento. Un utente forse? Bene, questo è un buon inizio. Un documento utente contiene tutte le cose che questo utente ha scritto. Ma per quanto riguarda 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 esaminare tutti i documenti dell'utente nel database per modificare ogni occorrenza della voce precedente. Senza contare la duplicazione dei dati.

  Un'alternativa sarebbe quella di mantenere all'interno del documento dell'utente solo l'elenco di voci condivise da questo utente (con l'ID dell'utente e voce di riferimento). Ma ora si presenterebbe un problema diverso: se un utente condivideva migliaia di voci da migliaia di utenti, sarebbe necessario aprire migliaia di documenti per ottenere quelle voci.

  O possiamo modellare la nostra collezione attorno alle voci stesse, ogni voce si riferisce al suo autore e ha un elenco di utenti che lo hanno condiviso. Anche in questo caso, i problemi relativi alle 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 usando un database relazionale? Giusto, tre. Sarebbe semplice modellare e anche semplice da usare.

Ogni tecnologia ha i suoi vantaggi.

I vantaggi dei database relazionali è che l'RDBMS fa alcune cose per te, come:

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

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

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

D'altro canto, uno dei vantaggi dei database NOSQL è che scalano 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 ha bisogno di queste funzionalità.

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

MongoDB è più adatto in scenari che richiedono lettura / scrittura di molti dati, senza molta enfasi sulla sicurezza delle transazioni (se alcuni dati si perdono occasionalmente in un crash del server, non è un grosso problema ), si prevede di ridimensionarsi in grande, e in realtà non hanno uno schema stabile.

MongoDB è non adatto per scenari che richiedono:

1. Buone garanzie ACID: MongoDB consente di archiviare dati duplicati, letture incoerenti e persino perdita di dati. Queste cose vanno bene in alcune applicazioni, ma non nella maggior parte dei casi.
2. Transazioni multi-oggetto: MongoDB supporta le transazioni ACID, ma solo per un singolo oggetto / documento. Questo semplicemente non lo taglierà per operazioni più complesse come i bonifici bancari, la prenotazione, ecc.
3. BI tradizionale: ci sono molti strumenti di BI là fuori che funzionano solo bene 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 un sacco di cose complesse (mentre con MongoDB avresti problemi eseguire un semplice join) ed è trasferibile attraverso molte implementazioni.

MongoDB è più veloce e ti permetterà di ottenere più prestazioni dal sistema eliminando un sacco di cose che RDBMS applica di default, come i controlli di integrità (nota che puoi anche modificare RDBMS per tali scopi, comunque), ma il la verità è che, nella maggior parte degli scenari, non è proprio 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 i tuoi dati (e nelle connessioni dei tuoi dati) hanno più valore. Se non lo sai ancora, probabilmente è meglio se scegli qualcosa che non ti dipinga in un angolo in futuro, e ti permetterà di aggiungere le funzionalità ed eseguire le operazioni di cui l'applicazione ha bisogno.

MongoDB è utile per memorizzare tutti i dati strutturati necessari per costruire una determinata istanza di una pagina web. Puoi 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. Il che significa che se cambi qualcosa nella struttura della tua pagina web, potrebbe essere possibile che tu non abbia i dati per riempire i buchi nelle tue pagine già memorizzate. Maggiori informazioni su questo qui: link

MongoDB è fantastico quando puoi rappresentare i tuoi dati come "pacchetti" indipendenti di informazioni. Hai i codici postali di google maps, incorporati nel codice di avviamento 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.

Una volta detto questo, sono completamente in disaccordo con la tendenza attuale che sto osservando che implica che MongoDB sia una specie di post e soluzione superiore a RDBMS e noSQL deve essere la soluzione di default. Tutto ciò è assurdo. MongoDB è un database di nicchia e il 90% dei progetti è relazionale e necessita di un'opzione RDBMS perché vuoi una soluzione di query potente come SQL per generare i tuoi report e cercare dati dispersivi: 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 è ancora più stretta ora.