gp数据库中Appendonly与compresslevel

本文探讨了GP数据库中Appendonly表的应用场景,适合无需更新删除操作、全表扫描访问及固定字段结构的场景。通过特定语法创建压缩表,如使用with(appendonly=true,compresslevel=5),并介绍了关键属性如compresslevel、blocksize和distributedby。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

gp数据库中Appendonly(1)压缩表的应用场景

业务上不需要对表进行更新和删除操作,用truncate + insert 就可以实现业务逻辑
访问表的时候基本上是全表扫描,不需要在表上建立索引
不能经常对表进行加字段或修改字段类型,对Appendonly表加字段比普通表慢很多
(2)语法介绍

建表的时候加上 with(appendonly=true) 就可以指定表是Appendonly表。如果需要建压缩表,则加上 with(appendonly=true,compresslevel=5),其中compresslevel是压缩率,取值为1~9,一般选择5就足够

appendonly=true, orientation=column这两个属性决定了这是列存压缩表。

compresstype: 压缩方式,支持zlip,rte等

compresslevel: 压缩级别,0-9,一般压缩级别为5即可

blocksize: 块大小8KB-2MB, 大小在8192 - 2097152 之间并且是8192的倍数

distributed by(fieldname1,fieldname2) : 分布键可以以多个设置,也可以设置一个,GP会hash分布到不同的segment上

<think>嗯,用户想了解Greenplum数据库的常用关键配置参数及其作用和配置方法。我需要先回忆一下Greenplum的主要配置参数,通常这些参数涉及资源管理、查询优化、并发控制等方面。首先,资源管理相关的参数应该包括内存分配,比如max_statement_mem和statement_mem,这两个参数控制每个查询的内存使用上限。还有gp_vmem_protect_limit,用于防止单个Segment使用过多内存导致OOM。 接下来是并发连接,max_connections和superuser_reserved_connections,这些影响数据库的并发处理能力。需要区分主节点和Segment节点的配置,主节点通常处理更多连接,而Segment节点可能设置较低。 然后是工作负载管理,资源队列如max_resource_queues和资源组的max_resource_groups,可能用于分配不同的资源给用户或组。资源队列的参数比如ACTIVE_STATEMENTS和MEMORY_LIMIT,这些需要根据集群规模调整。 查询优化方面,gp_enable_global_deadlock_detector是处理全局死锁的,尤其在更新操作频繁时需要开启。还有gp_workfile_compression,用于压缩临时文件,节省空间。 日志和错误处理参数如log_statement和log_duration,记录SQL语句和执行时间,帮助调试。gp_max_csv_line_length控制CSV导入的行长,避免超长行问题。 网络和连接超时参数如gp_interconnect_type,可能用UDP或TCP,影响数据传输效率。还有tcp_keepalives_idle保持连接活跃。 维护相关的参数,比如maintenance_work_mem和autovacuum,影响VACUUM和ANALYZE的性能,自动清理是否开启也很重要。 我需要确保每个参数的作用解释清楚,配置建议合理,比如根据内存总量分配statement_mem,或者根据并发需求调整max_connections。同时要注意主节点和Segment节点的不同配置,避免混淆。可能还需要提醒用户某些参数需要重启生效,或者动态设置。最后,检查参数名称的正确性,比如gp_vmem_protect_limit是否正确,以及资源队列和资源组的区别,确保信息准确。</think>Greenplum数据库作为分布式MPP架构的分析型数据库,其核心配置参数可分为资源管理、查询优化、并发控制等类别。以下是关键参数详解及配置建议: --- ### 一、资源管理类参数 1. **max_connections** - 作用:控制Master节点最大客户端连接数 - 配置:默认250,Segment节点建议保持默认值,Master节点可根据应用需求调高(如500-1000) 2. **gp_vmem_protect_limit** - 作用:单个Segment节点内存保护阈值,防止OOM - 配置:建议=物理内存*0.9/最大活跃查询数。例如128GB内存集群,活跃查询10个时设为 `(128*0.9)/10=11GB` 3. **statement_mem** - 作用:单个查询在每个Segment的内存配额 - 公式:`(gp_vmem_protect_limit * .9) / max_expected_concurrent_queries` --- ### 二、查询优化参数 4. **gp_enable_global_deadlock_detector** - 作用:启用全局死锁检测(OLTP场景必开) - 配置:`on`(需重启集群) 5. **gp_workfile_compression** - 作用:压缩溢出到磁盘的临时文件 - 配置:`on`(默认开启,可节省30%+存储空间) --- ### 三、并发控制参数 6. **max_prepared_transactions** - 作用:最大两阶段提交事务数 - 配置:需 >= max_connections(建议设为相同值) 7. **gp_resource_manager** - 作用:资源管理策略(队列模式/组模式) - 可选值:`group`(资源组)或 `queue`(资源队列) --- ### 四、存储参数 8. **gp_default_storage_options** - 作用:控制AO表压缩参数 - 示例配置: ```sql SET gp_default_storage_options = 'appendonly=true, compresstype=zstd, compresslevel=5'; ``` --- ### 五、网络传输参数 9. **gp_interconnect_type** - 作用:数据节点间通信协议 - 推荐值: - 小集群用`udpifc`(低延迟) - 大集群用`tcp`(稳定性优先) --- ### 六、典型配置参考(postgresql.conf) ```conf # 内存管理 gp_vmem_protect_limit = 8192MB # 单个节点内存限制 statement_mem = 1024MB # 单查询内存配额 # 查询优化 gp_enable_global_deadlock_detector = on gp_workfile_compression = on # 并发控制 max_connections = 500 max_prepared_transactions = 500 # 资源管理 gp_resource_manager = group ``` --- ### 配置建议原则: 1. **内存分配**:总内存 = (gp_vmem_protect_limit + 其他进程内存) * Segment数量 2. **IO优化**:结合RAID级别调整`effective_io_concurrency` 3. **监控调整**:通过`pg_top`工具实时监控资源使用 4. **版本差异**:6.x版本推荐使用资源组,4.x版本使用资源队列 修改参数后需执行 `gpstop -u` 重新加载配置(部分参数需`gpstop -ra`重启生效)。建议通过gpconfig工具统一管理集群参数。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

weixin_44352020

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值