GreenPlum系列-6-表设计之存储类型、分布、分区的介绍

文章介绍了Greenplum数据库在创建表时的存储选择,包括堆存储与追加优化存储的适用场景,行存和列存的优缺点及选择依据,以及分布键的选择对性能的影响。此外,还讨论了压缩和分区在数据管理中的作用,以及如何根据业务需求进行合理的表设计。

在实际的生产中创建表之前需要对业务需求分析,包括使用堆存储还是追加优化存储、选择行存还是列存是否需要压缩、分布键的选择、分区的使用。

这章主要介绍以上内容。

一、堆存储(heap storage) 和 追加优化存储(append-optimized storage)

  1. 堆存储

默认存储类型,堆表存储在OLTP类型负载下表现最好,数据会在初始载入后被频繁的修改。适合较小的表,如维度表。

  1. 追加优化存储

在数据仓库环境中的非规范表表现最好。该类表通常被批量加载后只被只读查询访问。如事实表,同时追加优化表对批量数据加载性能有优化,不建议单行insert操作。追加优化表不支持cluster、declare... for update 和触发器。

  1. 堆表和追加表的选择

如果表在后续会有一定的并发的 insert/delete/update 需要选择 堆表;

如果后续只是批量加载且少更新,可选择追加表。

  1. 创建

堆表: create table foo (a int, b text) DISTRIBUTED BY (a);

追加优化表: create table bar (a int, b text) with (appendoptimized=true) DISTRIBUTED BY (a);

二、列存和行存

  1. 列存

适用于在少量列参与计算,同时这些列一旦载入以后极少会更新。

  1. 行存

适用于具有 很多迭代事务的OLTP类型以及一次需要多列的单行,检索性能高;

  1. 行存和列存的选择

表数据的更新,如果频繁装载和更新表数据,选择面向行的堆表;面向列的表只适合追加优化表。

频繁的插入,如果频繁的想表中插入行,选择面向行的模型;列存没有对写操作优化。

查询中要求的列数,如果查询列数或者条件自居中包含所有或大部分列,选择行存;列存适合查询单列汇总或单行过滤。

压缩,列数据具有相同的数据类型,很好的支持压缩。

  1. 创建

面向列

create table bar (a int, b text) with (appendoptimized=true, orientation=column) distributed by (a);

三、分布

  1. 为什么选择使用分布键

所有的join、sort、aggregation 都可以在本地segment 上完成,不需要motion动作在segment之间传递数据。当然这是理想状况,出于对性能的考虑,greenplum 系统所有的数据能够在segment 分布均匀,有利于后续的查询、聚合等操做,更好的利用MPP的并发特性。如果数据分布不均匀,出现数据倾斜,直接影响就是木桶效应,效率低下。默认情况下GP会指定随机分布。

  1. 分布键的类型

gp6支持3种分布类型,分别为 哈希分布、随机分布、复制分布。

哈希分布:默认的分布键。选择一列或多列作为数据表的分布键,通过hash计算,将插入的数据路由到特定的segment上。当建表未定义分布键时,如果表有主键则主键作为默认分布键,如果表无主键,则默认按照第一个字段来分布。

随机分布:数据随机分布在每一个segment上,可以保证数据平均分布,但在执行关联操作时需要将数据重新分布,性能较差。通过distributed randomly 指定,如果表上有主键则不能使用随机分布。

复制分布:每一条记录都会分布到整改集群的所有实例上,通过 DISTRIBUTED REPLICATED 指定。当需要在segment上执行用户自定义的函数,且函数需要访问表中的所有行时使用复制分布,或者 有大小表join 时,把小表指定为复制分布,性能会有提升。

  1. 如何选择分布键

经常需要join的列,选择分布键关联代价会减少。

分布均匀的列或多列,如果没有分布太均匀的字段,则将多个字段进行组合分布。

高并发查询的条件列,如果数据经常被高并发的键值或离散查询,可以将查询条件的列作为分布列。不需要连接到所有的segment 去查,提升并发性能。

不要轻易使用随机分布,如果多表管理会出现查询多节点重分布,效率低下。

不会被修改的字段,分布键不能出现在update语句中。

  1. 分布键的操作

查询数据倾斜:

select gp_segment_id,count(*) from ods_events GROUP BY gp_segment_id;

查看分布键

#\d table;

修改分布键(会重新分布表sales)

ALTER TABLE sales SET DISTRIBUTED BY (customer_id);

修改分布策略(会自动重新分配表数据)

ALTER TABLE sales SET DISTRIBUTED RANDOMLY|REPLICATED;

四、分区

表分区是指数据库在逻辑上划分大表来提升查询性能并有利于数据仓库任务维护。分区不会改变数据在segment之间的物理分布。

  1. 分区策略

小表不建议做分区

分区键和分布键不能是同一个

多级分区最好不要用

对于列存储的表,谨慎使用分区,列存在列级别做了隔离,在每个segment上物理文件个数:列数*分区数,使用分区将使物理文件个数快速增长,增加管理负担。

<think>我们正在讨论Greenplum分区表写入性能瓶颈的监控方法。根据用户的问题,需要提供具体的监控指标、工具方法。同时,用户引用了三篇文档,其中引用[1]提到gpfdistgp_external_max_segs参数,引用[2]提到分区分布策略,引用[3]提到资源组。但用户当前问题聚焦于监控,因此我们需要从监控角度出发,结合Greenplum的特性来回答。监控Greenplum分区表写入性能瓶颈,可以从以下几个层面入手:1.**系统资源监控**:观察CPU、内存、磁盘I/O网络的使用情况,判断是否存在硬件瓶颈。2.**Greenplum内部指标**:通过系统表、视图日志获取查询执行资源使用的详细信息。3.**分区表特定监控**:关注分区剪枝效果、分区锁竞争、分区分布倾斜等。具体方法如下:###📊1.系统级监控指标-**CPU使用率**:通过`gpssh``top`命令监控所有节点(MasterSegment)的CPU使用情况。如果某个Segment的CPU持续过高,可能该分区数据倾斜。-**内存使用**:重点监控`gp_vmem_protect_limit`相关参数,防止内存溢出。通过`gp_resqueue_status`视图查看资源队列的内存使用情况(如果使用资源队列)[^3]。-**磁盘I/O**:使用`iostat`监控磁盘读写速度等待时间。如果写入时磁盘利用率持续100%,说明磁盘成为瓶颈。-**网络流量**:使用`iftop`或`nethogs`监控节点间网络流量。Greenplum在数据写入时,Master会将数据分发到各个Segment,网络带宽不足会影响写入速度。###📈2.Greenplum内置监控工具-**gp_toolkit管理方案**:Greenplum提供了一系列管理视图,位于`gp_toolkit`模式下。-`gp_toolkit.gp_disk_free`:监控磁盘剩余空间。-`gp_toolkit.gp_workfile_usage`:查看临时文件使用情况(如排序、哈希操作溢出到磁盘)[^2]。-`gp_toolkit.gp_workfile_mgr_used_diskspace`:监控所有Segment上工作文件使用的磁盘空间。-`gp_toolkit.__gp_log_segment_ext`:查看Segment的日志(需要先启用日志记录)。-**系统视图**:-`pg_stat_activity`:查看当前活动的写入会话状态,关注`waiting`字段判断是否阻塞。-`pg_locks`:监控锁等待情况,分区表写入时可能因为分区锁竞争导致延迟。-`pg_stat_all_tables`:关注具体表的`n_tup_ins`(插入行数)`n_tup_hot_upd`(热更新行数)等统计信息。###🔍3.分区表写入专项监控-**分区剪枝效果**:通过查询计划检查是否有效剪枝。使用`EXPLAINANALYZE`查看写入语句(如`INSERT`)是否只涉及目标分区。```sqlEXPLAINANALYZEINSERTINTOsales_partitioned(...)VALUES(...);```如果计划中显示扫描了多个分区(特别是默认分区),则剪枝未生效,导致写入效率下降[^2]。-**分区锁竞争**:当多个并发写入操作同一分区时,可能产生锁竞争。通过以下查询检测锁等待:```sqlSELECT*FROMpg_locksWHEREgranted=false;```结合`pg_stat_activity`找到阻塞的会话查询。-**数据分布倾斜**:写入时若某个Segment负载过高,可能是分区键选择不当或分布键倾斜。使用以下查询检查数据倾斜:```sqlSELECTgp_segment_id,count(*)FROMsales_partitioned_1_prt_<分区名>--替换为具体分区名GROUPBYgp_segment_id;```如果某个Segment上的行数明显多于其他,则存在倾斜[^2]。###⚙️4.性能日志分析-**开启详细日志**:在`postgresql.conf`中设置日志级别:```log_statement='all'--记录所有SQLlog_min_duration_statement=1000--记录超过1秒的查询```-**使用gpperfmon**(如果安装):Greenplum的监控组件,收集系统性能数据并存储在`gpperfmon`数据库中。关键表包括:-`metrics_now`:当前性能指标快照。-`metrics_history`:历史性能数据。-重点指标:`disk_usage`(磁盘使用)、`cpu_usage`(CPU使用)、`mem_usage`(内存使用)`net_usage`(网络使用)[^1]。###🛠️5.外部工具-**GPCC(GreenplumCommandCenter)**:商业版图形化监控工具,提供实时性能仪表盘,可直观查看写入速度、资源使用查询状态。-**Prometheus+Grafana**:通过`node_exporter`收集系统指标,使用`postgres_exporter`收集Greenplum指标,在Grafana中展示。###📌关键性能瓶颈点总结|瓶颈类型|监控方法|优化方向||------------------|-----------------------------------|------------------------------||**CPU瓶颈**|`top`命令,Greenplum系统视图|优化查询,减少计算量||**内存瓶颈**|`gp_resqueue_status`,系统内存监控|增加内存,优化内存参数||**磁盘I/O瓶颈**|`iostat`,`gp_toolkit`视图|使用SSD,优化写入批次||**网络瓶颈**|`iftop`,网络流量监控|增加网络带宽,调整分布策略||**锁竞争**|`pg_locks`,`pg_stat_activity`|减少热点分区写入并发||**数据倾斜**|分区表Segment数据分布查询|调整分区键或分布键|通过上述监控手段,可以定位Greenplum分区表写入的性能瓶颈,并针对性地优化。---###📚相关问题1.如何优化Greenplum分区表的写入性能?2.Greenplum中如何设计分区键以避免数据倾斜?3.如何配置Greenplum的资源队列或资源组来管理写入负载?4.使用gpfdist加载数据到分区表时有哪些性能调优技巧?5.如何自动化监控Greenplum集群的写入性能?[^1]:gpfdist是Greenplum提供的一种文件服务器,提供了良好的性能并且非常容易运行。gpfdist利用Greenplum系统中的所有Segment读写外部表。gp_external_max_segs服务器配置参数控制可被单一gpfdist实例同时使用Segment的数量,缺省值为64。[^2]:•目标:确保数据均匀分布在所有节点,避免数据倾斜。•优化策略:•哈希分片:适合均匀分布的场景(如id字段)。sqlCREATETABLEsales(idINT,amountNUMERIC)DISTRIBUTEDBY(id);•范围分片:按时间字段分片,适合时间序列数据。sqlCREATETABLEsales_partitioned(idINT,sale_dateDATE,amountNUMERIC)PARTITIONBYRANGE(sale_date);2.表分区(Partitioning)[^3]:资源组是数据库另外一种管理模式,GP4是没有这个功能,GP5之后的版本才有这个管理模式。它的内存管理模式有2种。一种是基于角色,就是对数据库用户分配资源。另一种是基于外部组件(例如PXF这些)在并发事务限制这块,当资源组内的并发事务达到了设置的限制时,后面的查询会等待。资源组资源队列的区别</think>### 🛠️ Greenplum分区表写入性能瓶颈监控方法 以下为全面监控策略,涵盖系统资源、SQL执行、分区特性三个维度,结合具体工具指标: --- #### 📊 **1. 系统资源级监控** | **监控项** | **工具/方法** | **关键指标** | **瓶颈表现** | |------------------|-------------------------------------------|---------------------------------------------|--------------------------------| | **CPU利用率** | `gpssh` + `top`/`htop` | 各Segment节点CPU > 80% | 计算密集型写入(如分区约束检查) | | **磁盘I/O** | `iostat -x 2` | `await` > 10ms, `%util` > 90% | 分区文件写入延迟 | | **网络流量** | `iftop`/`nethogs` | 主节点->Segment流量不均衡 | 数据分发倾斜(分布键失效) | | **内存压力** | `gp_toolkit.gp_workfile_mgr_*` 视图[^3] | `workfile_bytes` 持续增长 | 分区排序/哈希操作溢出到磁盘 | > **示例命令**: > ```bash > # 监控所有Segment磁盘IO > gpssh -f seg_hosts -e 'iostat -x 2' > ``` --- #### 🔍 **2. SQL执行级监控** **(1)查询计划分析** ```sql EXPLAIN (ANALYZE, VERBOSE) INSERT INTO sales_partitioned ...; ``` 关注关键点: - **分区剪枝效果**:`Partitions scanned: 1 of 365`(理想状态)[^2] - **数据倾斜**:`Slice: Unbalanced` 警告 - **锁等待**:`Lock: RowExclusiveLock` 持续时间 > 100ms **(2)实时会话监控** ```sql SELECT * FROM pg_stat_activity WHERE query LIKE '%INSERT%' AND wait_event_type = 'Lock'; ``` - **关键字段**:`wait_event`, `query_start`, `state` - **阻塞源**:锁定分区的会话ID **(3)性能计数器** ```sql SELECT * FROM gp_toolkit.gp_resqueue_status WHERE rsqname = 'pg_default'; -- 资源队列[^3] ``` - 内存溢出:`memory_used > memory_limit` - 队列堆积:`queue_cur > 0` --- #### 🎯 **3. 分区表专项监控** **(1)分区锁竞争检测** ```sql WITH locks AS ( SELECT relation::regclass AS partition_name, COUNT(*) AS lock_count FROM pg_locks WHERE locktype = 'relation' GROUP BY 1 ) SELECT * FROM locks WHERE lock_count > 5; -- 高竞争分区 ``` **(2)分区数据倾斜分析** ```sql SELECT gp_segment_id, COUNT(*) FROM sales_partitioned_1_prt_p202401 -- 指定分区 GROUP BY 1 ORDER BY 2 DESC; ``` - **危险阈值**:最大/最小Segment数据量差异 > 3倍 **(3)默认分区陷阱** ```sql SELECT count(*) FROM sales_partitioned_1_prt_default; -- 默认分区数据量[^2] ``` - **告警线**:默认分区数据量 > 总数据量的1% --- #### ⚙️ **4. 自动化监控工具链** | **工具** | **功能** | **配置要点** | |------------------------|------------------------------------------|------------------------------------------| | **GPCC** | 官方监控平台 | 设置分区表写入告警规则 | | **Prometheus+Grafana** | 自定义仪表盘 | 采集`pg_stat_partition_operations`指标 | | **pg_partman** | 分区维护扩展 | 日志记录分区自动创建/清理事件 | > **Grafana仪表盘关键面板**: > - 分区级INSERT速率 > -分区磁盘空间占用热力图 > - 分区锁等待时间趋势 --- #### 📌 **性能瓶颈快速定位流程** ```mermaid graph TD A[写入延迟] --> B{检查系统资源} B -->|CPU高| C[分析分区剪枝效果] B -->|I/O高| D[检查分区文件分布] B -->|网络阻塞| E[验证分布键均匀性] C --> F[存在锁竞争?] D --> G[分区数据倾斜?] E --> H[调整分布策略] F --> I[优化并发写入逻辑] G --> J[重建分布键] ``` --- ### 📚 相关问题 1. 如何优化高并发写入场景下的Greenplum分区表锁竞争? 2. 分区表数据倾斜的根本原因及纠正方法有哪些? 3. 如何配置Greenplum资源组(resource group)保障写入SLA?[^3] 4. gpfdist并行加载数据时如何避免分区热点?[^1] 5. 时间分区表的自动维护最佳实践是什么? [^1]: gpfdist是Greenplum提供的一种文件服务器,提供了良好的性能并且非常容易运行。gpfdist利用Greenplum系统中的所有Segment读写外部表。gp_external_max_segs服务器配置参数控制可被单一gpfdist实例同时使用Segment的数量,缺省值为64。 [^2]: 目标:确保数据均匀分布在所有节点,避免数据倾斜。优化策略:哈希分片适合均匀分布的场景(如 id 字段),范围分片按时间字段分片适合时间序列数据。 [^3]: 资源组是数据库另外一种管理模式,GP4是没有这个功能,GP5之后的版本才有这个管理模式。它的内存管理模式有2种。一种是基于角色,就是对数据库用户分配资源。另一种是基于外部组件(例如PXF这些)在并发事务限制这块,当资源组内的并发事务达到了设置的限制时,后面的查询会等待。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值