关于社交类应用的用户关系数据表设计的一点儿思考

[NoBeeBee]

最近碰到多对多型数据需要设计数据库，然后想到可能和社交类应用的用户关系场景相似，然后就上网一痛乱搜，发现大家比较公认的方法是：

某 A 网友回答：
数据表三个字段

主键（自动生成） UserID1UserID2

注意事项

<UserID 1, UserID 2> 和 <UserID 2, UserID 1> 是一样的记录，不要重复添加

为了快速判断两个人是不是好友，可以在程序层插入数据前加一个限制 UserID1 < UserID2

为了快速得到一个人的好友列表，查询时用 UNION ALL，不是 UNION

如果为了再高效，加入缓存层（ Redis 或 Memcached ）
--------------------------------------------------------------

某 B 网友回答：
还能怎么设计呢

一个 uid，一个 friend_uid 呗

*********************************

现在细想一下，都是一个关系一条记录，那像微信，微博等大型的网站用户量怎么也得是亿级别的，每个人好友不用太多，就 200 个吧。那算下来这个用户关系表，最少也得是 200 亿行(⊙﹏⊙)b。

难道事实真的是这样吗？求科普

[fangchang]

不然你也可以用 graph db 啊

[NoBeeBee]

@fangchang 目前用的是 MySQL，还不想因为这个换库

[kaifeii]

如果压力在读操作的话，异步或直接做临接图，也就是把一个用户的好友做成一个字段放起来，这样其实跟索引差不多，只是省了数据库性能，也可以提前做一些静态数据的 join。

微博那种应该是分高频和低频的，具体不了解

[feverzsj]

约束 UserID1 < UserID2，这样只要一条记录就可以了

[NoBeeBee]

我现在遇到的场景大概是这样的：
1. 用户表 大概几个亿
2. 分组表 大概几百个
3. 用户可以在多个分组内, 即对应多个分组
4. 便于用户经常更新所属分组信息
更具上述情况构建 用户和分组的关系

这样看下来就是一般的多对多关系，只不过一边量比加大，一边量比较小而已。
如果按网友 A 和 B 的样子设计一个关系一行数据下来 关系表 的预计大小也在百亿左右。感觉挺占数据空间的，但感觉从 分组角度 来看检索速度会比较快。

如果将每个用户的所拥有的分组合并在一起，例如写成一个 list[A 组，B 组，C 组，等等]，这样存在一个字段 teams 里面，就可以直接写到用户表内，数据空间是到省了不少。但是从 分组角度 来建立索引检索感觉会非常慢，因为毕竟对字符串的检索要比对数字的检索慢很多。

现在比较纠结是拿空间换时间，还是拿时间换空间，总感觉还应该有更好的解决办法。
求指点

[NoBeeBee]

@kaifeii 那如果是个大 V 的话，几百万的好友列表，对应的这个好友字段岂不会相当长。

[NoBeeBee]

@feverzsj 感觉也就能省一半，毕竟一个人如果有 200 个好友，就需要 100 条这样的记录。量还是挺大的。