Preciso de um conselho sobre o NoSQL/MongoDB e a estrutura de dados/modelos

Question

Recentemente, estou explorando bancos de dados NoSQL. Preciso de um conselho sobre como armazenar dados da maneira mais ideal e eficiente para um determinado problema. Estou mirando o MongoDB, agora. No entanto, deve ser o mesmo com o CouchDB.

Digamos que temos esses 3 modelos:

Story:
 id
 title

User:
 id
 name

Vote:
  id
  story_id
  user_id

Eu quero poder fazer ao banco de dados estas perguntas:

• Quem votou nesta história?
• O que esse usuário votou?

Estou fazendo junções simples enquanto trabalho com um banco de dados relacional. A questão é: como devo armazenar os dados para esses objetos para serem mais eficientes.

Por exemplo, se eu armazenar os objetos de voto como uma subcollecção de histórias, não será fácil obter as informações - "o que um usuário votou".

Answer 1

Eu sugeriria armazenar votos como uma lista de história _ids em cada usuário. Dessa forma, você pode descobrir quais histórias um usuário votou apenas olhando para a lista. Para obter os usuários que votaram em uma história, você pode fazer algo como:

db.users.find({stories: story_id})

Onde story_id é o _id da história em questão. Se você criar um índice no stories O campo de ambas as consultas será rápido.

Answer 2

• Não se preocupe se suas consultas forem eficientes até começar a importar
• De acordo com a citação abaixo, você está fazendo errado

A maneira como eu tenho passado pela mudança da mente é esquecer o banco de dados Altogether. No mundo relacional do banco de dados, você sempre precisa se preocupar com a normalização dos dados e sua estrutura de tabela. Abandonar tudo. Basta fazer layout sua página da web. Deite -os tudo. Agora olhe para eles. Você já tem 2/3 lá. Se você esquecer a noção de que o tamanho e os dados do banco de dados não devem ser duplicados do que o seu 3/4 lá e você nem precisou escrever nenhum código! Deixe suas opiniões ditarem seus modelos. Você não precisa pegar seus objetos e torná -los mais bidimensionais como no mundo relacional. Você pode armazenar objetos com forma agora.

Como pensar em data-storres-instead-of-dados

Answer 3

OK, você não forneceu um modelo de dados normalizado, como faria em uma configuração SQL.

No meu entendimento, você não faz isso em MongoDB. Você pode armazenar referências, mas não faz por razões de desempenho no caso geral.

Eu não sou especialista na área de nosql de forma alguma, mas por que você simplesmente não segue suas necessidades e armazena o usuário (IDs) que votaram em uma história na coleção de histórias e na história (ids) que um usuário tem votou na coleção de usuários?

Answer 4

No CouchDB, isso é muito simples. Uma visão emite:

function(doc) {
 if(doc.type == "vote") {
   emit(doc.story_id, doc.user_id);
 }
}

Outra visão emite:

function(doc) {
 if(doc.type == "vote") {
   emit(doc.user_id, doc.story_id);
 }
}

Ambas são consultas extremamente rápidas, pois não há junta. Se você precisar de dados do usuário ou da história, o CouchDB suporta busca de vários documentos. Também é muito rápido e é uma maneira de fazer uma "junção".

Answer 5

Ultimamente, tenho procurado MongoDB e CouchDB, mas meu insight é limitado. Ainda assim, ao pensar em armazenar os votos dentro do documento da história, talvez você precise se preocupar em atingir o limite de tamanho de 4MB do documento. Mesmo se não o fizer, você pode estar constantemente aumentando o tamanho do documento o suficiente para fazer com que ele seja movido e, assim, diminuindo a velocidade das suas gravações (veja como os documentos são dimensionados em MongoDB).

Quanto ao CouchDB, esses tipos de coisas são bastante simples, elegantes e bastante rápidos quando os índices de visualização são calculados. Pessoalmente, no entanto, hesitei em fazer um projeto semelhante no CouchDB por causa dos benchmarks, mostrando que ele diminuiu progressivamente em um grau considerável à medida que o banco de dados cresce (e os índices de visualização crescem). Eu adoraria ver alguns benchmarks mais recentes mostrando o desempenho do CouchDB à medida que o tamanho do banco de dados aumenta. Quero experimentar o MongoDB ou o CouchDB, mas o SQL ainda parece tão eficiente e lógico, então ficarei com ele até que o projeto se encaixe na tentação da maneira certa.