Question

我对MongoDB相对较新，到目前为止我印象非常深刻。我正在努力设置我的文档商店的最佳方式。我正在尝试使用Twitter数据进行一些摘要分析，我不确定是将这些推文放入用户文档中，还是将它们作为单独的集合保存。似乎将推文置于用户模型中会很快达到规模限制。如果是这种情况，那么能够在一组用户的推文中运行MapReduce的好方法是什么？

我希望我不是太模糊，但我不想在设置我的域模型时过于具体和太过错误。

我确信你们都很无聊，我已经习惯了RDB的土地，我会在那里布局我的架构

| USER |
--------
|ID
|Name
|Etc.

|TWEET__|
---------
|ID
|UserID
|Etc

似乎Mongo中的逻辑架构是

User
|-Tweet (0..3000)
  |-Entities
    |-Hashtags (0..10+)
    |-urls (0..5)
    |-user_mentions (0..12)
  |-GeoData (0..20)
|-somegroupID

但不会很快膨胀用户文档超出容量。但我想对属于具有类似somegroupID的用户的推文进行分析。它在概念上对于如上所述的模型布局是有意义的，但是在什么时候太不合适了？什么是可行的替代方案？

Answer 1

你是对的，你可能会遇到16MB的MongoDB文件限制。您不是说要运行什么样的分析，因此很难推荐架构。 MongoDB模式在设计时考虑了数据查询（和插入）模式。

当然，您可以轻松地执行相反的操作，而不是将推文发送给用户，而是在tweet文档中添加用户ID和group-id。然后，如果您需要用户提供其他字段，则可以在显示时始终在第二个查询中提取该字段。

我的意思是推文文档的设计为：

{
    'hashtags': [ '#foo', '#bar' ],
    'urls': [ "http://url1.example.com", 'http://url2.example.com' ],
    'user_mentions' : [ 'queen_uk' ],
    'geodata': { ... },
    'userid': 'derickr',
    'somegroupid' : 40
}

然后对于用户集合，文档可能如下所示：

{
    'userid' : 'derickr',
    'realname' : Derick Rethans',
    ...
}

Answer 2

所有信用都归功于MongoHQ.com的优秀人士。我在https://groups.google.com/d/msg/mongodb-user/OtEOD5Kt4sI/qQg68aJH4VIJ

上回答了我的问题

Chris Winslett @ MongoHQ


你会发现这个视频很有趣：

http://www.10gen.com/presentations/mongosv-2011/schema-design-at-scale

基本上，在一个文档中，存储一天的推文   人。理由：


查询通常包含天数和用户


因此，您可以拥有以下索引：

{user_id：1，date：1} #Date需要是最后一个，因为你会有范围   并按日期排序

玩得开心！

Chris MongoHQ

我认为实施以下内容最有意义：

用户的

{ user_id: 123123, screen_name: 'cledwyn', misc_bits: {...}, groups: [123123_group_tall_people, 123123_group_techies, ], groups_in: [123123_group_tall_people] }

的鸣叫 的

{ tweet_id: 98798798798987987987987, user_id: 123123, tweet_date: 20120220, text: 'MongoDB is pretty sweet', misc_bits: {...}, groups_in: [123123_group_tall_people] }

具有大量内部文档的MongoDB数据结构

2 个答案: