各位大佬,几十万用户,存在上下级关系如下需求,改用啥数据库或啥方式存储处理好些

2021-01-06 09:47:20 +08:00
 cnbattle

目前用 mysql

有如下俩张表:

  1. 基础表:存用户数据及上级的 ID
id parend_id is_black 昵称等其他字段
1 0 0
2 1 0
3 2 0
4 2 0
  1. 关系表:某用户上级及下级所有用户的表: 存用一用户 id,上级,上级的上级直到,没有上级, 下级同理(下级数据,极少数的账号有 20 多万的下级 id,大多数几千到几万不等)
id uid 所有上级 所有下级
1 1 2,3,4
2 2 1 3,4
3 3 1,2
4 4 1,2

需求如下:

  1. 基于某一用户,检索他的下级, 例如 基于 id 2 下, 检索昵称为 cnbattle 的用户

  2. 拉黑某用户,拉黑后,删除并清空该用户的关系,下级数据依次上移到该用户的上级,

假设基于上述的表: 拉黑 id 2 的用户,那么更新为如下的数据

基础表:

id parend_id is_black 昵称等其他字段
1 0 0
2 0 1
3 1 0
4 1 0

关系表

id uid 所有上级 所有下级
1 1 3,4
2 2
3 3 1
4 4 1

问题:

Q1: 检索,目前是基于关系表 where in, 虽目前能正常运行,但性能不好,有内存溢出的风险

Q2: 拉黑用户:是队列处理,当处理一个关系靠顶部的用户时,处理数据量会比较大(这个还好,队列慢慢处理也行)


基于上述情况,如果优化可以基本满足在简单加机器的情况下,让程序稳定运行的方案方法?

2237 次点击
所在节点    问与答
22 条回复
mlhadoop
2021-01-06 09:51:12 +08:00
所以是 zhuan 销集团么
IMCA1024
2021-01-06 09:54:00 +08:00
Q1: 可以定时任务 每隔一小段时间跑一份数据处理, 但有一定延时,单表查询速度比较快,
也可以继续用你的这种 in 查询 几千几万 ,应该还好的啊, 控制 in 的数量应该问题不大,分段也可以。

也想看看其他方法,学习学习
wangxiaoaer
2021-01-06 10:21:34 +08:00
blueorange
2021-01-06 10:26:37 +08:00
@mlhadoop 非常像
oott123
2021-01-06 10:27:05 +08:00
Materialized Path 行不行
UserNameisNull
2021-01-06 11:49:54 +08:00
图数据库呢?
wudaye
2021-01-06 12:58:19 +08:00
可以拉黑,看来不是企业组织
cnbattle
2021-01-06 14:01:12 +08:00
@mlhadoop
@blueorange
@wudaye

直销系统,有兴趣的话可以了解下
cnbattle
2021-01-06 14:04:15 +08:00
@oott123 存储方式有的, 关系链 有个所有上级字段,存的就是类似 Materialized Path 的结构数据,目前是想找个好的方式来做查询,及更新操作
cnbattle
2021-01-06 14:35:51 +08:00
@wangxiaoaer 谢谢,大概看了下,感觉不错,不过之前没用过 postgresql,周末模拟点数据试试
dswyzx
2021-01-06 14:38:09 +08:00
法律规定,分销层级超过三级即可判定为传销.所以说如果是合法的也就最多嵌套三层层级.直接写死层级也没多复杂吧
cnbattle
2021-01-06 14:39:01 +08:00
@UserNameisNull 没了解过,我先看看 0.0
cnbattle
2021-01-06 14:58:13 +08:00
@dswyzx 不是讨论是否发杂的问题,而是想讨论下有没有啥更好一些的方案而已

就好比你说三级一个用户找了几百人,往下两级就几万用户了,同样会出现性能,内存可能溢出的问题,和修改操数据量大的问题,从而可能出现 mysql 锁 相关的一系列问题,只是想在可能出问题之前,做点预防性的优化 修改等
opengps
2021-01-06 15:05:43 +08:00
不要一看到无限级联就想到传销,现在常见的玩法是:虽然无限级联,但是消费利润最多分享给上级个上上级这三级,丝毫没有违法
atusss
2021-01-06 15:10:23 +08:00
嗷,最近才做了一个类似的需求。
表结构大致这样
user_id (用户 id ),`base_id ( 64 进制的用户 id ),`link (当前用户的完整链),

1003854 3R5E {3QzH}{3QBh}{3R5E}
1000072 3QA8 {3Qz2}{3Qz9}{3Qzg}{3QzT}{3QA8}
1000996 3Qbn {3QzH}{3QEa}{3QES}{3Qbn}
1000073 3QAz {3Qz2}{3Qz9}{3Qzg}{3QzT}{3QAz}
1003856 3R5G {3QzH}{3QEa}{3QES}{3Qbn}{3R5G}
1000080 3QAG {3QzH}{3QAG}
1000375 3QET {3QzH}{3QEa}{3QET}
1000060 3QzY {3Qz2}{3Qz9}{3Qzg}{3QzY}
1000442 3QFW {3QzH}{3QEa}{3QET}{3QFW}
JasperYanky
2021-01-06 15:15:46 +08:00
https://github.com/django-mptt/django-mptt 这是个树型结构管理库,我拿来做用户关系,基本都能满足,你可以看看
matrix67
2021-01-06 15:23:25 +08:00
coreki
2021-01-07 00:28:38 +08:00
我写过这个,多级上下级,也是几万几十万下级,这种下级全部写在一个字段里面,性能不好。
cnbattle
2021-01-07 08:25:28 +08:00
@matrix67 这样方式,数据量少还可以,一多就不行了
cnbattle
2021-01-07 08:28:20 +08:00
@coreki 恩,所以就想问问有啥好点的方式,现在在研究图数据量,测试看看

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/742061

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX