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

[puritania]

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

[Universe]

不止一种数据库，关系型数据库和图数据库混用，这个是图数据库的经典例子了，相关的讨论非常多

[klxq15]

我尝试用过 dgraph 图数据库，但是性能什么的没测试过

[fcten]

@puritania 我不是说数据库特殊处理，我是说缓存特殊处理。
这种数据用 NoSQL 存储，根本没有分库分表的问题。用关系型数据库存储，必然达不到性能要求，必然要上缓存。数据库进行特殊处理，恐怕收益非常有限。

[puritania]

@fcten 数据库肯定是要有完整数据的，缓存的话每个大 v 几千万的粉丝都缓存感觉不太现实吧。

[1ku]

等会，我去泡好茶，搬好凳子...瓜子零食已到位，好了，开始吧！

[Kilerd]

排队学习

[Immortal]

微博应该大量用了 redis 以前有技术分析的文章 找一下网上应该有不少 大 B 百万关注那种都是特殊处理了 单独使用一个实例 或者 啥的，和普通用户分开了 还有就是前面大佬说的推拉结合

[fcten]

@puritania 几千万粉丝其实数据量并不大。对于微博来说，上 TB 的内存集群都没啥问题吧。

[owenliang]

不要用条数轮性能，知道 log based 存储吗 越大的批量写入收益越高。

当你性能不行的时候，想想批量两个字。

[Zzde]

排队学习

[puritania]

@owenliang 不明白你什么意思 数据库存储结构跟批量写入有什么关系

[owenliang]

@puritania 大家一般认为 feed 流就是拷贝千万次，实际上对于 hbase 这种日志存储来说，批量提交 1m 的 batch 可能包含数万条 feed 关系，这是大家觉得不可思议最本质的一个问题。

就像有人疑惑弹幕服务器如何承载百万人在线一样，认为 1 条弹幕要推送 100 万次，不可思议。其实大家没想过，完全可以攒几秒秒再批量推送下去，瓶颈转移到带宽而不是 cpu。

只是告诉你两个字，批量。

[bsidb]

微博的技术大拿在网上有技术分享 PPT，应该还能搜到。
我印象中，当时的 PPT 是这样说的（约至少 2 年前），如果说的有问题，还请拍砖：
1. 微博信息数据（即微博的具体内容等）是存储在关系型数据库中的。使用标准的分库分表技术就能水平扩展。
2. 微博的关系数据（即 Follow 关系）和 Feed 流数据，我记得没有细说。但是每个用户是会维护自己的 Feed 流，这个 Feed 流应该只保存了微博 ID 编号，不保存具体微博内容。等用户浏览自己的 Feed 流的时候，再从关系数据库中取出微博内容，并将网页返回给用户。
3. 微博的通知数据（你有 XX 新粉丝，有 XX 新回复，有 XX 新点赞等信息），因为体积不大而且经常变动，是保存在 Redis 中。

当一个用户发了一条新微博之后，后续的更新动作一般是推拉结合：
1. 对于普通用户（粉丝数小于某个值）的微博更新，用“推”的方式比较划算。当一个用户更新微博后，把新微博的 ID 信息写入他的粉丝的 Feed 流存储之中。
2. 对于大 V 用户（粉丝数大于某个值）的微博更新，用“拉”的方式比较划算。当大 V 更新微博后，并不会将新微博 ID 推送到粉丝的 Feed 流。而是在粉丝查看自己的 Feed 流的时候，现场去查询其关注的大 V 的最新动态，并加入 Feed 流。这种“拉”的好处是减少了大 V 更新微博时的一系列数据库操作代价，而且大 V 微博的时效性很强，能很好地进行热缓存。