项目背景:
微服务架构、主数据源(oracle)、边缘业务数据源(PostgreSQL)
目前生产几百张表,有的表数据量达到了千万,导致数据库压力非常大,一些查询非常慢
团队人数较多,目前未对SQL有统一的规范,故开启了这次讨论会,谈谈大家的看法
会议纪要:
1、统计大量数据定时任务,建议改用大数据
2、对慢查询进行优化,建议使用es或大数据或改造进行单表查询
3、对核心模块 例如登录 出单 邀新人 佣金结算等模块进行隔离
4、尽量少使用关联查询 数据在业务内进行组装
5、前端可以对数据进行缓存,例如:用户信息
6、数据大表进行梳理,量级大 需要改造
7、定期检查数据的增量 查询访问量,对数据过大的表进行分区分表或PG库改造
8、使用PG库存储非核心数据,减少核心库的压力
9、增加熔断机制 每个后台都需要会定位并熔断接口
10、对非实时性数据 ,可以先统计T-1后查询
11、将cpu占用过多的sql进行处理
12、对慢请求慢sql不走索引的SQL进行追踪 并 处理
13、目前所有请求使用一个库,可以通过业务区分出来,分成多个库
14、一个接口查询信息聚合过多,可以分成多个接口查询
eg:初始化home接口 里面查询的数据太多导致速度慢 可以拆分成多个接口进行处理
15、对于一些需要实时查看的数据,可以先缓存,然后通过通知更新数据
16、开发对于大表的数据要进行认知,少做统计查询
17、查询数据比较大的时候,可以先做统计使用大数据和es进行查询
18、对历史表 关注表的数量级增长,性能比较慢的查询
19、关注数据量的大小,分区是否使用正确
20、一致性要求不高的数据尽量放入缓存
21、需求设计,数据库设计表 设计进行评估
22、数据统计时,对活跃人群定时任务跑 减少全表扫描
23、表数据过大是否可以进行清理
24、减少不必要的索引建立, 索引过多会影响到查询的效率
25、应用划分了模块,建立数据库也划分模块
26、数据量大的标准,什么时候使用PG库 什么时候使用Oracle 需要进行规范 定义
27、较少由于需求变复杂 导致请求的链路过长导致过慢 考虑缩短链路甚至直接请求
28、数据库硬件性能需要监控查看
29、查询数据统一入口,各个模块的数据由各个模块提供
数据库最大连接数,各应用最大的连接数,cpu和io的消耗 数据块的指标 需要统一,团队所有开发都需要清楚认识并落实