Ho bisogno di un consiglio su NoSQL / MongoDb e sulla struttura di dati / modelli
Domanda
Recentemente sto esplorando i database NoSQL. Ho bisogno di un consiglio su come archiviare i dati nel modo più ottimale ed efficiente per un determinato problema. Sto prendendo di mira MongoDB, ora. Tuttavia, dovrebbe essere lo stesso con CouchDB.
Diciamo che abbiamo questi 3 modelli:
Story:
id
title
User:
id
name
Vote:
id
story_id
user_id
Voglio essere in grado di porre al database queste domande:
- Chi ha votato per questa storia?
- Per cosa ha votato questo utente?
Sto facendo dei semplici join mentre lavoro con un DB relazionale. La domanda è: come devo archiviare i dati per quegli oggetti per essere più efficiente.
Ad esempio, se conservo gli oggetti Vote come sottocollection di Stories non sarà facile ottenere le informazioni - " Ciò per cui un utente ha votato " ;.
Soluzione
Suggerirei di memorizzare i voti come un elenco di storie _id
in ciascun utente. In questo modo puoi scoprire quali storie hanno votato un utente semplicemente guardando l'elenco. Per ottenere gli utenti che hanno votato per una storia, puoi fare qualcosa del tipo:
db.users.find ({stories: story_id})
dove story_id
è il _id
della storia in questione. Se crei un indice nel campo stories
entrambe le query saranno veloci.
Altri suggerimenti
- non preoccuparti se le tue query sono efficienti fino a quando non iniziano a importare
- secondo la citazione seguente, stai sbagliando
Il modo in cui ho seguito il il cambio di mente è dimenticare il database complessivamente. Nel mondo db relazionale che devi sempre preoccuparsi della normalizzazione dei dati e la struttura del tuo tavolo. Abbandona tutto. Basta layout la tua pagina web. Posali tutto fuori. Adesso guardali. Il tuo già 2/3 lì. Se dimentichi il l'idea che le dimensioni del database contino e i dati non dovrebbero essere duplicati dei tuoi 3/4 lì e non hai nemmeno dovuto scrivi qualsiasi codice! Lascia dettare le tue opinioni i tuoi modelli. Non devi prendere i tuoi oggetti e realizzali 2 più dimensionale come nel mondo relazionale. È possibile memorizzare oggetti con forma ora.
Ok, hai fornito un modello di dati normalizzato come faresti in una configurazione SQL.
Per quanto ne so, non lo fai in MongoDB. È possibile memorizzare riferimenti, ma non per motivi di prestazioni nel caso generale.
Non sono un esperto nell'area NoSQL in nessun modo, ma perché non segui semplicemente le tue esigenze e memorizzi l'utente (ID) che ha votato per una storia nella raccolta di storie e nella storia (ID) un utente ha votato nella raccolta utenti?
In CouchDB questo è molto semplice. Viene emessa una vista:
function(doc) {
if(doc.type == "vote") {
emit(doc.story_id, doc.user_id);
}
}
Viene emessa un'altra vista:
function(doc) {
if(doc.type == "vote") {
emit(doc.user_id, doc.story_id);
}
}
Entrambe sono query estremamente veloci poiché non esiste alcun join. Se hai bisogno di dati utente o dati della storia, CouchDB supporta il recupero di più documenti. Anche abbastanza veloce ed è un modo per fare un " join " ;.
Ultimamente ho esaminato MongoDB e CouchDB, ma la mia intuizione è limitata. Tuttavia, quando pensi di archiviare i voti all'interno del documento della storia, potresti doverti preoccupare di raggiungere il limite di dimensioni del documento di 4 MB. Anche se non lo fai, potresti aumentare costantemente le dimensioni del documento in modo da farlo spostare e rallentare così le tue scritture (vedi come le dimensioni dei documenti in MongoDB).
Per quanto riguarda CouchDB, questo tipo di cose sono abbastanza semplici, eleganti e abbastanza veloci una volta calcolati gli indici di visualizzazione. Personalmente, tuttavia, ho esitato a fare un progetto simile in CouchDB a causa dei benchmark che lo mostrano progressivamente rallentando in misura considerevole man mano che il database cresce (e gli indici di visualizzazione crescono). Mi piacerebbe vedere alcuni benchmark più recenti che mostrano le prestazioni di CouchDB all'aumentare delle dimensioni del database. VOGLIO provare MongoDB o CouchDB, ma SQL sembra ancora così efficiente e logico, quindi rimarrò con esso fino a quando il progetto si adatta alla tentazione giusta.