大数据量联表操作

[ModiKa2022]

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

[simen513]

最常用的做法是：

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

[ModiKa2022]

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

[ModiKa2022]

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

[kestrelBright]

这种上 es 吧

[jjx]

erp 很难

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

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

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

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

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

[volvo007]

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

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

[flxaq]

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

[feifan19]

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

[lyusantu]

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

[iamzcr]

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

[yiyufxst]

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

[lpn666]

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

[yjfkk]

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

[ModiKa2022]

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

[ModiKa2022]

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

[ModiKa2022]

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

[ModiKa2022]

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

[ModiKa2022]

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

[ModiKa2022]

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

[ModiKa2022]

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