微博的用户关系数据库应该如何设计？

[puritania]

疑问在于用什么维度做数据库、表拆分，这种数据极不平均，大 R 几千万粉丝，普通人几百粉丝，按传统 uid 这种做 hash 行不通，应该如何设计呢？

[WeaPoon]

等大佬回答，排队学习．

[xAx]

具体是怎么实现不清楚。
但这类场景，如果是用关系型数据库，那么不管哪种解决方案，思路都差不多。
用代理层对业务屏蔽数据库细节。
数据库上可能把大 V 和普通用户分库或分表。这怎么分都是无所谓。
分库分表不一定非 uid 什么的，随便哪个字段都行，是不是 vip,是不是政企，注册时间，活跃度...都可以用作分库分表的依据。
甚至可以把不同用户的数据散布在不同的数据中心。

业务含意的逻辑分完后，还可以进行数据库底层的物理分。

其实重点是怎么做汇总查。
很多项目都处理不好分表分库时的汇总查，所以喜欢搞微批系统，以批量出非实时统计结果

[puritania]

@xAx 数据库上可能把大 V 和普通用户分库或分表。这怎么分都是无所谓。
你直接就把我的问题无所谓了。。

[puritania]

@xAx 然后为什么说要按 uid 分，就是为了降低查询的复杂度，按你说的随便哪个字段那代理层可能需要查无数个数据库、表才能获得我到我的粉丝列表。

[xwhxbg]

如果把用户关系看做有向图，似乎可以通过图的疏密来分区，查找可能是两步，先从分区键查分区，再用 uid 查具体哪个用户
以上全是 YY 的哈，没做过这个量级的

[kimchan]

排队学习+1

[jzds001]

排队学习+1

[grimpil]

排队围观，暂时学不了这种高科技

[chenyj]

好奇观摩

[jy02534655]

排队学习+1

[clino]

"大 R 几千万粉丝，普通人几百粉丝"
我现想的抛个砖,我想虽然这里面大 V 有好多粉丝,但是并没有需要有地方能把这些粉丝都显示出来,所以我只要保证前多少个粉丝(比如 500)能快速查询出来就可以了,多的另外的表来存放,这样是不是相当于把大 V 和普通人分开了.

而一个用户 fo 的人一般不会太多,这部分也冗余地存放起来

我觉得比较难的部分是快速过滤出某些用户的微博,比如我 fo 的所有用户的微博,各种 tag 的用户的列表,要能看这些列表的微博,这部分我觉得要做到高效挺难的...不知道怎么做的

[puritania]

@clino 你说的 feed 数据每个人都有自己的 feed 列表，一般都是推拉结合来做的。

[clino]

@puritania #12 你是说每个人的 feed 都是自己一份? 那比如我有 20 个用户分组,那么每个组的 feed 是从前面这份全的 feed 和分组信息关联查询出来的?

[puritania]

@clino 那肯定，没有必要为了分组多冗余数据。

[clino]

@puritania #14 如果每个人的 feed 都自己一份,那就是说比如说有 1 千万粉丝的大 V 发一条,就要给这些粉丝的 feed 增加一条记录,就要一下增加 1 千万条这样吗?

[fcten]

用户的关注关系是一个访问极端频繁的数据，是必然要缓存在内存里的。所以即使需要用关系型数据库做持久化，在设计上也不必太考虑性能的问题。
估计会针对大 V 和非活跃用户做一些特殊处理。

[rogwan]

以前微博的技术 yang 分享过，就是推拉结合。具体谁推谁拉算法肯定是一直在变的，根据用户的活跃情况调整。

[puritania]

@clino 所以说是推拉结合的 可以考虑只给再现用户推 部在线用户 上线时拉取

[puritania]

@fcten 问题就是特殊处理应该如何处理。。

[puritania]

@clino feed 也是很难的设计