一个面试题

假设网站有1000万个注册用户，每个用户跟每个用户都有可能是好友关系， 如果是你怎么设计存储过程，如何设计表？

解决方案 »

  1.   

    按用户ID的首两个字母/数字分表-库比如你hxprince的用户信息，及好友信息放在hx里面
      

  2.   

    存储过程 不知道，要看你的存储过程的功能需求是什么。表的设计 一般是user (uid,uname,....)
    friends ( uid,fid,..)粗体为主键。
      

  3.   

    单表的话，user可能抗得下来，friends可能够呛。
      

  4.   

    1000万个注册用户, 假设每个用户平均50好友 则friends 需要 50*10,000,000 = 500M 条记录。应该还可以。
      

  5.   

    500M = 5亿条。我想求教一下狼头，friends的PK，第一层应该是先uid，1000w种可能，是不是会对效率没什么帮助？是否考虑用hash uid更有帮助?
      

  6.   

    我觉得首先分表是必须的，但是你需要考虑的问题其实很多， 如果是在同一个DB, 那么不管user表还是friends表，分成多少个桶都可以。但是如果有这么多的用户，那么同一个mysql DB是否能承受得住这个访问量，如果是分库， 那就又牵涉到另外一个查询的问题，例如我想找我所有朋友的个人信息，这时是拿着好友ID到所有DB去查一遍还是怎么来做呢? 如果拿着ID到所有DB去查一遍似乎性能不会太好，那是否有更好的办法呢? 这得看需求是什么要的， 如果list的时候只需要列出好友的少量信息，那是否可以考虑使用数据冗余呢?另外一个问题是， A邀请B做了好友， B成了A的好友， 那么此时A是否也自动成为了B的好友呢? 如果是，那么当friends(invitee_ID,invited_ID)的时候， 如果B要查找所有好友，是否会要找select * from friends where col1=B_UID or col2=B_UID呢? 如果这样做性能是否能接受呢? 
    其实这个问题基本上每个大公司都碰到过
      

  7.   

    恩 确实有楼上所考虑的问题，一般好友关系都是双向的，A到B 与B到A 要有两条记录的
      

  8.   

    大家都光考虑数据库本身了，缓存等
    双向是个问题。但不是本题的主要问题。
    另外，select * from friends where col1=B_UID or col2=B_UID一般都用union all，两个字查询分别利用各自索引
      

  9.   

    一个字段，保存一堆好友关系key，依赖上层解决好友关系解析问题
      

  10.   

    一个字段，保存一堆好友关系key，依赖上层解决好友关系解析问题. 楼上有位仁兄提了这个建议，那如果哪天需要找出哪些人把我加成了好友， 我该怎么来解决.
    其实我觉得在详细的需求出来之前， 这个问题不那么容易有答案吧...
      

  11.   

    3楼的表结构没什么问题,我也觉得会用分表存储的方式,而且应用上用memcache或者其他方式的缓存来读取