大数据量联表操作

[ModiKa2022]

公司现在的业务, 总会涉及到连表操作, 百万级的数据, 一联表, 查询会变得的缓慢. 例如订单, 收货单, 入库单, 退货单, 验收单 数据一直在写入 如果涉及到这种情况, 除了冗余存储数据外, 还有什么其他的解决方案吗? 诚恳的咨询下各位

[jjx]

erp 的这种业务形态,用 es 无法解决的

sap 就是干脆搞 hana, 关系数据直接搞内存里

普通人就没有办法了, 除非这个使用习惯有调整

[oneisall8955]

查询字段溶于一张表，详细表其余表走主键

[feifan19]

@ModiKa2022 #38 精髓就在于数据分离，分库分表其实也一样，就是把使用频率较低的数据迁移出去，提高数据查询速度。
分库分表其实也是冷热分离，月别做不了，年别应该是可以的吧

[flxaq]

你们这个业务可以不怎么用动，我们公司几万亿的数据，用 pg 完全没问题。设计下数据库就行了，你这几百万的，研究下索引基本 ok

[ModiKa2022]

@oneisall8955 处理的业务太多了,冗余的数据也很多

[ModiKa2022]

@flxaq 我很好奇你们公司数据库的硬件配置

[caronyan]

用 cdc 预联表打宽做个新表，在新表上把联表查询改成单层的查询就行了，这个数据量延迟也就秒级

[RandomJoke]

基于关系型数据库 能优化的：
1. 首次 fetch 只查 id ，根据 id 最后获取想要的数据
2. 部分冗余，部分卡顿场景具体分析解决
3. 分表，这个要针对业务场景了，有些情况要就是没法分的
4. 冷数据处理，比如几年前的数据，把它迁移走
5. 建立好索引，优化查询语句
基于 CDC：
1. 做个新的宽表，数据仍旧放在 PG
2. 新宽表放到 ES CH 等地方

[wu00]

要是挡不住这个需求的话，赶紧抽数据做宽表吧。

我们的更恶心，相当于要把“订单”、“收货单”、“入库单”、“退货单”等不同类型的单据强行抽象成同一种业务单据供分页查询，并且每个字段可筛选，充分迎合业务人员的需求“一个页面可以把所有事情都干了”。

其实这需求都还好... 最恶心的是产品没想清楚，就潦草设计快速上线，然后三天两头的加字段改字段、改抽象逻辑、刷历史数据，苦的都是开发、测试。

[ModiKa2022]

@wu00 一样, 产品比较模糊, 开发涉及好 model 后, 业务需求变更了

[opzpy]

先查询主表 ，然后多线程查询 join 表，内存连接，如果存在 join 表条件就在这个 join 表的查询结果中过滤掉主表的记录

[changdy]

N 年前也遇到了和楼主同样的情况,数据量不大. 但是 join 之后就的体积就大了.同样也是查询条件分散在不同的表上.
我当时的做法是用 debezium 重新聚合到另外一张表上 .并适当的做 水平&垂直分表, 一个完整的 etl 流程

https://juejin.cn/post/7207410405786484796
https://juejin.cn/post/7323570678690185242

ps 楼上不少同学对复杂查询的经验不太足, 可能是比较幸运的程序员没有接受过复杂 erp 中各种逆天的 sql
1) 推荐 es 的: 虽然 es 是查询引擎 但 es 的查询侧重的并不是点对点查询 ,op 的问题主要在于 join 后的笛卡尔积太大.
2) 分开查询在 join: 如果你的所有条件都在一张表上是没问题的.如果是多张表那肯定还是数据库直接写 join 吧

同时 @yiyufxst 的经验非常好 数仓其实主要优化的还是复杂查询 ,在内存充足的情况下能保证结果尽量能出来.
@jjx 的提到的 hana 的确可以搞一搞..但是就是价格也不菲.

我感觉几条可行的解决方案是 :

1) 自己写一套 etl 流程.制作宽表
2) 不写 etl 了, 直接全量 all in 到关系型数仓中 ,在关系型数仓中进行查询 (不过数仓也很耗费资源 .并且如果将来数据量大,同样也是会查询失败)
3) 内存之类的数据库 ( 这个我没试过 ,听介绍有可能可以.

[Link9898]

按照不同类别计算没有必要精确到明细上面，针对不同的需求去搞不同的处理办法，页面上全量搜索所有数据这特喵不开玩笑么

[lvlongxiang199]

先明确下查询是 AP 还是 TP. 如果根据经过 filter 后, join 的数据量比较少是 TP 否则为 AP. AP 的话用 Doris 之类的 MPP 数据库吧

如果是 TP, 明确下为啥查询慢, join 顺序不对还是没加索引, 如果是前者的话, 通过 join hint 指定下 join 顺序

[ModiKa2022]

@Link9898 那是比较简单的业务场景, 真实的业务场景就是一个大列表, 列表中展示了 30-60 个字段, 每个字段可以单独搜索, 这些字段来自不同的表, 没有开玩笑, ToB 的业务很多就是这些东西

[ModiKa2022]

@changdy 感谢回复, 垂直拆分和水平拆分, 对我们这边的业务不太适用, 现在一直在寻求宽表的解决方案

[Link9898]

@ModiKa2022 我也是搞 ToB 的，，就感觉这样的业务很奇怪，不做限制么，，，所有数据搞到一张大表上数据权限怎么控制，，可以全部查看，，给上层领导看又没有必要精确到每一条明细上，，，

[endershadow]

上 pg 插件 hydra

[mark2025]

统计场景可以考虑单独的一个库跑批或者物化视图

[sead]

@ModiKa2022 PG 不应该这么菜啊，SQL 层面优化是否下足功夫？我测试过单 SQL 10 多张表一起处理（ 70 万单表有多张），整体比分开查快。。。后端减少了请求次数，处理数据所用的内存对象也大量减少；以前经常用 ORM ，怎么写都提升不了性能，后面手撸 SQL 差异肉眼可见