MongoDB数据库架构设计

Question

我有一个拥有500万用户的网站(在sql server 2008上运行).我想现在包括用户及其朋友的活动流.在SQL Server上测试了一些东西后,很明显RDMS不是这种功能的好选择.它很慢(即使我严重地对我的数据进行了规范化).因此,在查看其他NoSQL解决方案后,我认为我可以使用MongoDB.我将关注基于活动流的activitystrea.ms json规范的数据结构 所以我的问题是:MongoDB中活动流的最佳模式设计是什么(有这么多用户,你几乎可以预测它会非常沉重在写入时,因此我选择MongoDB - 它具有很好的"写入"性能.我已经考虑了3种类型的结构,请告诉我这是否有意义或者我应该使用其他模式模式.

1 - 以这种模式将所有朋友/粉丝存储在每个活动中:

 

    {
     _id:'activ123',
     actor:{
            id:person1
            },
    verb:'follow',
    object:{
            objecttype:'person',
            id:'person2'
            },
    updatedon:Date(),
    consumers:[
            person3, person4, person5, person6, ... so on
            ]

    }

2 - 第二个设计:集合名称 - activity_stream_fanout

    {
    _id:'activ_fanout_123',
    personId:person3,
    activities:[
    {
     _id:'activ123',
     actor:{
            id:person1
            },
    verb:'follow',
    object:{
            objecttype:'person',
            id:'person2'
            },
    updatedon:Date(),
    }

    ],[
    //activity feed 2
    ]

    }

3 - 这种方法是将活动项目存储在一个集合中,将消费者存储在另一个集合中.在活动中,您可能有一个文档,如:

    { _id: "123",
      actor: { person: "UserABC" },
      verb: "follow",
      object: { person: "someone_else" },
      updatedOn: Date(...)

    } 

然后,对于粉丝,我会有以下"通知"文件:

    { activityId: "123", consumer: "someguy", updatedOn: Date(...) }
    { activityId: "123", consumer: "otherguy", updatedOn: Date(...) }
    { activityId: "123", consumer: "thirdguy", updatedOn: Date(...) } 

非常感谢您的回答.

Answer 1

我会选择以下结构:

1. 对所发生的所有操作使用一个集合, Actions

2. 使用另一个集合来跟踪谁, Subscribers

3. 使用第三个集合,Newsfeed对于某个用户的新闻源,项目会从Actions集合中展开.

该Newsfeed集合将由异步处理新进程的工作进程填充Actions.因此,新闻源不会实时填充.我不同意Geert-Jan,因为实时很重要; 我相信大多数用户在大多数(并非所有)应用程序中都不关心延迟一分钟(实时,我会选择完全不同的架构).

如果你有很多consumers,扇出可能需要一段时间,真实.另一方面,将消费者权利放入对象中也不会对非常大的跟随者计数起作用,并且它将创建占用大量索引空间的过大对象.

然而,最重要的是,扇出设计更加灵活,允许相关性评分,过滤等.我刚刚在MongoDB上写了一篇关于新闻提要模式设计的博客文章,其中我更详细地解释了一些灵活性.

说到灵活性,我会小心那个activitystrea.ms规范.作为不同提供者之间互操作的规范似乎有意义,但我不会将所有冗长的信息存储在我的数据库中,只要您不打算从各种应用程序聚合活动.