Quali sono i vantaggi dell'utilizzo di un database senza schema come MongoDB rispetto a un database relazionale?

Sono abituato a utilizzare database relazionali come MySQL o PostgreSQL e combinato con framework MVC come Symfony, RoR o Django e penso che funzioni alla grande.

Ma ultimamente ho sentito parlare molto di MongoDB che è un database non relazionale o, per citare la definizione ufficiale ,

un database scalabile, ad alte prestazioni, open source, privo di schemi e orientato ai documenti.

Sono davvero interessato ad essere al limite e voglio essere consapevole di tutte le opzioni che avrò per un prossimo progetto e scegliere le migliori tecnologie disponibili.

In quali casi usare MongoDB (o database simili) è meglio che usare un database relazionale "classico"? E quali sono i vantaggi di MongoDB rispetto a MySQL in generale? O almeno, perché è così diverso?

Se hai puntatori alla documentazione e / o agli esempi, sarebbe di grande aiuto anche.

Di seguito sono riportati alcuni dei vantaggi di MongoDB per la creazione di applicazioni web:

1. Un modello di dati basato su documenti. L'unità di archiviazione di base è analoga a JSON, dizionari Python, hash Ruby, ecc. Si tratta di una ricca struttura di dati in grado di contenere array e altri documenti. Ciò significa che spesso è possibile rappresentare in una singola entità un costrutto che richiederebbe diverse tabelle per rappresentare correttamente in un database relazionale. Ciò è particolarmente utile se i tuoi dati non sono modificabili.
2. Capacità di interrogazione profonda. MongoDB supporta le query dinamiche sui documenti utilizzando un linguaggio di query basato sui documenti potente quasi quanto SQL.
3. Nessuna migrazione dello schema. Poiché MongoDB è privo di schema, il codice definisce lo schema.
4. Un percorso chiaro verso la scalabilità orizzontale.

Avrai bisogno di saperne di più e di giocarci per avere un'idea migliore. Ecco una demo online:

http://try.mongodb.org/

Ci sono numerosi vantaggi.

Ad esempio lo schema del tuo database sarà più scalabile, non dovrai preoccuparti delle migrazioni, il codice sarà più piacevole da scrivere ... Ad esempio, ecco uno dei codici del mio modello:

class Setting
  include MongoMapper::Document

  key :news_search, String, :required => true
  key :is_availaible_for_iphone, :required => true, :default => false

  belongs_to :movie
end

Aggiungere una chiave significa semplicemente aggiungere una riga di codice!

Ci sono anche altri vantaggi che appariranno a lungo termine, come una migliore scalabilità e velocità.

... Ma tieni presente che un database non relazionale non è migliore di uno relazionale . Se il tuo database ha molte relazioni e normalizzazioni, potrebbe avere poco senso usare qualcosa come MongoDB. Si tratta di trovare lo strumento giusto per il lavoro.

Per ulteriori informazioni, consiglio di dare un'occhiata a " Perché penso che Mongo stia per i database quello che Rails era per Frameworks " o questo post sul sito web di mongodb. Per emozionarti e se parli francese, dai un'occhiata a questo articolo spiega come configurare MongoDB da zero.

Modifica: mi sono quasi dimenticato di parlarti di questo railscast di Ryan . È molto interessante e ti fa venire voglia di iniziare subito!

Il vantaggio dello schema-free è che puoi scaricare qualunque sia il tuo carico e nessuno avrà mai motivo di lamentarsene o di dire che era sbagliato.

Significa anche che qualunque cosa ci metti dentro, rimane totalmente priva di significato dopo che lo hai fatto.

Alcuni lo definirebbero un grave svantaggio, altri no.

Il fatto che un database relazionale abbia uno schema consolidato, è una conseguenza del fatto che ha un insieme ben definito di predicati estensionali, che sono ciò che ci permette di attribuire significato a ciò che è registrato nel database, e che sono anche un prerequisito necessario per noi per farlo.

Senza uno schema ben stabilito, senza predicati estensionali e senza precicati estensionali, non c'è modo per l'utente di ricavare un significato da ciò che è stato infilato in esso.

MongoDB è stato presentato su FLOSS Weekly questa settimana - http://twit.tv/floss105 Un database che utilizza un concetto simile è CouchDB che è stato presentato su un altro FLOSS Weekly: http://twit.tv/floss36

Penso che valga la pena ascoltare quelli oltre ai link forniti da @marcgg

La mia esperienza con Postgres e Mongo dopo aver lavorato con entrambi i database nei miei progetti.

Postgres (RDBMS)

Postgres è consigliato se le tue applicazioni future hanno uno schema complicato che richiede molti join o tutti i dati hanno relazioni o se abbiamo una scrittura pesante. Postgres è open source, più veloce, conforme ad ACID e utilizza meno memoria su disco, offre ottime prestazioni anche per l'archiviazione JSON e include la completa serializzabilità delle transazioni con 3 livelli di isolamento delle transazioni.

Il più grande vantaggio di restare con Postgres è che abbiamo il meglio di entrambi i mondi. Possiamo memorizzare i dati in JSONB con vincoli, coerenza e velocità. D'altra parte, possiamo usare tutte le funzionalità SQL per altri tipi di dati. Il motore sottostante è molto stabile e gestisce bene una buona gamma di volumi di dati. Funziona anche su hardware e sistema operativo a tua scelta. Postgres fornisce funzionalità NoSQL insieme al supporto completo delle transazioni, archiviando documenti JSON con vincoli sui dati dei campi.

Vincoli generali per Postgres

Scalare Postgres orizzontalmente è significativamente più difficile, ma fattibile.

Le operazioni di lettura rapida non possono essere eseguite completamente con Postgres.

NESSUN database SQL

Mongo DB (Wired Tiger)

MongoDB può battere Postgres in una dimensione di "scala orizzontale". L'archiviazione di JSON è ciò per cui Mongo è ottimizzato. Mongo memorizza i suoi dati in un formato binario chiamato BSONb che è (approssimativamente) solo una rappresentazione binaria di un superset di JSON. MongoDB memorizza gli oggetti esattamente come sono stati progettati. Secondo MongoDB, per le applicazioni ad alta intensità di scrittura, Mongo afferma che il nuovo motore (Wired Tiger) offre agli utenti un aumento fino a 10 volte delle prestazioni di scrittura (dovrei provare questo), con una riduzione dell'80% dell'utilizzo dello storage, contribuendo a ridurre i costi di archiviazione , ottenere un maggiore utilizzo dell'hardware.

Vincoli generali di MongoDb

L'utilizzo di un motore di archiviazione senza schema porta al problema degli schemi impliciti. Questi schemi non sono definiti dal nostro motore di archiviazione, ma sono invece definiti in base al comportamento e alle aspettative dell'applicazione.

Le tecnologie NoSQL autonome non soddisfano gli standard ACID perché sacrificano la protezione dei dati critici a favore di prestazioni ad alto throughput per applicazioni non strutturate. Non è difficile applicare ACID su database NoSQL, ma renderebbe il database lento e inflessibile fino a un certo punto. "La maggior parte delle limitazioni di NoSQL sono state ottimizzate nelle versioni e nei rilasci più recenti che hanno superato in larga misura i limiti precedenti".

Si tratta di compromessi. MongoDB è veloce ma non ACID, non ha transazioni. È migliore di MySQL in alcuni casi d'uso e peggiore in altri.

Linee qui sotto scritte in MongoDB: The Definitive Guide.

Ci sono diversi buoni motivi:

1. Mantenere diversi tipi di documenti nella stessa raccolta può essere un incubo per sviluppatori e amministratori. Gli sviluppatori devono assicurarsi che ogni query restituisca solo documenti di un certo tipo o che il codice dell'applicazione che esegue una query possa gestire documenti di forme diverse. Se stiamo cercando i post del blog, è una seccatura eliminare i documenti contenenti i dati dell'autore.
2. È molto più veloce ottenere un elenco di raccolte che estrarre un elenco dei tipi in una raccolta. Ad esempio, se avessimo una chiave di tipo nella raccolta che dicesse se ogni documento è un documento "scremato", "intero" o "scimmia grosso", sarebbe molto più lento trovare quei tre valori in una singola raccolta rispetto a hanno tre raccolte separate e chiedi i loro nomi
3. Il raggruppamento di documenti dello stesso tipo nella stessa raccolta consente la località dei dati. Ottenere diversi post di blog da una raccolta contenente solo post richiederà probabilmente meno ricerche su disco rispetto a ottenere gli stessi post da una raccolta contenente post e dati dell'autore.
4. Iniziamo a imporre una struttura ai nostri documenti quando creiamo gli indici. (Ciò è particolarmente vero nel caso di indici univoci.) Questi indici sono definiti per raccolta. Inserendo solo documenti di un singolo tipo nella stessa raccolta, possiamo indicizzare le nostre raccolte in modo più efficiente

Dopo una questione di database con archiviazione testuale), ho dato un'occhiata a MongoDB e sistemi simili.
Se ho capito bene, dovrebbero essere più facili da usare e configurare e molto più veloci. Forse anche più sicuro in quanto la mancanza di SQL impedisce l'iniezione di SQL ...
Apparentemente, MongoDB viene utilizzato principalmente per le applicazioni Web.
Fondamentalmente, e affermano che essi stessi, questi database non sono adatti per query complesse, data mining, ecc. Ma brillano nel recuperare rapidamente molti dati flat.

1. MongoDB supporta la ricerca per campi, ricerche di espressioni regolari. Include funzioni di script java definite dall'utente.
2. MongoDB può essere utilizzato come file system, sfruttando le funzionalità di bilanciamento del carico e replica dei dati su più macchine per l'archiviazione dei file.