GreenPlum 最佳实践

数据模型

Greenplum数据库是一种shared nothing的分析型MPP数据库。这种模型与高度规范化的/事务型的SMP数据库有显著区别。Greenplum数据库使用非规范化的模式设计会工做得最好，非规范化的模式适合于MPP分析型处理，例如带有大型事实表和较小维度表的星形模式或者雪花模式。

对表中用于链接的列使用相同的数据类型。

 

堆存储 vs. 追加优化存储

对将会接收迭代批量或者单一UPDATE、DELETE以及INSERT操做的表和分区使用堆存储。

对将会接收并发UPDATE、DELETE以及INSERT操做的表和分区使用堆存储。

对于在初始装载后不多更新而且只会在大型批处理操做中进行后续插入的表和分区，使用追加优化存储。

毫不在追加优化表上执行单个INSERT、UPDATE或者DELETE操做。

毫不在追加优化表上执行并发的批量UPDATE或DELETE操做。能够执行并发的批量INSERT操做。

 

行存 vs. 列存

若是负载中有要求更新而且频繁执行插入的迭代事务，则对这种负载使用行存。

在对宽表选择时使用行存。

为通常目的或混合负载使用行存。

选择面很窄（不多的列）和在少许列上计算数据汇集时使用列存。

若是表中有单个列按期被更新而不修改行中的其余列，则对这种表使用列存。

 

压缩

在大型追加优化和分区表上使用压缩以改进系统范围的I/O。

在数据位于的级别上设置列压缩设置。

在较高的压缩级别和压缩解压数据所需的时间和CPU周期之间作出平衡。

 

分布

为全部的表显式定义一个列分布或者随机分布。不要使用默认值。

使用将在全部Segment间均匀分布的单列。

不要在查询的WHERE子句中用到的列上进行分布。

不要在日期或时间戳上分布。

不要在同一列上分布而且分区表。

在常被链接起来的大型表的相同列上进行分布以显著地改进本地链接。

在初始装载数据以及增量装载数据以后验证数据被均匀分布。

根本上确保没有数据倾斜！

 

内存管理

把vm.overcommit_memory设置为2。

不要配置OS使用大页。

使用gp_vmem_protect_limit设置实例能够为每一个Segment数据库中执行的全部工做分配的最大内存。

经过下面的计算为gp_vmem_protect_limit设置值：

gp_vmem – Greenplum数据库可用的总内存

 

其中 SWAP是该主机的交换空间（以GB为单位），RAM是该主机的RAM（以GB为单位）

max_acting_primary_segments – 当镜像Segment因为主机或者Segment失效而被激活时，能在一台主机上运行的最主Segment的最大数量

gp_vmem_protect_limit

 

转换成MB来设置配置参数的值。

在有大量工做文件被生成的场景下用下面的公式计算将工做文件考虑在内的gp_vmem因子：

 

毫不将gp_vmem_protect_limit设置得太高或者比系统上的物理RAM大。

使用计算出的gp_vmem值来计算操做系统参数vm.overcommit_ratio的设置：

 

使用statement_mem来分配每一个Segment数据库中用于一个查询的内存。

使用资源队列设置活动查询的数目（ACTIVE_STATEMENTS）以及队列中查询所能利用的内存量（MEMORY_LIMIT）。

把全部的用户都与一个资源队列关联。不要使用默认的队列。

设置PRIORITY以匹配用于负载以及实际状况的队列的实际须要。

确保资源队列的内存分配不会超过gp_vmem_protect_limit的设置。

动态更新资源队列设置以匹配平常操做流。

 

分区

只对大型表分区。不要分区小表。

只有能基于查询条件实现分区消除（分区剪枝）时才使用分区。

选择范围分区而舍弃列表分区。

基于查询谓词对表分区。

不要在同一列上对表进行分布和分区。

不要使用默认分区。

不要使用多级分区，建立较少的分区让每一个分区中有更多数据。

经过检查查询的EXPLAIN计划验证查询有选择地扫描分区表（分区被消除）。

不要用列存储建立太多分区，由于每一个Segment上的物理文件总数：物理文件数 = Segment数 x 列数 x 分区数

 

索引

一般在Greenplum数据库中无需索引。

对高基数的表在列式表的单列上建立索引用于钻透目的要求查询具备较高的选择度。

不要索引被频繁更新的列。

老是在装载数据到表以前删除索引。在装载后，从新为该表建立索引。

建立具备选择性的B-树索引。

不要在被更新的列上建立位图索引。

不要为惟一列、基数很是高或者很是低的数据使用位图索引。

不要为事务性负载使用位图索引。

一般不要索引分区表。若是须要索引，索引列必须与分区列不一样。

 

资源队列

使用资源队列来管理集群上的负载。

将全部的角色都与一个用户定义的资源队列关联。

使用ACTIVE_STATEMENTS参数限制特定队列的成员能并发运行的活动查询数量。

使用MEMORY_LIMIT参数控制经过队列运行的查询所能利用的总内存量。

不要把全部队列都设置为MEDIUM，由于这实际上没有对负载进行管理。

动态修改资源队列以匹配负载以及现状。

 

监控和维护

实现Greenplum数据库管理员指南中的"推荐的监控和维护任务"。

安装时运行gpcheckperf而且在以后按期运行该工具，保存其输出用来比较系统性能随时间的变化。

使用手头的全部工具来理解系统在不一样负载下的表现。

检查任何异常事件以判断成因。

经过按期运行解释计划监控查询活动以确保查询被以最优的方式运行。

检查计划以判断索引是否被使用以及分区消除是否按照预期发生。

了解系统日志文件的位置和内容而且按期监控它们，而不是只在问题出现时才去检查日志。

 

ANALYZE

不要在整个数据库上运行ANALYZE。须要时，有选择地在表级别上运行ANALYZE。

在装载后老是运行ANALYZE。

在显著改变底层数据的INSERT、UPDATE以及DELETE操做以后老是运行ANALYZE。

在CREATE INDEX操做以后老是运行ANALYZE。

若是在很是大的表上运行ANALYZE须要太长时间，能够只在用于链接条件、WHERE子句、SORT子句、GROUP BY子句或者HAVING子句的列上运行ANALYZE。

 

清扫

在大型UPDATE和DELETE操做后运行VACUUM。

不要运行VACUUM FULL。而是运行一个CREATE TABLE...AS操做，而后重命名而且删掉原始表。

频繁地在系统目录上运行VACUUM以免目录膨胀以及在目录上运行VACUUM FULL的须要。

毫不要杀掉目录表上的VACUUM。

不要运行VACUUM ANALYZE。

 

装载

使用gpfdist在Greenplum数据库中装载或者卸载数据。

随着Segment数目增长最大化并行性。

在尽量多的ETL节点上均匀散布数据。

把很是大型的数据文件分割成相等的部分，而且把数据散布在尽量多的文件系统上。

每一个文件系统运行两个gpfdist实例。

在尽量多的接口上运行gpfdist。

使用gp_external_max_segs以控制每一个gpfdist服务的Segment数量。

老是保持gp_external_max_segs和gpfdist进程的数量为偶因子。

在装载到现有表以前老是删除索引而且在装载以后重建索引。

老是在对表装载以后运行ANALYZE。

在装载期间经过设置gp_autostats_mode为NONE禁用自动统计信息收集。

在装载错误以后运行VACUUM以从新得到空间。

 

gptransfer

为了最快的传输率，使用gptransfer传输数据到尺寸相同或者更大的目标数据库。

避免使用--full或--schema-only选项。而是使用不一样的方法将模式复制到目标数据库中，而后传输表数据。

在传输表以前删除索引而且在传输完成后重建它们。

使用SQL的COPY命令传输较小的表到目标数据库。

使用gptransfer批量传输较大的表。

在执行生产迁移以前，先测试运行gptransfer。用--batch-size和--sub-batch-size选项进行实验以获得最大并行性。为迭代运行gptransfer肯定合适的表批次。

只使用彻底限定的表名称。表名中的点号（.）、空格、引号（'）和双引号（"）均可能形成问题。

若是使用--validation选项在传输后验证数据，肯定也使用-x选项在源表上放置排他锁。

确保在目标数据库上建立每个角色、函数和资源队列。当使用gptransfer -t选项时，这些对象不会被会传输。

将postgres.conf和pg_hba.conf配置文件从源集群拷贝到目标集群。

在目标数据库中用gppkg安装所需的扩展。

 

安全性

保护gpadmin用户ID而且只容许对它进行必需的系统管理员访问。

在执行特定的系统维护任务（例如升级或者扩张）时，管理员只应做为gpadmin登入到Greenplum。

限制具备SUPERUSER角色属性的用户。成为超级用户的角色能绕过Greenplum数据库中的全部访问特权检查以及资源队列。只有系统管理员应该被给予超级用户的权力。请见Greenplum数据库管理员指南中的“修改角色属性”。

数据库用户毫不应该以gpadmin登陆，且ETL或者生产负载也毫不应该以gpadmin运行。

为每一个登入的用户分派一个不一样的角色。

对于应用或者Web服务，考虑为每一个应用或服务建立一个不一样的角色。

使用组管理访问特权。

保护root口令。

为操做系统口令强制一种强口令策略。

确保重要的操做系统文件受到保护。

 

加密

加密和解密数据须要性能做为代价，只加密须要加密的数据。

在生产系统中实现任何加密方案以前，先执行性能测试。

生产Greenplum数据库系统中的服务器证书应该由一个数字证书认证机构（CA）签发，这样客户端能够认证该服务器。若是客户端都是机构中的本地客户端，CA能够是本地的。

只要客户端到Greenplum数据库的链接会经过不安全的连接，就应该对其使用SSL加密。

对称加密方案（加密和解密使用一样的密钥）具备比非对称方案更好的性能，所以在密钥能被安全共享时应当使用对称加密方案。

使用pgcrypto包中的函数来加密磁盘上的数据。数据在数据库进程中被加密和解密，所以有必要用SSL保护客户端链接以免传输未加密数据。

在ETL数据被装载到数据库中或者从数据库中卸载时，是用gpfdists协议加密它。

 

高可用性

使用带有8至24个磁盘的硬件RAID存储方案。

使用RAID 一、5或6，这样磁盘阵列能容忍一个失效的磁盘。

在磁盘阵列中配置一个热后备以容许在检测到磁盘失效时自动开始重建。

经过镜像RAID卷防止重建时整个磁盘阵列失效和退化。

按期监控磁盘使用而且在须要时增长额外的空间。

监控Segment倾斜以确保数据被平均地分布而且在全部Segment上存储被平均地消耗。

设置一个后备Master以便在主Master失效后接管。

规划当失效发生时，如何把客户端切换到新的Master实例，例如，经过更新DNS中的Master地址。

设置监控机制以便在主Master失效时在系统监控应用中或者经过email发出通知。

为全部的Segment设置镜像。

将主Segment和它们的镜像放置在不一样的主机上以预防主机失效。

设置监控机制以便在主Segment失效时在系统监控应用中或者经过email发出通知。

迅速地使用gprecoverseg工具失效的Segment，以便恢复冗余而且让系统回到最佳平衡。

配置Greenplum数据库发送SNMP通知给网络监控器。

在$MASTER_DATA_DIRECTORY/postgresql.conf配置文件中设置email通知，这样Greenplum系统能够在检测到严重问题时用email通知管理员。

考虑双集群配置以提供额外层次上的冗余以及额外的查询处理吞吐。

除非数据库能够很容易地历来源恢复，按期备份Greenplum数据库。

若是堆表相对较小而且两次备份之间只有不多的追加优化或列存分区被修改，使用增量备份。

若是备份被保存到本地集群存储上，在备份完成后将这些文件移动到一个安全的、不在集群上的位置。

若是备份被保存到NFS挂载点，使用例如Dell EMC Isilon之类的横向扩展NFS方案以免IO瓶颈。

考虑使用Greenplum集成将备份流式传送给Dell EMC Data Domain或者 Veritas NetBackup企业级备份平台。

---恢复内容结束---

数据模型

Greenplum数据库是一种shared nothing的分析型MPP数据库。这种模型与高度规范化的/事务型的SMP数据库有显著区别。Greenplum数据库使用非规范化的模式设计会工做得最好，非规范化的模式适合于MPP分析型处理，例如带有大型事实表和较小维度表的星形模式或者雪花模式。

对表中用于链接的列使用相同的数据类型。

 

堆存储 vs. 追加优化存储

对将会接收迭代批量或者单一UPDATE、DELETE以及INSERT操做的表和分区使用堆存储。

对将会接收并发UPDATE、DELETE以及INSERT操做的表和分区使用堆存储。

对于在初始装载后不多更新而且只会在大型批处理操做中进行后续插入的表和分区，使用追加优化存储。

毫不在追加优化表上执行单个INSERT、UPDATE或者DELETE操做。

毫不在追加优化表上执行并发的批量UPDATE或DELETE操做。能够执行并发的批量INSERT操做。

 

行存 vs. 列存

若是负载中有要求更新而且频繁执行插入的迭代事务，则对这种负载使用行存。

在对宽表选择时使用行存。

为通常目的或混合负载使用行存。

选择面很窄（不多的列）和在少许列上计算数据汇集时使用列存。

若是表中有单个列按期被更新而不修改行中的其余列，则对这种表使用列存。

 

压缩

在大型追加优化和分区表上使用压缩以改进系统范围的I/O。

在数据位于的级别上设置列压缩设置。

在较高的压缩级别和压缩解压数据所需的时间和CPU周期之间作出平衡。

 

分布

为全部的表显式定义一个列分布或者随机分布。不要使用默认值。

使用将在全部Segment间均匀分布的单列。

不要在查询的WHERE子句中用到的列上进行分布。

不要在日期或时间戳上分布。

不要在同一列上分布而且分区表。

在常被链接起来的大型表的相同列上进行分布以显著地改进本地链接。

在初始装载数据以及增量装载数据以后验证数据被均匀分布。

根本上确保没有数据倾斜！

 

内存管理

把vm.overcommit_memory设置为2。

不要配置OS使用大页。

使用gp_vmem_protect_limit设置实例能够为每一个Segment数据库中执行的全部工做分配的最大内存。

经过下面的计算为gp_vmem_protect_limit设置值：

gp_vmem – Greenplum数据库可用的总内存

 

其中 SWAP是该主机的交换空间（以GB为单位），RAM是该主机的RAM（以GB为单位）

max_acting_primary_segments – 当镜像Segment因为主机或者Segment失效而被激活时，能在一台主机上运行的最主Segment的最大数量

gp_vmem_protect_limit

 

转换成MB来设置配置参数的值。

在有大量工做文件被生成的场景下用下面的公式计算将工做文件考虑在内的gp_vmem因子：

 

毫不将gp_vmem_protect_limit设置得太高或者比系统上的物理RAM大。

使用计算出的gp_vmem值来计算操做系统参数vm.overcommit_ratio的设置：

 

使用statement_mem来分配每一个Segment数据库中用于一个查询的内存。

使用资源队列设置活动查询的数目（ACTIVE_STATEMENTS）以及队列中查询所能利用的内存量（MEMORY_LIMIT）。

把全部的用户都与一个资源队列关联。不要使用默认的队列。

设置PRIORITY以匹配用于负载以及实际状况的队列的实际须要。

确保资源队列的内存分配不会超过gp_vmem_protect_limit的设置。

动态更新资源队列设置以匹配平常操做流。

 

分区

只对大型表分区。不要分区小表。

只有能基于查询条件实现分区消除（分区剪枝）时才使用分区。

选择范围分区而舍弃列表分区。

基于查询谓词对表分区。

不要在同一列上对表进行分布和分区。

不要使用默认分区。

不要使用多级分区，建立较少的分区让每一个分区中有更多数据。

经过检查查询的EXPLAIN计划验证查询有选择地扫描分区表（分区被消除）。

不要用列存储建立太多分区，由于每一个Segment上的物理文件总数：物理文件数 = Segment数 x 列数 x 分区数

 

索引

一般在Greenplum数据库中无需索引。

对高基数的表在列式表的单列上建立索引用于钻透目的要求查询具备较高的选择度。

不要索引被频繁更新的列。

老是在装载数据到表以前删除索引。在装载后，从新为该表建立索引。

建立具备选择性的B-树索引。

不要在被更新的列上建立位图索引。

不要为惟一列、基数很是高或者很是低的数据使用位图索引。

不要为事务性负载使用位图索引。

一般不要索引分区表。若是须要索引，索引列必须与分区列不一样。

 

资源队列

使用资源队列来管理集群上的负载。

将全部的角色都与一个用户定义的资源队列关联。

使用ACTIVE_STATEMENTS参数限制特定队列的成员能并发运行的活动查询数量。

使用MEMORY_LIMIT参数控制经过队列运行的查询所能利用的总内存量。

不要把全部队列都设置为MEDIUM，由于这实际上没有对负载进行管理。

动态修改资源队列以匹配负载以及现状。

 

监控和维护

实现Greenplum数据库管理员指南中的"推荐的监控和维护任务"。

安装时运行gpcheckperf而且在以后按期运行该工具，保存其输出用来比较系统性能随时间的变化。

使用手头的全部工具来理解系统在不一样负载下的表现。

检查任何异常事件以判断成因。

经过按期运行解释计划监控查询活动以确保查询被以最优的方式运行。

检查计划以判断索引是否被使用以及分区消除是否按照预期发生。

了解系统日志文件的位置和内容而且按期监控它们，而不是只在问题出现时才去检查日志。

 

ANALYZE

不要在整个数据库上运行ANALYZE。须要时，有选择地在表级别上运行ANALYZE。

在装载后老是运行ANALYZE。

在显著改变底层数据的INSERT、UPDATE以及DELETE操做以后老是运行ANALYZE。

在CREATE INDEX操做以后老是运行ANALYZE。

若是在很是大的表上运行ANALYZE须要太长时间，能够只在用于链接条件、WHERE子句、SORT子句、GROUP BY子句或者HAVING子句的列上运行ANALYZE。

 

清扫

在大型UPDATE和DELETE操做后运行VACUUM。

不要运行VACUUM FULL。而是运行一个CREATE TABLE...AS操做，而后重命名而且删掉原始表。

频繁地在系统目录上运行VACUUM以免目录膨胀以及在目录上运行VACUUM FULL的须要。

毫不要杀掉目录表上的VACUUM。

不要运行VACUUM ANALYZE。

 

装载

使用gpfdist在Greenplum数据库中装载或者卸载数据。

随着Segment数目增长最大化并行性。

在尽量多的ETL节点上均匀散布数据。

把很是大型的数据文件分割成相等的部分，而且把数据散布在尽量多的文件系统上。

每一个文件系统运行两个gpfdist实例。

在尽量多的接口上运行gpfdist。

使用gp_external_max_segs以控制每一个gpfdist服务的Segment数量。

老是保持gp_external_max_segs和gpfdist进程的数量为偶因子。

在装载到现有表以前老是删除索引而且在装载以后重建索引。

老是在对表装载以后运行ANALYZE。

在装载期间经过设置gp_autostats_mode为NONE禁用自动统计信息收集。

在装载错误以后运行VACUUM以从新得到空间。

 

gptransfer

为了最快的传输率，使用gptransfer传输数据到尺寸相同或者更大的目标数据库。

避免使用--full或--schema-only选项。而是使用不一样的方法将模式复制到目标数据库中，而后传输表数据。

在传输表以前删除索引而且在传输完成后重建它们。

使用SQL的COPY命令传输较小的表到目标数据库。

使用gptransfer批量传输较大的表。

在执行生产迁移以前，先测试运行gptransfer。用--batch-size和--sub-batch-size选项进行实验以获得最大并行性。为迭代运行gptransfer肯定合适的表批次。

只使用彻底限定的表名称。表名中的点号（.）、空格、引号（'）和双引号（"）均可能形成问题。

若是使用--validation选项在传输后验证数据，肯定也使用-x选项在源表上放置排他锁。

确保在目标数据库上建立每个角色、函数和资源队列。当使用gptransfer -t选项时，这些对象不会被会传输。

将postgres.conf和pg_hba.conf配置文件从源集群拷贝到目标集群。

在目标数据库中用gppkg安装所需的扩展。

 

安全性

保护gpadmin用户ID而且只容许对它进行必需的系统管理员访问。

在执行特定的系统维护任务（例如升级或者扩张）时，管理员只应做为gpadmin登入到Greenplum。

限制具备SUPERUSER角色属性的用户。成为超级用户的角色能绕过Greenplum数据库中的全部访问特权检查以及资源队列。只有系统管理员应该被给予超级用户的权力。请见Greenplum数据库管理员指南中的“修改角色属性”。

数据库用户毫不应该以gpadmin登陆，且ETL或者生产负载也毫不应该以gpadmin运行。

为每一个登入的用户分派一个不一样的角色。

对于应用或者Web服务，考虑为每一个应用或服务建立一个不一样的角色。

使用组管理访问特权。

保护root口令。

为操做系统口令强制一种强口令策略。

确保重要的操做系统文件受到保护。

 

加密

加密和解密数据须要性能做为代价，只加密须要加密的数据。

在生产系统中实现任何加密方案以前，先执行性能测试。

生产Greenplum数据库系统中的服务器证书应该由一个数字证书认证机构（CA）签发，这样客户端能够认证该服务器。若是客户端都是机构中的本地客户端，CA能够是本地的。

只要客户端到Greenplum数据库的链接会经过不安全的连接，就应该对其使用SSL加密。

对称加密方案（加密和解密使用一样的密钥）具备比非对称方案更好的性能，所以在密钥能被安全共享时应当使用对称加密方案。

使用pgcrypto包中的函数来加密磁盘上的数据。数据在数据库进程中被加密和解密，所以有必要用SSL保护客户端链接以免传输未加密数据。

在ETL数据被装载到数据库中或者从数据库中卸载时，是用gpfdists协议加密它。

 

高可用性

使用带有8至24个磁盘的硬件RAID存储方案。

使用RAID 一、5或6，这样磁盘阵列能容忍一个失效的磁盘。

在磁盘阵列中配置一个热后备以容许在检测到磁盘失效时自动开始重建。

经过镜像RAID卷防止重建时整个磁盘阵列失效和退化。

按期监控磁盘使用而且在须要时增长额外的空间。

监控Segment倾斜以确保数据被平均地分布而且在全部Segment上存储被平均地消耗。

设置一个后备Master以便在主Master失效后接管。

规划当失效发生时，如何把客户端切换到新的Master实例，例如，经过更新DNS中的Master地址。

设置监控机制以便在主Master失效时在系统监控应用中或者经过email发出通知。

为全部的Segment设置镜像。

将主Segment和它们的镜像放置在不一样的主机上以预防主机失效。

设置监控机制以便在主Segment失效时在系统监控应用中或者经过email发出通知。

迅速地使用gprecoverseg工具失效的Segment，以便恢复冗余而且让系统回到最佳平衡。

配置Greenplum数据库发送SNMP通知给网络监控器。

在$MASTER_DATA_DIRECTORY/postgresql.conf配置文件中设置email通知，这样Greenplum系统能够在检测到严重问题时用email通知管理员。

考虑双集群配置以提供额外层次上的冗余以及额外的查询处理吞吐。

除非数据库能够很容易地历来源恢复，按期备份Greenplum数据库。

若是堆表相对较小而且两次备份之间只有不多的追加优化或列存分区被修改，使用增量备份。

若是备份被保存到本地集群存储上，在备份完成后将这些文件移动到一个安全的、不在集群上的位置。

若是备份被保存到NFS挂载点，使用例如Dell EMC Isilon之类的横向扩展NFS方案以免IO瓶颈。

考虑使用Greenplum集成将备份流式传送给Dell EMC Data Domain或者 Veritas NetBackup企业级备份平台。