大数据量联表操作

最常用的做法是：

特大数据量的表，按时间做 partition 分表。
查询时分时段查询，再汇总到周、月、年，一级一级汇总。

@thinkwei2012 冗余数据,涉及到很多逻辑上的处理, 对每个列表都要单独冗余数据, 系统比较大, 涉及的查看页面有些多

@simen513 挺好的思路, 现在的问题是, 每个独立的表都是单独的单子,时间是独立的, 如果按照时间分表, 逻辑上很多 join 不好处理

这种上 es 吧

erp 很难

表现在客户查询条件巴不得每个字段都可以用来查询

报表页面必须有小计总计, 使得优化困难

数据一定要实时性, 高度要求数据正确

数据查看需要各种制约,比方说按地区/员工/合作伙伴/部门等等, 不得不联表

当然,这些还仅仅是 erp 变态需求中的一部分

我一直以为是我使用数据库的方法有问题，原来大家也都会遇到类似的问题。不过这里想问问，所谓的查询速度快是多快呢？

对于内部用户，我认为百万级的多个表关联（例如 10 张表），返回 100 条以内的数据的响应时间在 3 秒内算是可以接受。如果面向 toB 用户，那么秒级差不多；而面向 toC 用户，大概要在 100 ms 这个水平？

先看你 pg 硬件配置，我们公司一个表几亿的，pg 连几十个表没什么问题，ssd 的还要做好数据库参数优化，要改成适合 ssd 的参数，让 sql 能走合理的索引，连表关键要看索引是否合理，对应表要看具体业务场景，有时间纬度的可以按时间分区。数据库内存 等参数要合理分配

分库分表，数据缓存，读写分离之类的没什么好说的，
提供一种冷热分离的思路，我们项目中每天凌晨会有一个定时任务，把 7 天前的交易数据压缩为 zip 上传到 Blob 上
7 天内的数据自动查 DB 表，7 天以前的数据都会从 Blob 上下载下来读取到内存后再返回给前台画面
Blob 速度也挺快的，目前系统一切都很正常

PG 百万数据就卡不应该吧 EXPLAIN 一下看看优化优化

百万就卡，要不先看看执行计划？

我们 PG 大表（千万、亿级）连太慢，现在说把 PG 同步到 Starrocks ，SR 大表关联性能还可以，缺点是他复杂查询性能好，简单查询不如 PG 、MySQL 这种关系型数据库

flink cdc 然后 join ，最后吧结果数据写到 es 。转批处理为流处理，upsert 保证数据一致性。 后台查询 es 大表，保证实时。

这不是搜索典型应用场景吗？上 ES

@jjx 现在就是把公司原有的 ERP 功能, 替代掉, ERP 更改总是要找外包处理, 现在在肢解原有的 ERP 系统

@volvo007 主要是 TOB, 查过 1s 的话, 前端会有明显的卡顿

@flxaq 有几张过亿的表, 那是一点儿都不敢连表, 稳定崩的, 现在是好几张百万级的表在关联查询, 卡顿很明显

@flxaq pg 使用的是阿里云, 运维那边的预算有限, 现在主要想的是后端的优化方案

@feifan19 业务上的时效性, 感觉跟你们的不太一样, 一个订单 可以一个月之前下单, 然后下个月才能到达(供应链上的业务, 可以提前很久下单的), 如果单纯的按照几天之前的数据分割, 不满足业务的需求

@lyusantu 好几张百万级别的表关联查询

@iamzcr 好几张百万级别的表关联查询