Quando utilizzare MongoDB o altri sistemi di database orientati ai documenti? [chiuso]


516

Offriamo una piattaforma per clip video e audio, foto e grafica vettoriale. Abbiamo iniziato con MySQL come backend del database e recentemente incluso MongoDB per la memorizzazione di tutte le meta-informazioni dei file, perché MongoDB si adatta meglio ai requisiti. Ad esempio: le foto possono avere informazioni Exif , i video possono avere tracce audio in cui anche noi vogliamo archiviare le meta-informazioni. I video e la grafica vettoriale non condividono alcuna meta-informazione comune, ecc. Quindi so che MongoDB è perfetto per archiviare questi dati non strutturati e mantenerli ricercabili.

Tuttavia, continuiamo a sviluppare la nostra piattaforma e ad aggiungere funzionalità. Ora uno dei prossimi passi sarà fornire un forum per i nostri utenti. La domanda che si pone ora è: utilizzare il database MySQL, che sarebbe una buona scelta per archiviare forum e post di forum, ecc. O usare MongoDB anche per questo?

Quindi la domanda è: quando usare MongoDB e quando usare un RDBMS. Cosa prenderesti, mongoDB o MySQL, se avessi la scelta e perché lo prenderesti?


12
Non sono sicuro del perché questo sia contrassegnato come basato sull'opinione quando chiaramente non lo è. C'è una chiara risposta giusta o sbagliata qui.
Spencer,

Risposte:


659

In NoSQL: If Only It Was That Easy , l'autore scrive su MongoDB:

MongoDB non è un archivio chiave / valore, è un po 'di più. Non è nemmeno un RDBMS. Non ho usato MongoDB in produzione, ma l'ho usato un po 'per costruire un'app di test ed è un kit molto interessante. Sembra essere molto performante e o ha, o avrà presto, tolleranza agli errori e auto-sharding (ovvero scalerà). Penso che Mongo potrebbe essere la cosa più vicina a una sostituzione RDBMS che ho visto finora. Non funzionerà per tutti i set di dati e i modelli di accesso, ma è costruito per le tue cose CRUD tipiche. La memorizzazione di ciò che è essenzialmente un enorme hash e la possibilità di selezionare una di quelle chiavi è ciò per cui la maggior parte delle persone utilizza un database relazionale.Se il tuo DB è 3NF e non fai alcun join (stai solo selezionando un gruppo di tabelle e mettendo insieme tutti gli oggetti, cosa che la maggior parte delle persone fa in un'app Web), MongoDB probabilmente ti darebbe un calcio nel culo.

Quindi, in conclusione:

La cosa vera da sottolineare è che se ti stai trattenendo dal creare qualcosa di eccezionale perché non puoi scegliere un database, lo stai facendo in modo sbagliato. Se conosci mysql, basta usarlo. Ottimizza quando è effettivamente necessario. Usalo come ak / v store, usalo come un rdbms, ma per l'amor del cielo, costruisci la tua app killer! Niente di tutto ciò sarà importante per la maggior parte delle app. Facebook utilizza ancora MySQL, molto. Wikipedia usa MySQL, molto. FriendFeed usa MySQL, molto. NoSQL è un ottimo strumento, ma sicuramente non sarà il tuo vantaggio competitivo, non renderà la tua app calda e, soprattutto, ai tuoi utenti non importa nulla di tutto questo.

Su cosa costruirò la mia prossima app? Probabilmente Postgres. Userò NoSQL? Può essere. Potrei anche usare Hadoop e Hive. Potrei tenere tutto in file flat. Forse inizierò a hackerare Maglev. Userò tutto ciò che è meglio per il lavoro. Se ho bisogno di segnalazioni, non userò nessun NoSQL. Se ho bisogno della cache, probabilmente userò Tokyo Tyrant. Se ho bisogno di ACIDity, non userò NoSQL. Se ho bisogno di un sacco di segnalini, userò Redis. Se ho bisogno di transazioni, userò Postgres. Se ho una tonnellata di un solo tipo di documenti, probabilmente userò Mongo. Se avessi bisogno di scrivere 1 miliardo di oggetti al giorno, probabilmente userei Voldemort. Se avessi bisogno di una ricerca a testo integrale, probabilmente userei Solr. Se avessi bisogno di una ricerca a testo integrale di dati volatili, probabilmente userei Sphinx.

Mi piace questo articolo, lo trovo molto istruttivo, offre una buona panoramica del panorama e dell'hype NoSQL. Ma, e questa è la parte più importante, aiuta davvero a porsi le domande giuste quando si tratta di scegliere tra RDBMS e NoSQL. Vale la pena leggere l'IMHO.

Link alternativo all'articolo


4
grazie, è davvero un articolo molto interessante.
aurora,


48
@iddqd ROFL! Amico, questo è stato divertente. "Se sei abbastanza stupido da ignorare totalmente l'affidabilità solo per ottenere benchmark, ti ​​suggerisco di reindirizzare i tuoi dati /dev/null, sarà molto veloce" : D
Pascal Thivent

3
Grazie per la risposta consapevole hype.
Deamon,

2
Spero che BJ Clark non scelga di usare tutte quelle tecnologie nello stesso progetto. Sarebbe un po 'una curva di apprendimento.
Adam Monsen,

186

Dopo due anni che ho usato MongoDb per un'app social, ho visto cosa significa veramente vivere senza un RDBMS SQL.

  1. Finisci per scrivere lavori per fare cose come unire dati da diverse tabelle / raccolte, cosa che un RDBMS farebbe automaticamente per te.
  2. Le funzionalità di query con NoSQL sono drasticamente paralizzate. MongoDb potrebbe essere la cosa più vicina a SQL ma è ancora molto indietro. Fidati di me. Le query SQL sono super intuitive, flessibili e potenti. Le query MongoDb non lo sono.
  3. Le query MongoDb possono recuperare i dati da una sola raccolta e sfruttare un solo indice. E MongoDb è probabilmente uno dei database NoSQL più flessibili. In molti scenari, ciò significa più viaggi di andata e ritorno al server per trovare record correlati. E poi inizi a de-normalizzare i dati, il che significa lavori in background.
  4. Il fatto che non si tratti di un database relazionale significa che non avrete vincoli di chiave esterna (ritenuti da alcuni inadeguati) per garantire la coerenza dei dati. Ti assicuro che questo alla fine creerà incoerenze nei dati nel tuo database. Essere preparato. Molto probabilmente inizierai a scrivere processi o controlli per mantenere coerente il tuo database, che probabilmente non funzionerà meglio che lasciare che RDBMS lo faccia per te.
  5. Dimentica le strutture mature come l'ibernazione.

Credo che il 98% di tutti i progetti probabilmente siano molto meglio con un tipico RDBMS SQL che con NoSQL.


10
pensieri interessanti ...
luigi7up

3
D'altra parte, le funzionalità di query e i join che descrivi non dovrebbero essere un problema: se usi MongoDB, dovrai comunque fare qualche lavoro per progettare le tue raccolte e quali dati inserirai in modo da non aver bisogno di complessi ISCRIVITI e così via. Comunque i DB non sono un collo di bottiglia e ci sono soluzioni alternative come Memcache per alcuni casi d'uso. Se a partire da zero, tuttavia, potresti scoprire che la progettazione e l'uso di MongoDB è più semplice e veloce (come sviluppatore che lavora con il codice oggetto, non ho bisogno di un ORM). Sicuro che devi scrivere alcuni script, ma in realtà non è così difficile e riutilizzi il codice
Aki

1
La maggior parte delle persone non utilizzerà i database NoSQL per il caso d'uso molto specifico per cui sono stati creati, reinventando così tante ruote in seguito. Il dibattito NoSQL vs. SQL mostra che molte persone sperimentano l'uso di NoSQL come se tornassero indietro di 20-30 anni, in tempi pre-Codd, pre-relazionali e pre-SQL . Oppure, come dice Michael Stonebraker: "Ciò che va intorno viene intorno"
Lukas Eder,

1
L'articolo 3, "e approfitta di un solo indice" è ancora valido oggi? Sto entrando in MongoDB ora e sembra da quello che ho letto / visto finora che può supportare più indici?
Jeach,

1
@Jeach: No, # 3 non è più vero. MongoDB 2.6 ha introdotto l' intersezione dell'indice .
Rob Garrison,

26

per archiviare questi dati non strutturati

Come hai detto, MongoDB è il più adatto per archiviare dati non strutturati. E questo può organizzare i tuoi dati in formato documento. Questi altenativi RDBMS chiamati archivi di dati NoSQL ( MongoDB , CouchDB , Voldemort ) sono molto utili per applicazioni che si ridimensionano in modo massiccio e richiedono un accesso più rapido ai dati da questi archivi di grandi quantità di dati.

E l'implementazione di questi database è più semplice del normale RDBMS. Dal momento che questi sono semplici oggetti binari con valori chiave o stile documento direttamente serializzati su disco. Questi archivi di dati non applicano le proprietà ACID e nessuno schema . Questo non fornisce alcuna capacità di transazione . Quindi questo può essere grande e possiamo ottenere un accesso più veloce (sia in lettura che in scrittura).

Al contrario, RDBM applica ACID e schemi sui dati. Se si desidera lavorare con dati strutturati, è possibile procedere con RDBM.

Sceglierei MySQL per creare forum per questo tipo di cose. Perché questo non ridimensionerà in grande. E questa è un'applicazione (comune) molto semplice che ha relazioni strutturate tra i dati.


10
"Vorrei scegliere mysql per creare forum in genere." Veramente? Penso che cose come i forum sarebbero molto più facili da scrivere usando un database orientato ai documenti piuttosto che un relazionale (se lo scrivessi da zero). Se non hai specificamente bisogno delle funzionalità di un RDBMS, direi di usare MongoDB o un database simile per facilità d'uso e ridimensionamento.
Sasha Chedygov,

2
CouchDB ha il supporto ACID. couchdb.apache.org/docs/overview.html
Sonia,

2018: MongoDB ha anche il supporto ACID
Nepoxx,

10

Si noti che Mongo essenzialmente memorizza JSON. Se la tua app ha a che fare con molti oggetti JS (con annidamento) e desideri persistere questi oggetti, c'è un argomento molto forte per usare Mongo. Rende i tuoi strati DAL e MVC ultra sottili, perché non disimballano tutte le proprietà degli oggetti JS e cercano di adattarli forzatamente in una struttura (schema) in cui non si adattano naturalmente.

Abbiamo un sistema che ha nel cuore diversi JS Objects complessi e adoriamo Mongo perché possiamo perseverare in modo molto, molto semplice. I nostri oggetti sono anche piuttosto amorfi e non strutturati, e Mongo assorbe quella complicazione senza battere ciglio. Abbiamo un livello di reporting personalizzato che decifra i dati amorfi per il consumo umano e che non è stato così difficile da sviluppare.


7

Direi che usa un RDBMS se hai bisogno di transazioni complesse. Altrimenti andrei con MongoDB - più flessibile con cui lavorare e sai che può ridimensionare quando è necessario. (Sono di parte però - lavoro sul progetto MongoDB)


7
Le transazioni complesse non funzionano in MongoDB, ma funzionano in altri database NoSQL, come MarkLogic (anche io sono distorto da quando eseguo la comunità di sviluppatori per MarkLogic).
Eric Bloch,

Grazie per il suggerimento a MarkLogic - non lo sapevo.
aurora

Mi piacerebbe sentirlo da mdirolf. Perché MongoDB ha scelto di non implementare le transazioni?
Aki,

7

Chi ha bisogno di forum distribuiti e precisi? Forse Facebook, ma a meno che tu non stia creando un concorrente di Facebook, usa Mysql, Postgres o qualsiasi altra cosa tu ti senta più a tuo agio. Se vuoi provare MongoDB, ok, ma non aspettarti che faccia magie per te. Avrà le sue stranezze e cattiveria generale, proprio come tutto il resto, poiché sono sicuro che hai già scoperto se ci hai già lavorato davvero.

Certo, MongoDB potrebbe essere pubblicizzato e sembrare facile in superficie, ma incontrerai problemi che i prodotti più maturi hanno già superato. Non essere attirato così facilmente, ma piuttosto aspetta fino a quando "nosql" matura o muore.

Personalmente, penso che "nosql" appassirà e morirà a causa della frammentazione, in quanto non esistono standard stabiliti (quasi per definizione). Quindi non ci scommetterò personalmente su alcun progetto a lungo termine.

L'unica cosa che può salvare "nosql" nel mio libro, è se può integrarsi perfettamente in Ruby o in linguaggi simili e rendere il linguaggio "persistente", quasi senza spese generali di programmazione e progettazione. Questo potrebbe accadere, ma aspetterò fino ad allora, non ora, E deve essere naturalmente più maturo.

A proposito, perché stai creando un forum da zero? Ci sono tonnellate di forum open source che possono essere modificati per soddisfare la maggior parte dei requisiti, a meno che tu non stia davvero creando The Next Generation of Forum (che dubito).


5
grazie per la tua risposta. l'integrazione di un forum è un disastro: l'abbiamo già fatto e abbiamo deciso di non procedere di nuovo in questo modo: non abbiamo bisogno di migliaia di funzionalità ma di una piena integrazione nel nostro software.
aurora

4

Ho visto che molte aziende utilizzano MongoDB per analisi in tempo reale dai registri delle applicazioni. La sua assenza di schema si adatta davvero ai registri delle applicazioni, dove lo schema dei record tende a cambiare di volta in volta. Inoltre, la sua funzione Capped Collection è utile perché elimina automaticamente i vecchi dati per mantenerli nella memoria.

Questa è un'area in cui penso davvero che MongoDB sia adatto, ma MySQL / PostgreSQL è più raccomandato in generale. Esistono molte documentazioni e risorse per gli sviluppatori sul Web, nonché la loro funzionalità e robustezza.


4

I 2 motivi principali per cui potresti voler preferire Mongo sono

  • Flessibilità nella progettazione dello schema (archivio documenti di tipo JSON).
  • Scalabilità: basta aggiungere nodi e può scalare abbastanza bene in orizzontale.

È adatto per applicazioni con big data. RDBMS non è buono per i big data.


3

Sai, tutta questa roba sui join e le "transazioni complesse" - ma è stato lo stesso Monty che, molti anni fa, ha spiegato il "bisogno" di COMMIT / ROLLBACK, dicendo che "tutto ciò che viene fatto nelle classi logiche (e non il database) ", quindi è sempre la stessa cosa. È necessario un motore di archiviazione / recupero dei dati stupido ma incredibilmente ordinato e veloce, per il 99% di ciò che fanno le app Web.


Grazie, stai sollevando un punto interessante qui. Sarei davvero interessato alla spiegazione di Monty, perché non sono sicuro di quanto i rollback complessi degli aggiornamenti su più tabelle entrino nella logica dell'applicazione pura - non sono sicuro, se questo è davvero possibile?
aurora

Non sono nemmeno sicuro del modo "migliore". Abbiamo sempre tenuto traccia di tutto ciò che è stato fatto sul DB, quindi lo consentiamo o lo annulliamo a livello di applicazione, nel codice. Non abbiamo mai fatto affidamento su transazioni, ovunque, mai. I documenti Mongo suggeriscono di utilizzare i metadati per tenere traccia di quali parti della transazione rollbackable si sono verificate, in quale stato si trova la transazione, nel caso in cui si interrompa e debba essere ripristinata. La cosa divertente è che lo avevamo già fatto insieme a MySQL e altri. Non è molto più lavoro e mantiene l'attenzione su cosa sta succedendo, quando, dove e perché, invece di black boxing.
FYA,

C'è una nota al riguardo sul sito Web 10gen da qualche parte ... che menziona come i campi "interblocco" o "cricchetti" vengono utilizzati manualmente per indicare lo stato di un processo in più passaggi. Mi sembra che se si esegue lo zoom nel motore MySQL stesso, la "transazione di blocco" si espande ancora in una serie di passaggi, non importa quale; è solo che gli interblocchi o i cricchetti vengono eseguiti in modo molto più piccolo e veloce rispetto al tracciamento manuale nei campi del database.
FYA

Dobbiamo ancora trovare un buon modo per limitare il demone MongoDB: divora quasi tutta la RAM disponibile per il suo indice e l'archiviazione dei dati in memoria, anche se produce rapidamente memoria quando altri proc ne hanno bisogno. Tuttavia, sarebbe bello avere un 'use_max_memory' o alcuni altri limiti facilmente definibili per assicurarsi che MongoDB non scappi e mandi il server in crash (lo abbiamo visto diverse volte, anche nella versione più recente). Almeno MySQL accetta tutti i tipi di limiti e suggerimenti operativi definibili.
FYA

Non direttamente correlato, ma in qualche modo: stavamo usando memcached ma ci siamo arresi a causa del fiasco del driver Memcache / Memcached PHP ancora irrisolto. Abbiamo usato MongoDB come chiave rapida e temporanea: val store (per il quale ha funzionato alla grande!) Fino a scoprire quanto è veloce e facile apc_store (). Se scopriamo che APC si sta riempiendo di greggio temporaneo (vs PHP precompilato memorizzato) che usavamo per memorizzare in memcached, torneremo a MongoDB per key: val storage.
FYA

1

Come detto in precedenza, puoi scegliere tra molte scelte, dare un'occhiata a tutte quelle scelte: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Quello che suggerisco è di trovare la migliore combinazione: MySQL + Memcache è davvero eccezionale se hai bisogno di ACID e vuoi unirti ad alcune tabelle MongoDB + Redis è perfetto per l'archivio documenti Neo4J è perfetto per il database dei grafici

Cosa faccio: inizio con MySQl + Memcache perché sono abituato, quindi inizio a utilizzare il framework di altri database. In un singolo progetto, ad esempio, puoi combinare MySQL e MongoDB!


MySQL + memcached ti darà l'eventuale coerenza. Che non considero ACID in un contesto RDMB.
R. van Twisk,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.