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