Ho usato per costruire applicazioni Ruby on Rails con MySQL.MongoDB vs MySQL
Attualmente MongoDB è diventato sempre più famoso e ora sto iniziando a provarlo.
Il problema è, non so la teoria alla base di come MongoDB sta lavorando (sto usando gemma mongoid se importa)
Così mi piacerebbe avere un confronto sulle prestazioni tra l'utilizzo di MySQL + ActiveRecord e il modello generato dalla gemma mongoidica, qualcuno potrebbe aiutarmi a capirlo?
L'articolo dal titolo: What the heck are you actually using NoSQL for? fa un ottimo lavoro nel presentare i pro e i contro dell'uso di NoSQL.
Edit: Anche a leggere http://blog.fatalmind.com/2011/05/13/choosing-nosql-for-the-right-reason/ post sul blog troppo
Re-edit: ho trovato un po 'di materiale recente (pubblicato nel 2014) su questo argomento che considero rilevanti: What’s left of NoSQL?
Non entra nei dettagli o nelle specifiche di quando utilizzare un'implementazione NoSQL rispetto all'altra, come suggerirebbe il titolo, tuttavia il caso è abbastanza buono. Non usare qualcosa solo perché è possibile o è l'ultima tendenza o parola d'ordine/termine/tecnologia. Forse lo strumento che hai funziona perfettamente, ma non lo stai usando bene. Come dice il proverbio: un cattivo operaio dà la colpa ai suoi strumenti. Ad ogni modo, la morale della storia è azzeccata. –
Come dice @MattSetter, non usare qualcosa solo perché è possibile o perché è di moda. Aggiungerò questo: la maggior parte dei dati non è fortemente relazionale o basata su documenti e MongoDB è molto semplice da scalare. – wprl
Non so molto della teoria sottostante. Ma questo è il consiglio che ho ricevuto: usa MongoDB solo se lo usi su più server; è allora che splenderà. Per quanto ho capito, il movimento NoSQL è apparso in non piccola parte a causa del dolore dei database relazionali di bilanciamento del carico su più server. Quindi, se stai ospitando la tua applicazione su non più di un server, MySQL sarebbe la scelta preferita.
Le persone buone sopra allo Doctrine project hanno recentemente scritto un utile blog post sull'argomento.
Esiste qualche funzione in MongoDB che lo rende più adatto a più server ? – PeterWong
Proprio come molte soluzioni di ricerca, MongoDB usa "sharding". È un modo per suddividere intervalli di dati su più server. Inoltre, poiché MongoDB è privo di molte delle funzionalità di integrità dei dati dei database relazionali, dovrebbe essere eseguito su non meno di due server (uno master e uno slave). http: //en.wikipedia.org/wiki/MongoDB – Henrik
I database relazionali supportano il sharding. Le soluzioni NoSQL non supportano le transazioni e spesso falliscono nei record di flussaggio sul disco. Buona fortuna nel loro utilizzo in cui la coerenza dei dati è un must. –
Da quello che ho letto finora ... ecco la mia opinione su di esso.
Lo standard SQL consente di ridurre le prestazioni per la ricchezza delle funzionalità ... cioè consente di eseguire join e transazioni tra set di dati (tabelle/raccolte, se lo si desidera) tra le altre cose.
Ciò consente a uno sviluppatore di applicazioni di trasferire parte della complessità dell'applicazione nel livello del database. Questo ha il vantaggio di non doversi preoccupare dell'integrità dei dati e del resto delle proprietà ACID da parte dell'applicazione, a seconda della tecnologia collaudata. La mancanza di scalabilità estrema funziona praticamente per tutti i progetti, a condizione che si riesca a mantenere l'applicazione funzionante entro i limiti di tempo previsti, il che a volte può comportare l'acquisto di sistemi di database relazionali ad alte prestazioni/costosi.
D'altra parte, Mongo DB, esclude deliberatamente gran parte della complessità intrinseca associata ai database relazionali, consentendo una migliore prestazione scalabile.
Questo approccio costringe lo sviluppatore dell'applicazione a ri-progettare l'applicazione per aggirare la mancanza di caratteristiche relazionali ... che in sé e per sé è una buona cosa, ma lo sforzo richiesto è in genere vale la pena se si dispone della scalabilità requisiti. Si noti che con MongoDB, in base ai requisiti dei dati con le proprietà ACID, l'applicazione dovrà essere potenziata e gestita secondo necessità.
Hai ragione in generale, ma vorrei sottolineare che Mongo è "per lo più" conforme ACID a livello di documento. Le unioni sono il diavolo. Entrambe le potenziali insidie sono rese meno problematiche pianificando la progettazione del database per evitare la necessità di unire o scrivere su più di un documento. La definizione dello schema viene eseguita nell'app, ma può essere eseguita utilizzando le librerie, quindi non è troppo diverso dalla definizione dei tuoi schemi in es. un file hibernate.xml (eccetto, come dici tu, che le definizioni dello schema sono applicate nell'app, non nel database). – wprl
È possibile trovare questo divertente e interessante da ascoltare http://www.xtranormal.com/watch/6995033/mongo-db-is-web-scale – dkroy