V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
hambman
V2EX  ›  数据库

社交网络里的关注实现(类似 V2EX 的关注)

  •  
  •   hambman · 2021-02-13 04:34:39 +08:00 · 2777 次点击
    这是一个创建于 1139 天前的主题,其中的信息可能已经有所发展或是发生改变。

    需求:用户关注一批用户,获取他们的动态。

    特大规模类比新浪微博 但是对于中等应用,比如一个用户关注~ 100 个用户左右 (明星用户有~ 1 万个关注者),简单的数据库查询,如果暂不考虑 redis 等 cache 方案的话,能否支持 10 万左右的用户体量。

    可以请 @livid 分享一些经验?

    select topics where author_id in (用户关注的用户列表,100 人左右)。
    
    18 条回复    2021-03-13 09:08:42 +08:00
    Mitt
        1
    Mitt  
       2021-02-13 04:45:00 +08:00 via iPhone
    这点量还不成问题吧,做好索引就行了
    js8510
        2
    js8510  
       2021-02-13 08:27:49 +08:00
    如果是纯考虑 sql 数据库的话,假设考虑用户访问同一个 DC: ( 1 )做一些 sharding 这样可以并发 select 请求。 (2) 做 replicates, 一个 master write only 然后 replicates read-only. 因为“动态” 听起来对一致性要求不高,而更在乎 延迟 (3) sql 数据库里只放纯 metadata(id, e.g topic id, item id, post id etc) 这样可以减少 DB read/write bandwith cost 把具体内容的分发剥离出去 暂时考虑这么多。


    一个很好的演讲全面的介绍了 Twitter 的很多年前的解决方案。
    Operations at Twitter: Scaling Beyond 100 Million Users":
    &t=1s
    sugarkeek
        3
    sugarkeek  
       2021-02-13 08:48:05 +08:00
    10 万不多吧,又不是同时十万个人关注,淅淅沥沥的那几个量,常见的数据库都没啥问题
    owenliang
        4
    owenliang  
       2021-02-13 10:38:41 +08:00 via Android
    实际工程上会用 hbase,现在也可以看看 tidb 了。
    hantsy
        5
    hantsy  
       2021-02-13 11:29:20 +08:00
    用 key/value 数据库啦,我是搞不懂为什么国内都是喜欢什么东西都是往 RDBMS 里面塞。
    BiteTheDust
        6
    BiteTheDust  
       2021-02-13 12:35:32 +08:00
    有一种做法似乎是 维护用户的时间线 在一个人发送了动态后向所有关注者的时间线插入数据
    love
        7
    love  
       2021-02-13 12:40:00 +08:00
    老问题了,一搜一大把。有推和拉二种,一般用推是保险做法,用拉以后可能会出大性能问题。
    areless
        8
    areless  
       2021-02-13 15:56:13 +08:00 via Android
    in 配合 exists,在大用户上使用 exists,10 万用户应该扛得住。不要给页码,只有上一页下一页以及超时直接抛错,慢查询独立处理。
    buliugu
        9
    buliugu  
       2021-02-13 23:41:15 +08:00
    新浪微博貌似是大规模使用 redis 的
    chengxiao
        10
    chengxiao  
       2021-02-14 19:27:49 +08:00
    印象中 KV 数据库在国内大规模的兴起和使用,就是因为社交网络
    hambman
        11
    hambman  
    OP
       2021-02-15 02:13:42 +08:00
    @BiteTheDust 恩,这个是“推”模式,用户少的时候也可以。
    hambman
        12
    hambman  
    OP
       2021-02-15 02:15:43 +08:00
    @chengxiao @hantsy 这个场景,请问用 key/value store 的优势是哪方面? 要两个查询,第一步得到关注的对象,第二步查询这些关注对象的文章。 是量大以后 scale 的优势吗?
    hambman
        13
    hambman  
    OP
       2021-02-15 02:17:46 +08:00
    @love 恩,我查询了一些经验。我理解是反过来?如果一个用户有 1 万人关注,他每发一条帖子数据库要插入 1 万条记录?
    hambman
        14
    hambman  
    OP
       2021-02-15 04:23:01 +08:00
    @areless 请问不给页码的优势是?我实现上一页,下一页,是用?page=(n-1) 和 ?page=(n+1)的方法,和页码本质是一样的,有更好的方法吗?
    hambman
        15
    hambman  
    OP
       2021-02-15 04:26:01 +08:00
    @js8510 谢谢建议,恩,应该会用到 2)和 3 ),如果数据量大的话也会用 sharding.
    love
        16
    love  
       2021-02-15 09:04:27 +08:00 via Android
    @hambman 对呀,现在有每个人有个接受邮箱,大 V 发个帖就是群发,其实只是看着有点可怕,毕竟又不是人人都是大 V 。比如 10 万个人每个人的接收队列每天会收到 100 条消息,那相当于一天中每秒只要插入 100 条记录就行了。
    e583409
        17
    e583409  
       2021-03-13 09:08:04 +08:00
    本质上是一个 feed 流实现了吧
    关系只是一部分,另一部分是 feed 流
    关系可以存 kv,mongodb 这些,feed 流这块比较复杂 没有多少经验
    e583409
        18
    e583409  
       2021-03-13 09:08:42 +08:00
    可以看看微博架构 演进路线
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2947 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 15:14 · PVG 23:14 · LAX 08:14 · JFK 11:14
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.