2012-05-08 15 views
8

Sono abituato a lavorare con mysql ma per la mia prossima serie di progetti CouchDB (NoSQL) sembra essere la strada da percorrere, fondamentalmente per evitare EAV in mysql e per abbracciare tutte le fantastiche funzionalità che ha da offrire .couchdb più database

Dopo molte ricerche e documentazione di lettura, ecc., C'è una cosa che non mi sembra di capire abbastanza bene.

Supponiamo di ospitare tre applicazioni Web sul mio server e di conseguenza ho bisogno di tre database di conseguenza. Ad esempio uno è un negozio online con tabelle di prodotti e fatture, uno è un blog con tabelle di articoli e commenti e un altro è un gioco basato sul web con tabelle di statistiche di gioco (semplificazione ovviamente).

Quindi io ospita più siti su un'installazione di mysql e ogni applicazione che eseguo sul mio server ottiene il proprio database con tabelle, campi e contenuto.

Ora, con CouchDb voglio fare la stessa identica cosa. Il problema sembra essere che la creazione di un database in CouchDb è più simile alla creazione di una tabella in mysql. Cioè Creo database chiamati "commenti", "articoli" ecc. Per il mio blog e all'interno creo un documento per articolo o un documento per commento.

Quindi la mia domanda è: come posso separare i miei dati da più applicazioni Web su un'installazione CouchDB?

Penso che sto facendo qualcosa di fondamentalmente sbagliato qui, ma spero che uno di voi ragazzi possa aiutarmi ad andare sulla buona strada.

risposta

6

In CouchDB, non è esplicitamente necessario separare i dati non correlati in più database. Se hai costruito correttamente i tuoi documenti e le tue visualizzazioni, solo i dati rilevanti verranno visualizzati nelle tue query.

Se si decide di separare i dati in database separati, è sufficiente creare un nuovo database.

$ curl -X PUT http://localhost:5984/somedb 
{"ok":true} 
+0

quindi se ho due applicazioni con dati-saggio alcuna relazione con l'altro, vorrei finire con due database separati giusto? ad esempio http: // localhost: 5984/webshop_for_client e http: // localhost: 5984/personal_blog –

+0

Corretto. Questi sono 2 database separati. – Chris

4

Dalla mia esperienza con CouchDB, separando i dati non correlati in diversi database è molto importante per le prestazioni e anche un gioco da ragazzi. La generazione della vista è una parte dolorosa di couchdb. Ogni volta che il database viene aggiornato, le viste (pensandole come indici in un tradizionale sql db relazionale) devono essere rigenerate. Ciò comporta l'iterazione di ogni documento nella banca dati . Quindi se hai scritto 2 milioni di documenti di tipo A e hai 300 documenti di tipo, B. E hai bisogno di rigenerare una vista delle query di tipo B, quindi tutte le 2 e 300 centinaia di enumerazioni verranno eseguite durante la generazione della vista e impiegherà molto tempo (potrebbe anche fare un timeout di lettura).

Pertanto, avere più database è un gioco da ragazzi quando si tratta di mantenere le viste (come si fa a query in couchdb, una caratteristica ovviamente importante e inevitabile) aggiornata.

+1

"Ogni volta che il database viene aggiornato" è un po 'fuorviante. Le viste non vengono rigenerate quando i documenti vengono aggiunti/aggiornati/cancellati - solo quando cambia la definizione delle viste, che dovrebbe essere rara. Le operazioni CRUD regolari aggiornano le visualizzazioni in modo incrementale. –

2

@Zombies ha perfettamente ragione sulle prestazioni. CouchDB non è adatto per eseguire su molti documenti in un singolo database. Se è necessario eseguire su, diciamo, più di 5000 documenti, lo standard MongoDB supererà CouchDB.

Le visualizzazioni in CouchDB sono essenziali, ma dolorose, con opzioni JavaScript limitate per creare query (non pensare nemmeno a riferimenti di documenti o oggetti nidificati). Considerare di avere database multipli per documenti diversi è piuttosto la soluzione.Alcune persone diranno qualcosa come:

CouchDB è un database NoSQL e, come tale, non è necessario ordinare i documenti né filtrarli utilizzando qualcosa di diverso dalle viste. NoSQL caratteristica principale del database è la capacità di memorizzare documenti schema-less [...]

E trovo molto fastidioso quando si necessità di trovare una soluzione per le prestazioni e interrogazione. Non dovresti preoccuparti di creare alcuni database per separare i tuoi dati se ti permette di dividere i tuoi dati, sarà comunque su un 'singola installazione CouchDB'. Non dimenticare che CouchDB è adatto per piccoli database . Il database più piccolo sarà, più veloce sarà la tua query, migliore sarà la performance.

(non so se ci sono errori in inglese, perdonatemi se è così)


EDIT Alcune aziende come ArangoDB fatto un confronto tra loro, MongoDB e CouchDB, e si conferma il mio modo di dire sul numero di documenti. Questo è il risultato:

Graphical comparison

Ci sono un sacco di altre risorse sul loro sito web. D'altra parte, questa affermazione è stata un'esperienza personale, e dal benchmarking per il mio tirocinio, con un software di benchmark .PHP che ho trovato su Internet. I risultati sono di seguito:

enter image description here

+0

"Se hai bisogno di esibirti su, diciamo, più di 5000 documenti, MongoDB supererà CouchDB." -> Questa è pura cazzata non intonata –

+1

-> https://www.arangodb.com/wp-content/uploads /2014/12/chart-overall-2.png Abbiamo anche fatto un benchmark, anche se non è disponibile su Internet (era per uno stage). Per favore dimostra il tuo punto, forse saremo in grado di discuterne, invece di essere aggressivi per praticamente nulla. Purtroppo non ci sono molti raffronti grafici tra Mongo e CouchDB, cosa che mi infastidisce. –