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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 1758 天前的主题，其中的信息可能已经有所发展或是发生改变。

目前用 mysql

有如下俩张表：

基础表：存用户数据及上级的 ID

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

关系表：某用户上级及下级所有用户的表：存用一用户 id,上级，上级的上级直到，没有上级，下级同理（下级数据，极少数的账号有 20 多万的下级 id，大多数几千到几万不等）

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

需求如下:

基于某一用户,检索他的下级, 例如基于 id 2 下, 检索昵称为 cnbattle 的用户
拉黑某用户,拉黑后,删除并清空该用户的关系,下级数据依次上移到该用户的上级,

假设基于上述的表: 拉黑 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: 拉黑用户：是队列处理，当处理一个关系靠顶部的用户时，处理数据量会比较大（这个还好，队列慢慢处理也行）

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

下级

上级

用户

关系表

22 条回复 • 2024-01-19 16:34:36 +08:00

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

https://www.postgresql.org/docs/9.0/ltree.html

blueorange

2021-01-06 10:26:37 +08:00

@mlhadoop 非常像

oott123

2021-01-06 10:27:05 +08:00 via Android

Materialized Path 行不行

UserNameisNull

2021-01-06 11:49:54 +08:00

图数据库呢？

wudaye

2021-01-06 12:58:19 +08:00 via Android

可以拉黑，看来不是企业组织

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}