我需要一个关于NoSQL / MongoDb和数据/模型结构的建议

时间:2009-11-29 14:58:17

标签: mongodb couchdb database nosql

最近我正在探索NoSQL数据库。我需要一个关于如何以最佳和有效的方式为给定问题存储数据的建议。我现在以MongoDB为目标。但是它与CouchDB应该是一样的。

假设我们有这三种型号:

Story:
 id
 title

User:
 id
 name

Vote:
  id
  story_id
  user_id

我希望能够向数据库询问这些问题:

  • 谁投票赞成这个故事?
  • 此用户投票给了什么?

我在使用关系数据库时正在进行简单连接。问题是,我应该如何存储这些对象的数据,以便最有效。

例如,如果我将投票对象存储为故事的子集合,则很难获得信息 - “用户投票的内容”。

5 个答案:

答案 0 :(得分:7)

我建议将投票存储为每个用户的故事_id列表。这样,只需查看列表,您就可以找到用户投票的故事。要获得投票选出故事的用户,您可以执行以下操作:

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

其中story_id是相关故事的_id。如果您在stories字段上创建索引,则这两个查询都会很快。

答案 1 :(得分:3)

  • 如果您的查询开始有效,请不要担心
  • 根据以下引用,你做错了
  

我一直在谈论的方式   心灵切换就是忘记了   数据库一共。在里面   你总是需要关系数据库世界   担心数据规范化和   你的桌子结构。放弃一切。   只需布置您的网页即可。放下它们   全力以赴。现在看看他们。您的   已经2/3了。如果你忘记了   数据库大小重要的概念   数据不应该比您的重复   3/4那里,你甚至没有   写任何代码!让你的意见决定   你的模特。你不必采取   你的对象并制作它们2   维度就像在   关系世界。你可以存储   现在有形状的物体。

how-to-think-in-data-stores-instead-of-databases

答案 2 :(得分:2)

好的,您没有像在SQL设置中那样提供标准化数据模型。

根据我的理解,你不会在MongoDB中这样做。您可以存储引用,但在一般情况下不是出于性能原因。

我绝对不是NoSQL领域的专家,但为什么不简单地按照你的需求存储已经在故事集和故事中投票的用户(ids)(ids)用户已在用户集合中投票?

答案 3 :(得分:1)

在CouchDB中,这非常简单。一个视图发出:

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

另一个视图发出:

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

由于没有连接,两者都是极快的查询。如果您确实需要用户数据或故事数据,CouchDB支持多文档提取。也很快,是进行“加入”的一种方式。

答案 4 :(得分:0)

我最近一直在研究MongoDB和CouchDB,但我的洞察力有限。尽管如此,在考虑将故事文档存储在故事文档中时,您可能不得不担心达到4MB的文档大小限制。即使您不这样做,也可能会不断增加文档的大小,导致文档被移动,从而减慢写入速度(请参阅MongoDB中文档的大小)。

对于CouchDB,一旦计算了视图索引,这些事情就非常简单,优雅,而且非常快。然而,就个人而言,由于基准测试显示随着数据库的增长(以及视图索引的增长)逐渐减慢到相当程度,我对在CouchDB中做类似的项目犹豫不决。我希望看到一些更近期的基准测试显示随着数据库大小的增加CouchDB的性能。我想尝试使用MongoDB或CouchDB,但SQL仍然看起来如此高效和合乎逻辑,所以我会坚持下去,直到项目恰好符合诱惑。