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

最近我在研究NoSQL数据库。我需要关于如何针对给定问题以最优化和有效的方式存储数据的建议。我现在针对的是MongoDB。但是它应该和CouchDB一样。我需要关于NoSQL/MongoDb和数据/模型结构的建议

比方说，我们有这3种型号：

Story: 
id 
title 

User: 
id 
name 

Vote: 
    id 
    story_id 
    user_id

我希望能够查询数据库，这些问题：

谁投了票？
此用户投票的内容？

我做简单的用一个关系数据库工作时加入。问题是，我应该如何存储这些对象的数据才能达到最高效率。

例如，如果我保存投票对象作为故事的一个子集合它不会是容易得到的信息 - “什么是用户投票支持”。

来源

2009-11-29 Stan Bright

我建议保存票作为故事_id S IN每个用户的列表。这样，您可以通过查看列表来查明用户投了哪些故事。为了让谁投票给一个故事你可以做一些喜欢的网友：

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

其中story_id是有问题的故事_id。如果您在stories字段上创建索引，那么这两个查询都将很快。

来源

2009-11-29 16:18:33 mdirolf

那么，事实上，我想在投票模型中存储更多信息。例如：created_at，ip，user_agent。我应该将数据存储在用户集合的故事列表中吗？ – 2009-11-30 19:10:08

您可以将投票存储为一个子文档数组，每个文档类似于'{story_id：...，created_at：...，ip：...}'等，然后查询变为'find（{'stories .story_id'：...}）'。你也可以索引。 – mdirolf 2009-11-30 21:17:13

那么我有一个相当大的数据库与几个M记录，并将测试上述情况。 – 2009-12-01 07:01:08

好吧，你还没给一个规范化的数据模型，你会在SQL设置做。

在我的理解，你不MongoDB中做到这一点。您可以存储参考文献，但在一般情况下您不会出于性能原因。

我不是NoSQL领域的专家，但您为什么不简单地按照您的需求来存储已经投票支持故事集合和故事中的故事的用户（ID））用户在用户集合中投了票吗？

来源

2009-11-29 16:13:44 mkluwe

在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支持多文档提取。也相当快，是做“加入”的一种方式。

来源

2009-11-29 17:50:12 dnolen

我需要在这种情况下查询，我会吗？一个用于查询投票文档的索引，另一个用于获取用户/文章的文档。 – 2009-11-30 19:06:27

@Stanislav。那是对的。您首先需要获取投票，然后获取用户和/或投票的故事。 – dnolen 2009-12-01 01:15:22

，直到它开始按照以下报价无关紧要
，你正在做的不要担心，如果你的查询都是有效的错

我一直在进行有关的方式头脑转换就是忘记所有的数据库。在关系数据库世界中，你总是需要担心数据规范化和你的表结构。放弃一切。只需布置您的网页。把它们全部放在。现在看看他们。您的已经2/3。如果您忘记了数据库大小很重要的概念，并且数据不应与您的 3/4重复，那么您甚至不必编写任何代码！让你的观点决定你的模型。您不必采取您的对象，并使它们不再像在关系世界中一样。您现在可以存储带有形状的物体。

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

来源

2010-01-09 02:44:27

我一直在寻找到的MongoDB和CouchDB的很多最近，但我的观点是有限的。尽管如此，当考虑将故事文档存储在故事文档中时，您可能不得不担心达到4MB文档大小限制。即使你不这样做，你可能会不断增加文档的大小以使其移动，从而减慢写入速度（请参阅MongoDB中的文档大小）。

对于CouchDB来说，一旦视图索引被计算出来，这些东西就相当简单，优雅，而且相当快。然而就我个人而言，由于基准测试显示随着数据库的增长（以及视图索引增长）逐渐减慢到相当程度，我在CouchDB中做类似的项目时犹豫不决。我很想看到一些更新的基准测试，显示随着数据库大小的增加，CouchDB的性能。我想尝试MongoDB或CouchDB，但SQL仍然看起来如此高效和合乎逻辑，所以我会一直坚持下去，直到项目适合诱惑为止。

来源

2011-07-08 18:45:58

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

回答

相关问题