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

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?

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

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.

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.

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.

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)

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).

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.

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.

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.

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!