最佳架构设计用于在MongoDB中

日志分析数据库中，我有以下的数据存储在MongoDB中uid, gender ,country, city, date_of_visit, url_of_visit最佳架构设计用于在MongoDB中

我想用来存储UID，性别，国家和城市的一个集合，因为这些信息不会针对特定改变用户。

其他集合中

我想用来存储uid, date_of_visit, url_of_visit

我想知道这是存储uid, date_of_visit and url_of_visit。还有在我的脑海两件事最佳实践..

(a) { uid: 100, date: xxxxxxxxxxxxxxx, url: abc.php } 
     { uid: 100, date: xxxxxx, url: ref.php } 
     { uid: 200, date: xxxxxxxxx, url: ref.php } 

    (b) { uid:100, visit:[{date:xxxxxxx, url:abc.php}, 
          {date:xxxx, url:def.php}, 
          {.........................}]}

我想有下面的索引日期：1，uid：1，url：1 ...方法（a）的问题是在数据库中插入每一行数据库端和索引大小将增加，并且当索引大小不适合时会出现一个点进入内存

问题与方法（b）是在某些时候，每个文件将超过16 MB的限制，这种方法将失败的时间..

请建议我什么应该是这种情况下最好的模式设计。我也会有查询，其中包括uid, gender, country, date_of_visit, url_of_visit

来源

2011-08-23 mark gill

我认为第二种方法比一种更好，因为它符合将相似数据分组在一起的想法。关于超过16M的文件，你可以达到这个限制，但他应该是一个非常活跃的用户。 :)

此外，您可以将一些数据提取到另一个集合，并使用ObjectId或DBRef进行引用。查看更多信息http://www.mongodb.org/display/DOCS/Database+References#DatabaseReferences-DBRef

来源

2011-08-23 10:45:15

出于好奇:)一个问题。随着时间的推移，文档大小将会增长，那么对这些文档（大尺寸文档）的写操作会很慢吗？ –

这很难说，它取决于Mongo数据总量以及它如何适应内存。但我认为没关系，因为在其他情况下，和以前的版本一样，限制将会是8M。 –

我想隐藏Uid Bin数据并将其分配给_id字段。将uid设为_id是个好主意吗？我已阅读过文档“使用大致按升序排列的_id值”。并且我的uids值完全是随机的 –

我知道这个线程有点老，但我想知道你是否决定了一个结构，如果它运作良好。

我的想法是，而不是冒着创建太大的文件的风险，结构它类似于你的第二种方法，但包括在主要集合中的日期。这样每个文档就会在一天内成为用户的活动。它将按用户和日期进行索引，易于更新和查询并保持组织结构。

喜欢的东西：

{ uid:100, date:xxxxxxx, event:[{time:xxxxxxx, url:abc.php}, 
           {time:xxxx, url:def.php}, 
           {.........................}]}

来源

2012-03-30 07:57:34 f10

你的第二个方法将迫使你从嵌入的文件，不能被蒙戈过滤取一个巨大的数据量。换句话说，如果有一百万个文档存储在特定用户的“事件”字段内，那么当您使用点符号获取这些嵌入文档时，则会返回包含父文档的整个文档。您无法过滤结果。

我会推荐第一种方法，使数据更容易检索和使用。

来源

2014-10-24 06:30:25

最佳架构设计用于在MongoDB中

回答

相关问题