Greenplum 数据库优化
2024-03-28 10:45:13 0 举报AI智能生成
Greenplum 数据库优化
作者其他创作
大纲/内容
版本升级
5.x 因为表锁的缘故，经常造成任务阻塞
6.x 核心是 锁 优化
AO 表可能不符锁的预期
https://github.com/greenplum-db/gpdb/issues/8362
https://github.com/greenplum-db/gpdb/issues/8362
gprecoverseg --differential
tablefunc
6.24 才支持
pg_trgm
6.20 才支持
不支持
upsert，PG 9.6 内核才支持的功能
SELECT func(id) FROM t;
CREATE TABLE t AS SELECT * FROM func_get_data();
需要修改 func_get_data() 的定义
idle_in_transaction_session_timeout
GPORCA 不支持 Expression Index
7.x 还得等
核心是 并行 优化
尤其是分区表支持了并行扫描
定时 vacuum + analyzedb
针对性 vacuum，切记别全库
增量 analyze
配置优化
内存相关
vm.overcommit_*
vm.dirty_*
vm.swappiness
gp_vmem_protect_limit
maintenance_work_mem
statement_mem
temp_buffers
gp_udp_bufsize_k
WAL日志相关
checkpoint_segment
checkpoint_timeout
超时配置相关
statement_timeout
lock_timeout
连接数相关
max_connections
max_prepared_transactions
引入 pgBouncer
spill files相关
gp_workfile_compression
冷热数据分级存储
热数据存放到SSD磁盘
SSD使用寿命一定要考虑
数据生命周期管理
gpbackup 并行备份，恢复
当前只支持逻辑备份
万兆网卡
最次也得是千兆的
不光要注意网卡，还要留意网线
标注清理已废弃数据
数仓一定要治理，不然就变成垃圾场了
关联条件最好用上分布键
如果用不上，则需要考虑重分布产生的影响
维表可以考虑使用 复制表
GP 6.x 历史版本的复制表有 bug，慎用，请升级到6.23.0+
需要特别留意从 5.x 升级到 6.x 后，分布键分布算法变更引发的效能问题
分区表管理
合理选择字段作为分区键
目的是查询时减少不必要的检索量
合理设置一个分区覆盖的数据范围
别预创建很多分区
对备份以及查询都不太友好
在 UDF 中，将分区表和一个结果集做关联，务必要确认执行计划
若 Where 中指定了分区条件，但还是遍历了全表，请尝试改用动态SQL
临时表管理
数仓里面临时表是必要的，但要注意系统表的膨胀问题
临时表和一个超大表关联，如果临时表数据量超过 800，小心利用不到大表索引
在 UDF 中，对临时表 CUD 之后，推荐手动执行一下 analyse，避免出现一些不符合预期的执行计划
索引
bitmap
索引体积比 btree 小了 10 倍，速度还比以前更快
brin
7.x 新增的索引类型，对于自增字段比较友好
无效索引一定要删，否则会引发奇葩的问题
数据建模
ER 建模落地成本较高，在数仓建设早期不容易落地
维度建模同样需要借鉴 3NF，不是说只有 ER 建模才遵循 3NF
尤其是第一范式，第三范式
反 3NF 的情况，用空间换时间
全量数据写一张表，异常记录再写入另一张表
通过双写优化部分查询业务
视图调整为 实体表 或 物化视图
AO表
列存
复合主键
优化方式可参考雪花算法
定长
可计算
唯一
自增
批处理
Copy
Merge Table
数据批量同步，涉及删除和更新
Kettle ETL 流程优化
通用数据同步功能，落地 GP 入库最佳实践
基于 Kettle 任务执行状态指标，排程优化
CDC 消息入库优化
慎用 CTE Recursive Query，能用 Join 关联一次出来的，千万别递归
查询优化器 optimizer_nestloop_factor
How to constrain the execution plan
https://github.com/greenplum-db/gpdb/blob/6X_STABLE/src/backend/utils/misc/guc_gp.c
https://github.com/greenplum-db/gpdb/issues/14136
set optimizer = off;
GPORCA 不支持范围查询，模糊匹配时使用索引
如果用 GPORCA 遇到一些异常重分布，可以考虑关闭该选项
set enable_nestloop = on
小心报错 ERROR: illegal rescan of motion node: invalid plan (nodeMotion.c:1604) #6769
如果在选择优化器的时候切换到 PostgreSQL 优化器，需要留意该配置项
optimizer_force_multistage_agg
多阶段聚集
optimizer_enable_hashjoin
GPORCA更倾向于HashJoin
测试发现，配置一个大于 1000 的值貌似也不起作用
gp_cte_sharing
optimizer_trace_fallback
Debug 的时候排查问题用
资源队列
依据 QPS 设置合理的资源队列大小，减少阻塞
gp_toolkit.gp_resqueue_status
0 条评论
下一页
