【问题标题】:Database choice: frequently querying 2nd degree connections数据库选择:频繁查询二度连接
【发布时间】:2016-07-08 11:12:07
【问题描述】:

我的网络应用程序需要始终查询 2 度连接。每个用户有 200 个朋友,这些朋友每个有 200 个朋友。我可以使用一些帮助来确定正确的数据库(和表结构),以使这个 Web 应用程序快速响应。

业务逻辑:用户搜索他们的 1 级和 2 级连接以获得使用特定服务的其他用户的列表(以 unsigned int 的形式存储在一列中)。这是此应用的唯一功能。

表结构

  • 用户表:User_ID (pk)、Facebook_ID (sk)、姓名、特定服务、位置
  • 关系表:仍未确定。

问题:我阅读了很多帖子并在网上搜索“社交网络数据库设计”。但是,这些应用程序与我的感觉有很大不同。我将有很多用户(+10 百万),但只有一个小型数据库,并且只运行一个查询,如业务逻辑中所述。

其他信息:用户只能使用他们的 Facebook 帐户注册(并随后登录)。他们的朋友将被邀请(通过 Facebook)也注册。 关系表将在朋友注册后填充(仅限活动/未阻止/未挂起的朋友)。因此,我可以从 Relationship Table 中删除“友谊状态”列。

【问题讨论】:

    标签: mysql facebook-graph-api database-schema social-networking database-performance


    【解决方案1】:

    你需要一个有两个 id 的表;它将定义一个“朋友”。这种关系是对称的吗?也就是说,如果 A 是 B 的朋友,那么 B 是 A 的朋友吗?好吧,我假设两者都发生时有 2 行。

    然后

    CREATE TABLE Friends (
        user1 ...,
        user2 ...,
        PRIMARY KEY(user1, user2),
        INDEX(      user2, user1)
    ) ENGINE=InnoDB;
    
    SELECT a.name, c.name
        FROM Users AS a
        JOIN Friends AS ab  ON ab.user1 = a.user_id
        JOIN Users AS b  ON b.user_id = ab.user2
        JOIN Friends AS bc  ON bc.user1 = b.user_id
        JOIN Users AS c  ON c.user_id = bc.user2
        WHERE a.user_id = ?
    

    【讨论】:

    • 是的,设计是对称的,没有其他选项(如关注者、阻止联系人等)。但我真正的问题是,当我执行查询以查找 2 度朋友时,这种设计是否有效?
    • 如果所有内容都被缓存,一千个二级朋友应该会在不到一秒的时间内完成。即使没有完全缓存,也可能只需要一秒钟。
    • 您能否根据您的经验评论一下使用哪个数据库?我的意思是我应该选择图形数据库还是 RDBMS?
    • (我对任何“图形数据库”一无所知。我的专长是帮助 MySQL,一个 RDBMS。)
    • @NeoSplit 您最终为此使用了哪个数据库?
    猜你喜欢
    • 2012-11-13
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-11-27
    • 1970-01-01
    • 2015-01-09
    • 1970-01-01
    相关资源
    最近更新 更多