Ho bisogno di un consiglio su NoSQL / MongoDb e sulla struttura di dati / modelli

Question

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 " ;.

Answer 1

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.

Answer 2

• 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.

how-to-think-in-data-store -invece-di-database

Answer 3

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?

Answer 4

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 " ;.

Answer 5

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.