Sono un po 'confuso riguardo l'intera cosa NoSQL e così via. Quando sceglieresti di usare qualcosa come MongoDB su qualcosa come Oracle o MySQL? Non capisco davvero la "differenza" per quanto riguarda l'utilizzo tra di loro.
Dalla mia comprensione, i database di tipo NoSQL non sono pensati per sostituire gli RDBMS, ma cosa dovrebbero esattamente fare?
Ho usato CouchDB prima per tre progetti di animali domestici.
Il motivo principale per cui ho scelto questo tipo di MSSQL o MySQL è la flessibilità che si ottiene quando lo si utilizza. Nessun schema rigido. Se tre mesi dopo la linea hai bisogno di un certo tavolo per avere un campo in più, e questo e quello, lo cambi e uscirà fuori da lì.
Ho usato Beginning CouchDB di Apress per imparare come usarlo.
Ad esempio, CouchDB utilizza json per comunicare con / dal database. Se la tua lingua può inviare dati POST, puoi usarla per comunicare con il DB.
Leggi anche: Perché dovrei usare un database basato su documenti invece che relazionale database? su StackOverflow
Mi dispiace aggiungere un'altra risposta, ma nessuna delle risposte qui è molto soddisfacente. Questa risposta è specifica per MongoDB (al contrario della vasta gamma di altre opzioni di archiviazione dei dati che non sono database relazionali).
Pro:
Contro:
Punti spesso fraintesi:
Per rubare spudoratamente da Renesis (in realtà sto facendo questa risposta in CW):
Uso di RDBMS anziché di altri tipi:
Quando i tuoi dati non sono relazionali, ci possono essere grandi vantaggi nell'utilizzo di database NoSQL come prestazioni e scalabilità (a seconda delle circostanze, ovviamente). Alcuni pattern di progettazione come CQRS rendono molto più semplice sfruttare i dati non relazionali in aree che richiederebbero convenzionalmente l'uso esclusivo di un database SQL.
È normale utilizzare database come mongo per i dati memorizzati nella cache. Ad esempio, se è necessario generare un report, è possibile eseguire una query SQL complessa che unisce e aggrega un gruppo di dati al volo oppure è possibile recuperare un solo documento json dal database mongo che dispone già di tutto ciò che è necessario per generare il rapporto. Ciò rende la lettura dei dati davvero facile (e veloce!), Ma può rendere la scrittura dei dati piuttosto complicata (è qui che entra in gioco CQRS).
I database come MongoDB sono grandi quando di solito sai dove sono i tuoi dati (al contrario di dover scrivere parecchie query complicate). Con Mongo, i dati "correlati" sono nidificati nei dati principali o ha chiavi primarie / esterne. Questo è grandioso se, ad esempio, hai Post e Commenti; in generale, non verranno visualizzati commenti al di fuori del contesto di un post, quindi è logico che i commenti siano contenuti in un post (in questo modo si ottengono tutti i commenti per il post senza la necessità di eseguire una query in una tabella separata).
MongoDB è senza schemi. Ciò significa che prenderà la struttura dei dati che ci passi sopra, per la maggior parte.
D'altra parte, se hai bisogno di utilizzare funzioni aggregate e senti la necessità di interrogare i dati in modi complessi che non possono essere raggiunti tramite incorporamenti o semplici relazioni in Mongo, è quando sai che è ora di usare un RDBMS come MySQL o PostgreSQL.
MongoDB non è destinato a sostituire SQL. Semplicemente soddisfa diversi bisogni e MongoDB e un RDBMS possono essere usati insieme. Secondo me, MongoDB non è tutto ciò che è necessario se non hai bisogno che i tuoi dati siano flessibili o incorporati in un documento principale. Lo sviluppo con MongoDB è molto divertente perché ci sono molti meno passi necessari per ottenere un progetto (diciamo in Rails) attivo e funzionante. Hai bisogno di cambiare? Nessun problema. Basta aggiungere un attributo al tuo modello. Fatto.
Non posso parlare per molti altri database NoSQL, anche se so che di solito sono progettati in modo simile per soddisfare un bisogno specifico che non può essere soddisfatto da un RDBMS. Alcuni risiedono interamente nella memoria o sono in grado di essere ridimensionati o ridimensionati molto facilmente. Sono abbastanza sicuro che Cassandra è progettato per continuare a funzionare senza perdita di dati se un nodo si interrompe. Redis è fondamentalmente un archivio di valori chiave che risiede in memoria (con scritture periodiche del disco per la persistenza), ma ha anche la capacità di memorizzare tipi di dati come set e ordinarli.
La vittoria principale è quando si desidera suddividere i dati o disporre di database multi-master. È possibile suddividere i dati in MySQL ma si trasforma in un grande dolore. Se si stanno facendo molte scritture, è spesso utile dividere i dati tra più server, il problema è che se si vuole avere una consistenza referenziale strong mentre si fa questo può essere molto difficile se non impossibile cercare il teorema CAP.
I database SQL hanno una consistenza molto buona ma un supporto per il partizionamento davvero scadente, i database NoSQL tendono ad andare diversamente. Facile da suddividere ma spesso ciò che viene definito consistenza finale. Se stai costruendo un sito di messaggistica che è ok, per una banca probabilmente non è OK.
Il vantaggio è che ora ci sono più modelli su come archiviare i dati in modo da avere una scelta su come implementare le cose, mentre prima c'erano tutti i database SQL.
SE Radio ha avuto alcuni buoni episodi su questo argomento.
MongoDB funziona bene quando scrivi molti dati e quando le tue esigenze di interrogazione non sono troppo complicate. Pertanto, MongoDB è una buona idea quando stai implementando CQRS con Event Sourcing sul lato Command - cioè, il tuo archivio eventi è un database MongoDB.
Dal punto di vista delle query, utilizziamo ancora un db di SQL Server con viste e WCF Data Services in cima, grazie alla sua flessibilità. Penso che nella maggior parte dei casi avrai davvero bisogno della potenza di un DB relazionale per l'interrogazione.
La differenza immediata e fondamentale tra MongoDB e un RDBMS è il modello di dati sottostante. Un database relazionale struttura i dati in tabelle e righe, mentre MongoDB struttura i dati in raccolte di documenti JSON. JSON è un formato di dati leggibile e auto-descrittivo. Originariamente progettato per scambi leggeri tra browser e server, è diventato ampiamente accettato per molti tipi di applicazioni.
I documenti JSON sono particolarmente utili per la gestione dei dati per diversi motivi. Un documento JSON è composto da un insieme di campi che sono essi stessi coppie chiave-valore. Ciò significa che ogni documento JSON porta con sé il proprio schema di progettazione leggibile in modo leggibile ovunque, consentendo ai documenti di spostarsi facilmente tra le applicazioni database e client senza perdere il loro significato.
JSON è anche un formato di dati naturale da utilizzare nel livello dell'applicazione. JSON supporta una struttura dati più ricca e flessibile rispetto alle tabelle costituite da colonne e righe. Oltre a supportare tipi di campo come numero, stringa, booleano, ecc., I campi JSON possono essere matrici o oggetti secondari nidificati. Ciò significa che possiamo rappresentare un insieme di relazioni sofisticate che sono una rappresentazione più ravvicinata degli oggetti con cui le nostre applicazioni lavorano. Utilizzare i documenti JSON nel nostro database significa che non abbiamo bisogno di un mappatore relazionale di oggetti tra il nostro database e le applicazioni che serve. Possiamo mantenere i nostri dati nella forma corretta
Se i tuoi dati richiedono molte query, una soluzione NoSQL non è buona e quando hai bisogno del supporto transazionale (ACID), un NoSql non è la soluzione migliore. Penso che NoSQL brilli quando si hanno molte letture che devono essere veloci e quando la struttura è un po 'ad hoc, si recupera per documento o per struttura di pagina, qualcosa del genere. Ma un sacco di soluzioni NoSQL migliorano molto velocemente, quindi presto ci saranno carenze. Comunque penso che i database relazionali siano ancora adatti alla maggior parte delle applicazioni.