Pro/contro di MongoDB o MySQL a questo scopo

Question

Sto cercando un po 'di aiuto o guida su quale database utilizzare per un progetto. Se puoi sollevare punti, o annotare difetti, rispondere a qualsiasi domanda o promuovere il tipo di database per lo scopo che sto per pronunciare, lo apprezzerei molto.

In ogni modo:

• Abbiamo alcuni software che tiene traccia le forme.

• Abbiamo utenti che possono avere MOLTE proprietà diverse, letteralmente centinaia di impostazioni e io non sono un fan delle tabelle MySQL così ampie. I mi piace molto Mongo per questo.

• Abbiamo diversi tipi di moduli, ognuno dei quali può avere campi completamente diversi. Al momento, abbiamo un elenco di moduli con dati generici, quindi entra nella tabella pertinente per ulteriori dati. Avrei tutti i campi in un documento distinto con Mongo, e potrei facilmente aggiungere campi senza preoccuparmi.

• Abbiamo costi, note, cronologia su ogni modulo. Mi piace come in MySQL siano in una tabella diversa, e posso ottenere la cronologia per modulo o per utente - come per le note.

• La nostra politica è praticamente TUTTI i dati, anche cancellati o pre-modificati dati ... per sempre. Dovrei essere preoccupato di raggiungere un limite di dimensioni? Probabilmente parliamo di 100 GB entro la fine del 2013

• Quante query Mongo per pagina si bloccheranno? 20? 100? cambierebbe se avessi un SSD nel server? (In questo momento, abbiamo circa 60 MySQL interroga una pagina. Questo può essere migliorato.)

• E 'una cattiva idea per il mio primo progetto Mongo per essere un po' importante po 'di software? È qualcosa che posso imparare mentre vado?

• Mi piace l'insensibilità del case dei nomi delle colonne MySQL per le cose sporche e sporche.

• In MySQL, suddivido le cose in tabelle diverse. Va bene, in Mongo, mettere insieme i dati che possono essere separati? Esempio: username, email, phone, license1 => [num,isValid], license2 => [num, isValid], notifications => [notification1...notification50000], password hash, salt, setting1, setting2...setting1000, permission1, permission2...permission1000 Ovviamente, utilizzerei lo stile nidificato per organizzarlo, ma è meglio memorizzare tutto questo sotto "utente" o estrapolarlo a impostazioni, licenze, permessi? Secondo esempio: formName, address, notes => [note1 => [user,note,date], note2 => [user,note,date]]

• C'è qualche problema con l'esecuzione di una configurazione HYBRID, dove i dati utente sono Mongo e i dati di modulo sono in MySQL?

• Dobbiamo eseguire molti rapporti, ci sono limitazioni su questo in Mongo? Per esempio, dovrei incorrere in problemi alla ricerca di ogni modulo degli ultimi 40 giorni con una commissione superiore a $ 10, con le commissioni in ogni riga totalizzate, ordinate in base all'età dell'utente che l'ha compilato?

• Ridondanza dei dati - Sul cloud Amazon, MySQL ha MASSIVE quantità di ridondanza. C'è qualche servizio per abbinarlo a Mongo? E 'complesso entrare a farmi da solo?

• MongoDB è supportato da qualsiasi provider "cloud"? AWS fa molto per MySQL, ma sembra che sarei da solo per Mongo

solo alcune cose al largo della parte superiore della mia testa - ho davvero apprezzato tutto ciò qualcuno ha da dire.

Answer 1

Abbiamo utenti che possono avere MOLTE proprietà diverse, letteralmente centinaia di impostazioni e io non sono un fan delle tabelle MySQL così ampie. I mi piace molto Mongo per questo.

Abbiamo diversi tipi di moduli, ognuno può avere completamente campi diversi. Al momento, disponiamo di un elenco di moduli con dati generici , quindi aggiungiamo la tabella pertinente per ulteriori dati. Avrei tutti questi campi in un documento distinto con Mongo e potrei facilmente aggiungere campi senza preoccuparmi.

Dal tuo post capisco che il tuo obiettivo finale è quello di gestire gli utenti & moduli che contengono schemi diversi (ovvero schemi). Credo che mongodb sia una scelta giusta per questo scopo.

Abbiamo commissioni, note, cronologia su ogni modulo. Mi piace come in MySQL siano in una tabella diversa, e posso ottenere la cronologia per modulo o per utente - come per le note.

Nessun problema, è possibile utilizzare diversi documenti (o documenti incorporati in base alla dimensione di esso - 16 mb è la dimensione massima del documento) per gestire questo senza problemi. in modo da avere lo schema come

Form 
    - form field1 
    - form field1 
    - id of the fees doc 
    - id of the notes doc 
    - id of the history doc 

o (per documenti incorporati)

Form 
    - form field1 
    - form field2 
    - embedded fees doc 
      - fees field1 
      - fees field2 
    - embedded notes doc 
      - notes field1 
      - notes field2 

La nostra politica è praticamente mantenere tutti i dati, anche i dati cancellati o pre-editati ... per sempre. > Dovrei essere preoccupato di raggiungere un limite di dimensioni? Probabilmente stiamo parlando 100GB entro la fine del> 2013

Sarà memorizzare quanto i dati si farebbe, già ci sono production deployments memorizzazione dati su terabyte.

È una cattiva idea che il mio primo progetto Mongo sia un po 'importante di software? È qualcosa che posso imparare mentre vado?

Sì, se si sta utilizzando mongodb senza prototipazione del modello di applicazione. Vorrei raccomandare di implementare (prototipo) un set minimo della tua app (come le funzionalità che fanno schifo in mysql) e imparare le basi e vedere quanto sei comodo.

Mi piace l'insensibilità del case dei nomi delle colonne MySQL per cose veloci e sporche.

Mongo applica la distinzione tra maiuscole e minuscole perché è una coppia di valori chiave BSON (come pure JSON).

In MySQL, suddivido le cose in tabelle diverse. Va bene, in Mongo, per mettere insieme i dati che possono essere separati? Esempio: nome utente, e-mail, telefono, license1 => [num, isValid],

principale vantaggio di Mongo su altri archivio dati SQL è, è possibile memorizzare il maggior numero di informazioni rilevanti all'interno dello stesso documento (all'interno del 16 mb size). Se non si è sicuri della dimensione o alcune parti dei dati sono in crescita, è possibile dividere la parte in un'altra. Dato che sei preoccupato del no delle query, ridurrà drasticamente il numero di richieste.

non c'è alcun problema con il fare una messa a punto HYBRID, in cui i dati utente è Mongo, e dati dei moduli è in MySQL?

No assolutamente no, in effetti sto eseguendo mongodb insieme a mysql (solo per le transazioni). Ma se non si gestiscono transazioni, è possibile utilizzare mongodb.

Noi ci dobbiamo correre un sacco di rapporti, sono limitazioni su questo in Mongo? Ad esempio, dovrei incorrere in problemi cercando ogni modulo negli ultimi 40 giorni con una commissione superiore a $ 10, con le commissioni in ogni riga totalizzate, ordinate in base all'età dell'utente che lo ha compilato?

No, non vedo alcuna limitazione in questo. In effetti le sue query di gestione molto veloce con gli indici adeguati. Ma ci sono alcune cose che non puoi fare con mongo come normali join, invece puoi usare map/reduce per gestire i dati per i report.

MongoDB è supportato da qualsiasi provider "cloud"? AWS fa molto per MySQL, ma sembra che sarei da solo per Mongo

Mongohq, Mongolab sono alcuni dei mongo gestito dedicato servizi di hosting disponibili. Anche RedHat OpenShift & vmware cloundfoundry fornisce le piattaforme di hosting per mongo, è possibile controllare la mongo hosting center per ulteriori informazioni

Spero che questo aiuti

Answer 2

Ecco alcune informazioni sul MongoDB nel cloud: http://www.mongodb.org/display/DOCS/Hosting+Center

Answer 3

è possibile utilizzare sia MongoDB o MySQL per quello che si vuole. La cosa principale da tenere presente è il ridimensionamento. In MySQL si scala verticalmente. Ottieni una macchina più grande, una macchina migliore. E spero che faccia la differenza. In MongoDB ridimensiona orizzontalmente. Hai più macchine e shard. Il ridimensionamento verticale ha un limite. Ma il ridimensionamento orizzontale no. In termini di ridimensionamento dei costi in verticale è facile da capire. Il ridimensionamento orizzontale di solito porta all'acquisto di un gruppo di macchine, quindi quando si desidera ridimensionare ulteriormente diventa esponenziale. Quindi è qualcosa che devi considerare.

Fare query statistiche è uno svantaggio di MongoDB. Per alcuni motivi. Prima di tutto ci saranno le funzionalità di MySQL che non avrai in MongoDB. In secondo luogo, per chiunque sia più di una persona con DB e abbia familiarità con le istruzioni SQL, potrebbe avere davvero difficoltà ad adattarsi alla sintassi di MongoDB. È qualcosa di nuovo da imparare. E alle persone piace spesso (e funziona bene) quello che sanno.

Come la maggior parte delle altre piattaforme 'NoSQL', MongoDB non utilizza ACID, il che gli conferisce un po 'di prestazioni. Ma questo significa che potrebbe essere più rischioso.

Esistono alcune soluzioni basate su cloud. Dai un'occhiata a MongoHQ e MongoLab. Potrei sbagliarmi, ma non credo che abbiano SSD. Sono tutti fusi. Ma ping il loro supporto. Di solito rispondono velocemente.

Nella mia esperienza MongoDB è veloce. Molto veloce. MySQL è lento quando hai tabelle grandi, join, ecc. E puoi indicizzare in MongoDB, come ti aspetteresti. Ho visto che se indicizzi troppe cose, o cose come gli array in cui deve indicizzare ogni elemento, allora può essere più tassativo per transazione.

Non vorrei spingerti in nessuna direzione. È qualcosa che richiede qualche ricerca. Non direi che usare MongoDB è una cattiva idea per un progetto così grande, ma ci vorrà del tempo per capire se funziona per la tua situazione. Come con tutte le cose.

Esistono alcune alternative, in particolare estensioni proprietarie a MySQL che possono darvi un grande incremento di prestazioni (a seconda della configurazione, del tipo medio di transazioni, ecc.). Uno che viene in mente è InfoBright, ma questi sono spesso costosi.