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

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

  •  
  •   hambman · 289 天前 · 2413 次点击
    这是一个创建于 289 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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