Utilizzando MongoDB vs MySQL con molti campi JSON?

Question

Esiste un tipo di applicazione di microblogging. Due principali database di base su cui è stato eseguito l'azzeramento sono: MySQL o MongoDB.

Ho intenzione di denormalizzare molti dati I.e. Un voto fatto su un post viene memorizzato in una tabella di votazione, inoltre viene incrementato un conteggio nella tabella principale dei post. Ci sono anche altre azioni coinvolte nel post (ad esempio, votare giù).

Se utilizzo MySQL, alcuni dati si adattano meglio a JSON che a schema fisso, per ricerche più veloci.

E.g.

POST_ID | activity_data 

213423424 | { 'likes': {'count':213,'recent_likers' : 
      ['john','jack',..fixed list of recent N users]} , 'smiles' : 
      {'count':345,'recent_smilers' : 
      ['mary','jack',..fixed list of recent N users]} } 

Esistono anche altri componenti dell'applicazione, in cui viene proposto l'utilizzo di JSON. Così, per aggiornare un campo JSON, la sequenza è:

1. Leggere il JSON in script python.

2. Aggiornare il JSON

3. Conservare il JSON di nuovo in MySQL.

Sarebbe stato singola operazione in MongoDB con operazioni atomiche come $push, $inc, $pull ecc Inoltre struttura del documento di MongoDB adatta bene i miei dati.

Le mie considerazioni durante la scelta dell'archivio dati.

Per quanto riguarda MySQL:

1. Stabile e familiare.
2. Il backup e il ripristino sono facili.
3. Alcune modifiche future dello schema possono essere evitate utilizzando alcuni campi come schemi JSON.
4. Potrebbe essere necessario utilizzare il livello di memcache all'inizio.
5. I BLOB JSON saranno statici in alcune tabelle come i messaggi principali, tuttavia verranno aggiornati molto in alcune altre tabelle come i voti Post e i Mi piace.

Per quanto riguarda MongoDB:

1. più adatto per memorizzare lo schema meno dati come documenti.
2. Il caching potrebbe essere evitato fino a una fase successiva.
3. A volte l'applicazione può diventare intensiva in scrittura, MongoDB può funzionare meglio in quei punti in cui le scritture non sicure non rappresentano un problema.
4. Non sicuro di stabilità e affidabilità.
5. Non sono sicuro di quanto sia facile eseguire il backup e il ripristino.

Domande:

1. Shall abbiamo scelto MongoDB se la metà dei dati è schemaless, e viene memorizzata come JSON se si utilizza MySQL?

2. Alcuni dei dati come i messaggi principali sono fondamentali, quindi verranno salvati utilizzando scritture sicure, i contatori ecc. verranno salvati utilizzando scritture non sicure. Questa politica è basata sull'importanza dei dati e l'intensità di scrittura è corretta?

3. Quanto è facile monitorare, eseguire il backup e ripristinare MongoDB rispetto a MySQL? Abbiamo bisogno di pianificare backup periodici (diciamo ogni giorno) e ripristinarli con facilità in caso di disastro. Quali sono le migliori opzioni che ho con MongoDB per renderlo una scommessa sicura per l'applicazione.

di stabilità, di backup, snapshot, il ripristino, più ampia adozione I.e.database durata nel tempo sono le ragioni mi puntano di utilizzare MySQL come RDBMS + NoSQL anche se un documento di archiviazione NoSQL potrebbe servire il mio scopo meglio.

Si prega di concentrare le proprie opinioni sulla scelta tra MySQL e MongoDB considerando il design del database che ho in mente. So che potrebbero esserci modi migliori per pianificare la progettazione del database con documenti RDBMS o MongoDB. Ma questo non è l'obiettivo attuale della mia domanda.

UPDATE: da MySQL 5.7 in poi, MySQL supporta una ricca nativo JSON tipo di dati che fornisce la flessibilità dei dati, nonché ricca interrogazione JSON.

https://dev.mysql.com/doc/refman/5.7/en/json.html

Answer 1

Quindi, per rispondere direttamente alle domande ...

Shall abbiamo scelto mongodb se la metà dei dati è schemaless, e viene memorizzato come JSON se si utilizza MySQL?

Lo storage di schema è certamente un motivo valido per andare con MongoDB, ma come hai fatto notare, è abbastanza facile memorizzare JSON in un RDBMS. Il potere dietro MongoDB è nelle query avanzate contro lo storage di schemi.

Se si può evidenziare un piccolo difetto nell'illustrazione sull'aggiornamento di un campo JSON, non si tratta semplicemente di ottenere il valore corrente, aggiornare il documento e quindi reinserirlo nel database. Il processo deve essere tutto racchiuso in una transazione. Le transazioni tendono ad essere abbastanza semplici, fino a quando non si avvia denormalizzazione del database. Quindi qualcosa di semplice come registrare un upvote può bloccare le tabelle su tutto lo schema.

Con MongoDB, non ci sono transazioni. Ma le operazioni possono essere quasi sempre strutturate in modo da consentire aggiornamenti atomici. Questo di solito comporta alcuni cambiamenti drammatici dai paradigmi SQL, ma a mio parere sono abbastanza evidenti quando si smette di cercare di forzare gli oggetti nelle tabelle. Per lo meno, molte altre persone hanno incontrato gli stessi problemi che affronterete e la comunità di Mongo tende ad essere abbastanza aperta e vocale riguardo alle sfide che ha superato.

Alcuni dei dati come i messaggi principali sono fondamentali, quindi verranno salvati utilizzando scritture sicure, i contatori ecc saranno salvati utilizzando scritture non sicure. Questa politica è basata sull'importanza dei dati e l'intensità di scrittura è corretta?

Per "scritture sicure" presumo intendete l'opzione per attivare un "getLastError()" automatico dopo ogni scrittura. Abbiamo un involucro molto sottile su un DBCollection che ci consente un controllo a grana fine su quando viene chiamato getLastError(). Tuttavia, la nostra politica non si basa sul modo in cui i dati "importanti" sono, ma piuttosto sul fatto che il codice che segue la query si aspetti che eventuali modifiche siano immediatamente visibili nelle letture seguenti.

In generale, questo è ancora un indicatore scarso, e abbiamo invece migrato a findAndModify() per lo stesso comportamento. Nell'occasione in cui ancora chiamiamo esplicitamente getLastError() è quando il database rischia di rifiutare una scrittura, come quando inseriamo() con un _id che può essere un duplicato.

Quanto è facile monitorare, eseguire il backup e ripristinare Mongodb rispetto a mysql? Abbiamo bisogno di pianificare backup periodici (diciamo ogni giorno) e ripristinarli con facilità in caso di disastro. Quali sono le migliori opzioni che ho con mongoDb per fare una scommessa sicura per l'applicazione?

Temo di non poter dire se la nostra politica di backup/ripristino sia efficace poiché non abbiamo ancora dovuto ripristinare. Stiamo seguendo i consigli MongoDB per il backup; @ mark-hillick ha fatto un ottimo lavoro nel riassumere quelli. Utilizziamo i set di repliche e abbiamo migrato le versioni di MongoDB e abbiamo introdotto nuovi membri di replica. Finora non abbiamo avuto tempi morti, quindi non sono sicuro di poter parlare bene fino a questo punto.

Stabilità, backup, istantanee, ripristino, adozione più ampia, ad es.la durabilità del database sono le ragioni che mi inducono a usare MySQL come RDBMS + NoSql anche se un archivio di documenti NoSQL può servire meglio al mio scopo.

Così, nella mia esperienza, MongoDB offre archiviazione di dati di schemi con un set di primitive di query abbastanza ricco che spesso le transazioni possono essere sostituite da operazioni atomiche. È stato difficile disimparare oltre 10 anni di esperienza SQL, ma ogni problema che ho riscontrato è stato affrontato direttamente dalla community o da 10gen. Non abbiamo perso dati o avuto tempi morti che posso ricordare.

Per dirla semplicemente, MongoDB è senza dubbio il miglior ecosistema di archiviazione dati che abbia mai utilizzato in termini di query, manutenzione, scalabilità e affidabilità. A meno che non avessi un'applicazione così chiaramente relazionale che non potrei in coscienza usare qualcosa di diverso da SQL, farei ogni sforzo per usare MongoDB.

Non lavoro per 10gen, ma sono molto grato per le persone che lo fanno.

Answer 2

Non ho intenzione di commentare i confronti (io lavoro per 10gen e non lo sento è appropriato per me di farlo), tuttavia, risponderò alle domande MongoDB specifiche in modo da puoi prendere meglio la tua decisione.

Back-Up

documentazione here è molto accurata, che copre molti aspetti:

• a livello di blocco Metodi (LVM rende molto facile e un sacco di gente fare questo)
• Con/senza inserimento nel diario
• Istantanee EBS
• Istantanee generali
• Replication (tecnicamente non back-up, tuttavia, un sacco di uso popolare set di repliche per la loro ridondanza e di back-up - non raccomandare questo ma è fatto)

Fino a poco tempo, non v'è alcun MongoDB equivalente di mylvmbackup ma un bel ragazzo ha scritto uno :) Nelle sue parole

primi giorni finora: è solo uno script di shell glorificato e ha bisogno di molto più controllo degli errori. Ma già funziona per me e ho pensato di condividere la gioia. Segnalazioni di errori, patch & suggerimenti benvenuti.

Fatevi una copia da here.

Ripristina

• Formats etc

mongodump è completamente documentato e here mongorestore è here.

mongodump non conterrà gli indici ma contiene la raccolta system.indexes in modo che mongorestore possa ricostruire gli indici quando si ripristina il file bson. Il file BSON sono i dati effettivi mentre mongoexport/mongoimport non sono type-safe in modo che potrebbe essere qualsiasi cosa (techically parlando) :)

Monitoraggio

documentata here.

Mi piace Cacti ma afaik, i modelli Cacti non hanno tenuto il passo con i cambiamenti in MongoDB e quindi si affidano alla vecchia sintassi in modo tale da postare 2.0.4, credo che ci siano problemi.

Nagios funziona bene ma è Nagios quindi lo ami o lo odi. Un sacco di gente usa Nagios e sembra offrire loro una grande visibilità.

Ho sentito parlare di alcune persone che guardano Zappix ma non l'ho mai usato quindi non posso commentare.

Inoltre, è possibile utilizzare MMS, che è gratuito e ospitato esternamente. Le istanze di MongoDB eseguono un agente e uno di questi agenti comunica (usando il codice Python) su https su mms.10gen.com. Utilizziamo MMS per visualizzare tutte le statistiche sulle prestazioni nelle istanze di MongoDB ed è molto vantaggioso da una vista panoramica di alto livello, oltre a offrire la possibilità di eseguire il drill-down. È semplice da installare e non è necessario eseguire alcun hardware per questo. Molti clienti lo gestiscono e alcuni lo completano con Cacti/Nagios.

È possibile trovare informazioni sulla guida su MMS here (è un documento molto dettagliato e completo).

Answer 3

Uno degli svantaggi di una soluzione mysql con json memorizzato è che non sarà possibile cercare in modo efficiente i dati JSON. Se lo memorizzi tutto in mongodb, puoi creare indici e/o query su tutti i tuoi dati incluso il json.

Le scritture di Mongo funzionano molto bene, e l'unica cosa che si perde contro mysql è il supporto delle transazioni, e quindi la possibilità di effettuare il rollback di salvataggi multipart. Tuttavia, se sei in grado di commettere le tue modifiche nelle operazioni atomiche, allora non c'è un problema di sicurezza dei dati. Se sei replicato, mongo fornisce una promessa "alla fine coerente" in modo tale che gli schiavi alla fine rispecchino il master.

Mongodb non fornisce l'imposizione nativa o il collegamento in cascata di alcuni costrutti db come chiavi esterne, quindi è necessario gestirli autonomamente (ad esempio attraverso la composizione, che è uno dei punti di forza di mongo) o tramite l'uso di dbrefs.

Se si ha realmente bisogno di supporto per le transazioni e di scritture "sicure" solide, ma si desidera ancora la flessibilità fornita da nosql, si potrebbe considerare una soluzione ibrida. Questo ti permetterebbe di usare mysql come archivio principale dei tuoi post, e quindi usare mongodb come il tuo negozio di 'schemaless'.Ecco un collegamento a un documento che discute soluzioni ibride mongo/rdbms: http://www.10gen.com/events/hybrid-applications L'articolo proviene dal sito di 10gen, ma puoi trovare altri esempi semplicemente facendo una rapida ricerca su google.