Quando qualcuno dovrebbe usare MongoDB (o simile) su un DBMS relazionale?

Sono un po 'confuso sull'intera cosa NoSQL e così via. Quando sceglieresti di usare qualcosa come MongoDB su qualcosa come Oracle o MySQL? Non capisco davvero la "differenza" per quanto riguarda l'utilizzo tra loro.

Da quanto ho capito, i database di tipo NoSQL non sono pensati per sostituire gli RDBMS, ma cosa devono fare esattamente?

Ho usato CouchDB in precedenza per tre progetti di animali domestici.

• Un sistema di micro blogging.
• Per il salvataggio di informazioni per una piccola nota presa app che ho fatto.
• Un'applicazione di brainstorming per scopi generici.

Il motivo principale per cui ho scelto questo rispetto a qualcosa come MSSQL o MySQL è la flessibilità che ottieni quando lo usi. Nessuno schema rigido. Se tre mesi lungo la linea hai bisogno di un determinato tavolo per avere un campo in più, e questo e quello, lo cambi e si increspa da lì in poi.

Ho usato Beginning CouchDB di Apress per imparare ad usarlo.

Ad esempio, CouchDB utilizza json per comunicare da / verso il database. Se la tua lingua è in grado di inviare i dati POST, puoi utilizzarli per comunicare con il DB.

Leggi anche: Perché dovrei usare un database basato su documenti anziché un database relazionale? su StackOverflow

Mi dispiace aggiungere un'altra risposta, ma nessuna delle risposte qui è molto soddisfacente. Questa risposta è specifica per MongoDB (al contrario della vasta gamma di altre opzioni di archiviazione dei dati che non sono database relazionali).

Professionisti:

• MongoDB ha una latenza inferiore per query e impiega meno tempo CPU per query perché sta facendo molto meno lavoro (ad es. Nessun join, transazioni). Di conseguenza, può gestire un carico maggiore in termini di query al secondo e viene quindi spesso utilizzato se si dispone di un numero enorme di utenti.
• MongoDB è più facile da frammentare (utilizzare in un cluster) perché non deve preoccuparsi di transazioni e coerenza.
• MongoDB ha una maggiore velocità di scrittura perché non deve preoccuparsi di transazioni o rollback (e quindi non deve preoccuparsi di bloccare).
• MongoDB non ha uno schema nel caso in cui tu abbia un caso d'uso speciale che può trarne vantaggio.

Contro:

• MongoDB non supporta le transazioni . Ecco come ottiene la maggior parte dei suoi benefici.
• In generale, MongoDB crea più lavoro (ad es. Più costi della CPU) per il server client . Ad esempio, per unire i dati è necessario emettere più query ed eseguire il join sul client.
• Anche qui nel 2017 c'è meno supporto degli strumenti per MongoDB rispetto a quello dei database relazionali semplicemente perché è più recente. Ci sono anche meno esperti MongoDB rispetto alle loro controparti relazionali.

Punti spesso fraintesi:

• Sia MongoDB che i database relazionali supportano l'indicizzazione. Le prestazioni delle query sono simili in termini di esecuzione di query di grandi dimensioni .
• MongoDB non elimina la necessità di migrazioni o, più specificamente, l'aggiornamento dei dati esistenti con l'evoluzione dello schema. Ad esempio: se si dispone di un'applicazione che si basa su una tabella degli utenti per contenere determinati dati e si modifica quella tabella per contenere dati diversi (supponiamo che si aggiunga un campo immagine del profilo), sarà comunque necessario:
  • Scrivi l'applicazione per gestire gli oggetti per i quali questa proprietà non è definita OR
  • Scrivi una migrazione singola per inserire un valore predefinito per questa proprietà OPPURE
  • Scrivi il codice per fornire un valore predefinito al momento della query se questo campo non è presente OPPURE
  • Gestisci il campo mancante in qualche altro modo

Per rubare senza vergogna a Renesis (in realtà sto facendo questa risposta in senso orario):

Utilizzo di RDBMS invece di altri tipi:

• Leggi l'idea di "NoSQL" e altri tipi di DB:
  • NoSQL: se solo fosse così facile
  • (sopra è collegato da) Quando utilizzare MongoDB o altri sistemi di database orientati ai documenti? ^{attualmente cancellato su SO} ( altro )
  • https://softwareengineering.stackexchange.com/questions/5354/are-nosql-databases-going-to-take-the-place-of-relational-databases-is-sql-going
  • Quando utilizzare CouchDB vs RDBMS
• Gli RDBMS fanno un uso pesante dell'indicizzazione per le prestazioni. Su database molto grandi, ciò può influire negativamente sulle prestazioni o addirittura ridurre il numero ottimale di righe per DB / Shard che richiedono più hardware
• Non è l'ideale se si memorizza una grande quantità di dati ma si legge meno frequentemente
• Se non si hanno molte relazioni estere, i database relazionali potrebbero non essere l'ideale (archiviazione dei documenti)

Quando i tuoi dati non sono relazionali, possono esserci grandi vantaggi nell'uso di database NoSQL come prestazioni e scalabilità (ovviamente a seconda delle circostanze). Alcuni schemi di progettazione come CQRS rendono molto più semplice sfruttare i dati non relazionali in aree che richiedono convenzionalmente l'uso esclusivo di un database SQL.

È comune utilizzare database come mongo per i dati memorizzati nella cache. Ad esempio, se è necessario generare un report, è possibile eseguire una complessa query SQL che unisce e aggrega un mucchio di dati al volo, oppure è possibile recuperare un singolo documento JSON dal database Mongo che ha già tutto ciò che è necessario generare il rapporto. Questo rende la lettura dei dati davvero semplice (e veloce!), Ma può rendere la scrittura dei dati piuttosto complicata (è qui che entra in gioco CQRS).

Database come MongoDB sono fantastici quando di solito sai dove sono i tuoi dati (invece di dover scrivere diverse query complicate). Con Mongo, i dati "correlati" sono nidificati nei dati padre o hanno chiavi primarie / esterne. Questo è fantastico se, ad esempio, hai post e commenti; in genere, non visualizzerai i commenti al di fuori del contesto di un post, quindi ha senso che i commenti siano contenuti all'interno di un post (in questo modo ottieni tutti i commenti per il post senza dover interrogare una tabella separata).

MongoDB è senza schemi. Ciò significa che per la maggior parte prenderà qualunque struttura di dati ci passi.

D'altra parte, se hai bisogno di usare funzioni aggregate e senti la necessità di interrogare i dati in modi complessi che non possono essere raggiunti tramite incorporamenti o semplici relazioni in Mongo, è allora che sai che è tempo di usare un RDBMS come MySQL o PostgreSQL.

MongoDB non intende sostituire SQL. Soddisfa semplicemente le diverse esigenze e MongoDB e un RDBMS possono essere utilizzati insieme. A mio avviso, MongoDB non è così necessario se non hai bisogno che i tuoi dati siano flessibili o incorporati in un documento principale. Lo sviluppo con MongoDB è molto divertente perché ci sono molti meno passaggi necessari per mettere in funzione un progetto (diciamo in Rails). Devi fare un cambiamento? Nessun problema. Aggiungi un attributo al tuo modello. Fatto.

Non posso parlare per molti altri database NoSQL, anche se so che di solito sono progettati in modo simile per soddisfare un'esigenza specifica che non può essere soddisfatta da un RDBMS. Alcuni risiedono interamente in memoria o possono essere facilmente frammentati o ridimensionati. Sono abbastanza sicuro che Cassandra è progettato per continuare a funzionare senza perdita di dati se un nodo si arresta. Redis è fondamentalmente un archivio di valori chiave che risiede in memoria (con scritture periodiche del disco per la persistenza), ma ha anche la capacità di archiviare tipi di dati come set e ordinarli.

La vittoria principale è quando si desidera condividere i dati o disporre di database multi master. Puoi frammentare i dati in MySQL ma si trasforma in un grande problema. Se stai scrivendo molte cose, è spesso utile condividere i dati su più server, il problema è che se vuoi avere una forte coerenza referenziale mentre fai questo può essere molto difficile se non impossibile cercare il teorema di CAP.

I database SQL hanno una consistenza molto buona ma un supporto al partizionamento davvero scadente, i database NoSQL tendono ad andare dall'altra parte. Facile da partizionare ma spesso ciò che viene chiamato eventuale coerenza. Se stai costruendo un sito di messaggistica che va bene, per una banca probabilmente non va bene.

Il vantaggio è che ora ci sono più modelli su come archiviare i dati, quindi c'è una scelta su come implementare le cose, mentre prima c'erano solo database SQL.

SE Radio ha avuto alcuni buoni episodi su questo argomento.

MongoDB funziona bene quando si scrivono molti dati e quando le esigenze di interrogazione non sono troppo complicate. Pertanto, MongoDB è adatto quando si implementa CQRS con Event Sourcing sul lato comando, ovvero l'archivio eventi è un database MongoDB.

Per quanto riguarda le query, utilizziamo ancora un db di SQL Server con viste e WCF Data Services in cima, a causa della sua flessibilità. Penso che nella maggior parte dei casi avrai davvero bisogno della potenza di un DB relazionale per l'interrogazione.

La differenza immediata e fondamentale tra MongoDB e un RDBMS è il modello di dati sottostante. Un database relazionale struttura i dati in tabelle e righe, mentre MongoDB struttura i dati in raccolte di documenti JSON. JSON è un formato di dati auto-descrivibile e leggibile dall'uomo. Originariamente progettato per scambi leggeri tra browser e server, è diventato ampiamente accettato per molti tipi di applicazioni.

I documenti JSON sono particolarmente utili per la gestione dei dati per diversi motivi. Un documento JSON è composto da un insieme di campi che sono essi stessi coppie chiave-valore. Ciò significa che ogni documento JSON porta con sé il proprio disegno di schema leggibile dall'uomo ovunque vada, consentendo ai documenti di spostarsi facilmente tra il database e le applicazioni client senza perdere il loro significato.

JSON è anche un formato di dati naturale da utilizzare nel livello applicazione. JSON supporta una struttura dati più ricca e flessibile rispetto alle tabelle costituite da colonne e righe. Oltre a supportare tipi di campi come numero, stringa, booleano, ecc., I campi JSON possono essere matrici o oggetti secondari nidificati. Ciò significa che possiamo rappresentare un insieme di relazioni sofisticate che rappresentano in modo più ravvicinato gli oggetti con cui lavorano le nostre applicazioni. L'uso dei documenti JSON nel nostro database significa che non abbiamo bisogno di un mappatore relazionale di oggetti tra il nostro database e le applicazioni che serve. Possiamo conservare i nostri dati nella forma giusta

Se i tuoi dati hanno bisogno di molte query, allora una soluzione NoSQL non è buona e quando hai bisogno di supporto transazionale (ACID), allora un NoSql non è la soluzione migliore. Penso che NoSQL brilli quando hai molte letture che devono essere veloci e quando la struttura è in qualche modo ad hoc, recuperi per documento o per struttura di pagina, qualcosa del genere. Ma molte soluzioni NoSQL migliorano molto velocemente, quindi presto non ci saranno carenze. Comunque penso che i database relazionali siano ancora adatti per la maggior parte delle applicazioni.