1
fangchang 2018-03-16 22:12:01 +08:00
不然你也可以用 graph db 啊
|
3
kaifeii 2018-03-16 22:36:48 +08:00 via iPhone
如果压力在读操作的话,异步或直接做临接图,也就是把一个用户的好友做成一个字段放起来,这样其实跟索引差不多,只是省了数据库性能,也可以提前做一些静态数据的 join。
微博那种应该是分高频和低频的,具体不了解 |
4
feverzsj 2018-03-16 22:41:26 +08:00
约束 UserID1 < UserID2,这样只要一条记录就可以了
|
5
NoBeeBee OP 我现在遇到的场景大概是这样的:
1. 用户表 大概几个亿 2. 分组表 大概几百个 3. 用户可以在多个分组内, 即对应多个分组 4. 便于用户经常更新所属分组信息 更具上述情况构建 用户和分组的关系 这样看下来就是一般的多对多关系,只不过一边量比加大,一边量比较小而已。 如果按网友 A 和 B 的样子设计一个关系一行数据下来 关系表 的预计大小也在百亿左右。感觉挺占数据空间的,但感觉从 分组角度 来看检索速度会比较快。 如果将每个用户的所拥有的分组合并在一起,例如写成一个 list[A 组,B 组,C 组,等等],这样存在一个字段 teams 里面,就可以直接写到用户表内,数据空间是到省了不少。但是从 分组角度 来建立索引检索感觉会非常慢,因为毕竟对字符串的检索要比对数字的检索慢很多。 现在比较纠结是拿空间换时间,还是拿时间换空间,总感觉还应该有更好的解决办法。 求指点 |