大数据量联表操作

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

pg 查询 count 慢，如果限制分页还是挺快的，可以把一些大表单据数据放到 Clickhouse 中，程序里需要处理下，一张表冗余查询出来的数据，初始化数据可以用 DataX

我们几千万几亿，都是连表查询，毫无压力。。。2H4G 阿里云。。。

阿里云 rds 打开慢查询，找到经常运行的慢 sql ，然后让他帮你分析下，一般是能分析出点东西的。

如果查询并发量不大的话，感觉这个页面的内容给 click house 查更方便。如果查询并发量比较大，还是对业务单设置好唯一编号再用 cdc+ES 更方便

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

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

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

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

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

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) 内存之类的数据库 ( 这个我没试过 ,听介绍有可能可以.

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

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

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

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