1
Septembers 2017-03-15 09:05:56 +08:00 via iPhone
async + cache?
|
2
yangqi 2017-03-15 09:07:33 +08:00
这个是数据库设计的问题,你这个做字符模糊查询肯定没法优化。只能改表结构
|
3
phpdever OP @yangqi 在代码上无法优化了吗?因为 shares_tree 这个字段存放时是:“-|51|5150|1799|-”这样的。
|
4
yangqi 2017-03-15 09:14:48 +08:00
|
5
Immortal 2017-03-15 09:26:55 +08:00 6
|
6
sheep3 2017-03-15 09:29:38 +08:00 1
1. 小心循环依赖导致无限递归,最好加一个栈深度值判断一下。
2. 要不用 redis ,存 userid->user_tree_kids[] |
8
jianzhiyao020 2017-03-15 09:37:48 +08:00 2
首先,
多对多的多次查询肯定是坑, 你这个需求,应该是这样子的, 分销系统, 一个用户有一个上级, 可以有多个下级, 那么我们可以这样处理, 一个字段存 tree , 一级分销 /二级分销 /三级分销 /四级分销 /, 该 tree 字段可以建立索引, 查询本级的子节点可以用, tree like 我的 tree+'%' (伪代码) 因为 like 在前缀确认的情况下, 是可以使用索引的, 还需要一个字段,存当前层级,标注当前层级 0,1,2,3,4,5,6,7,8,9 , 查询的时候,比自己大的就是后面的人, 这种方法,理论上可以实现无限分销。 |
10
dapeng 2017-03-15 09:46:34 +08:00 1
#8 楼靠谱,感觉用 redis 的并不是能很好的解决这个问题,一是数据递增变化大,二是当数据量达到一定量级时这 redis 内存得设置多大;
最优方法还是数据库设计这块,冗余字段, 用空间换时间 |
11
EchoUtopia 2017-03-15 09:48:41 +08:00
使用图数据库,或者你查询出来的时候,自己构建一个有向图放在内存里,我目前有个需求跟你类似,是这样打算的
|
12
Immortal 2017-03-15 10:06:15 +08:00
@jianzhiyao020 其实这样设计有点不灵活 查询起来基本没问题 但是修改起来问题很大 要更新索引 更新层级 尤其是遇到那种"升级"上的时候 更为繁琐 比如从四级->二级 连带的所有下级用户 和 层级 和 下级用户的层级 索引等等 全部要更新一次 如果层级深 这个估计也不会快
|
13
jianzhiyao020 2017-03-15 10:10:55 +08:00
@Immortal
分销系统的话, 这种层级维护的可能基本为 0 , 主要是看需求, 如果说类似文件变动, 肯定是多对多, 但是, 多对多也产生了一个回溯上级的问题, 特别是分销系统,需要给上级分发奖励, 所以我觉得该类问题,应该是提需求, 而不是提技术难点。 如有疏漏, 请再次提出。 感谢。 |
14
AbrahamGreyson 2017-03-15 10:26:26 +08:00 via iPhone 1
用嵌套集合模型重构数据库。
|
15
whahuzhihao 2017-03-15 10:35:49 +08:00
为何不用 mongoDB ?
|
16
hjxx 2017-03-15 10:39:18 +08:00 1
用左右值的方式 见 5 楼的链接
|
17
dangyuluo 2017-03-15 10:52:23 +08:00
|
19
dapeng 2017-03-15 11:04:43 +08:00
#5 楼链接的中的方法受教了,提到的这种 mysql 结构设计思维 nice !
|
20
Immortal 2017-03-15 11:43:24 +08:00
@dangyuluo 应该也适用的 这个左右值如果从属关系变更 新的左右值是可以计算的 如果说层级很深的情况下 相对而言也要多次递归查询之后才能得出新值 但是一般是 读 远大于 写,是可以接受的,具体怎么计算可以研究下,之前做过,三两句话讲不清楚,是个挺有意思的问题
|
21
fuxkcsdn 2017-03-15 12:32:46 +08:00 via iPhone 1
5 楼的左右值方法受教了,得去把数据结构书籍再翻出来细读了
对于真无限级别的场景,这方法真不错 对于有限(或假无限)级别的场景, 8 楼的方法更合适 |
22
lucifer4he 2017-03-15 14:50:52 +08:00 1
你需要 PG 递归查询。
|
23
TJT 2017-03-15 15:10:41 +08:00
之前也做过类似的需求,这是测试代码。把所有 source_id = x 的都取出来,就可以根据 refer_id 重建整棵树了。
https://ws1.sinaimg.cn/large/a95d59d7gy1fdnjiw4d39j20d804tdg6 |
24
TJT 2017-03-15 15:11:06 +08:00
|
26
TJT 2017-03-15 15:11:52 +08:00
|
28
fhefh 2017-03-15 16:19:25 +08:00
先 mark ~~~
|
29
none110 2017-03-15 17:28:32 +08:00 via iPhone
mark 备看
|
30
eamon666 2017-03-15 19:05:16 +08:00
要是以前的话我会用 8 楼的办法来搞,现在可能更趋向于 MONGODB
|
31
Time2 2017-03-15 22:03:59 +08:00
5L 的这个方案, 把数据结构中的树 的关系,联想到 数据库设计,厉害啊!
|