1、 介绍本文介绍 Pivotal Greenplum Database 数据库（以下简称：Greenplum 数据库，或GPDB）的最佳实践。最佳实践是指能持续产生比其他方法更好结果的方法或者技术，它来自于实战经验，并被证实了遵循这些方法可以获得可靠的预期结果。本最佳实践旨在通过利用所有可能的知识和技术为正确使用 GPDB 提供有效参考。本文不是在教您如何使用 Greenplum 数据库的功能，而是帮助您在设计、实现和使用Greenplum 数据库时了解需要遵循哪些最佳实践。关于如何使用和实现具体的 Greenplum数据库特性，请参考 http:/gpdb.docs.pivotal.io 上的
2、 Greenplum 数据库帮助文档以及http:/greenplum.org 上的 Sandbox 和实践指南。本文目的不是要涵盖整个产品或者产品特性，而是概述 GPDB 实践中最重要的因素。本文不涉及依赖于 GPDB 具体特性的边缘用例，后者需要精通数据库特性和您的环境，包括SQL 访问、查询执行、并发、负载和其他因素。通过掌握这些最佳实践知识，会增加 GPDB 集群在维护、支持、性能和可扩展性等方面的成功率。第一章 最佳实践概述本部分概述了 Greenplum 数据库最佳实践所涉及的概念与要点。数据模型GPDB 是一个基于大规模并行处理(MPP)和无共享架构的分析型数据库。这种数据库的数
3、据模式与高度规范化的事务性 SMP 数据库显著不同。通过使用非规范化数据库模式，例如具有大事实表和小维度表的星型或者雪花模式，GPDB 在处理 MPP 分析型业务时表现优异。跨表关联(JOIN)时字段使用相同的数据类型。详见数据库模式设计（后续章节)堆存储和追加优化存储(Append-Optimized ，下称 AO)若表和分区表需要进行迭代式的批处理或者频繁执行单个 UPDATE、DELETE 或 INSERT操作，使用堆存储。若表和分区表需要并发执行 UPDATE、DELETE 或 INSERT 操作，使用堆存储。若表和分区表在数据初始加载后更新不频繁，且仅以批处理方式插入数据，则使用 A
4、O 存储。不要对 AO 表执行单个 INSERT、UPDATE 或 DELETE 操作。不要对 AO 表执行并发批量 UPDATE 或 DELETE 操作，但可以并发执行批量 INSERT 操作。详见堆存储和 AO 存储（后续章节 )行存储和列存储若数据需要经常更新或者插入，则使用行存储。若需要同时访问一个表的很多字段，则使用行存储。对于通用或者混合型业务，建议使用行存储。若查询访问的字段数目较少，或者仅在少量字段上进行聚合操作，则使用列存储。若仅常常修改表的某一字段而不修改其他字段，则使用列存储。详见行存储和列存储（后续章节)压缩对于大 AO 表和分区表使用压缩，以提高系统 I/O。在字段级
5、别配置压缩。考虑压缩比和压缩性能之间的平衡。详见压缩（后续章节)分布为所有表定义分布策略：要么定义分布键，要么使用随机分布。不要使用缺省分布方式。优先选择可均匀分布数据的单个字段做分布键。不要选择经常用于 WHERE 子句的字段做分布键。不要使用日期或时间字段做分布键。分布键和分区键不要使用同一字段。对经常执行 JOIN 操作的大表，优先考虑使用关联字段做分布键，尽量做到本地关联，以提高性能。数据初始加载后或者每次增量加载后，检查数据分布是否均匀。尽可能避免数据倾斜。详见分布（后续章节)内存管理设置 vm.overcommit_memory 为 2不要为操作系统的页设置过大的值使用 gp_vm
6、em_protect_limit 设置单个节点数据库（Segment Database）可以为所有查询分配的最大内存量。不要设置过高的 gp_vmem_protect_limit 值，也不要大于系统的物理内存。gp_vmem_protect_limit 的建议值计算公式为： (SWAP + (RAM * vm.overcommit_ratio) * 0.9 / number_Segments_per_server使用 statement_mem 控制节点数据库为单个查询分配的内存量。使用资源队列设置队列允许的当前最大查询数（ACTIVE_STATEMENTS）和允许使用的内存大小（MEMORY
7、_LIMIT ）。不要使用默认的资源队列，为所有用户都分配资源队列。根据负载和时间段，设置和队列实际需求相匹配的优先级（PRIORITY）。保证资源队列的内存配额不超过 gp_vmem_protect_limit。动态更新资源队列配置以适应日常工作需要。详见内存和负载管理（后续章节)分区只为大表设置分区，不要为小表设置分区。仅在根据查询条件可以实现分区裁剪时使用分区表。建议优先使用范围 (Range) 分区，否则使用列表 (List) 分区。根据查询特点合理设置分区。不要使用相同的字段即做分区键又做分布键。不要使用默认分区。避免使用多级分区；尽量创建少量的分区，每个分区的数据更多些。通过查询计
8、划的 EXPLAIN 结果来验证查询对分区表执行的是选择性扫描 （分区裁剪）。对于列存储的表，不要创建过多的分区，否则会造成物理文件过多： Physical files = Segments * Columns * Partitions。详见分区（后续章节)索引一般来说 GPDB 中索引不是必需的。对于高基数的列存储表，如果需要遍历且查询选择性较高，则创建单列索引。频繁更新的列不要建立索引。在加载大量数据之前删除索引，加载结束后再重新创建索引。优先使用 B 树索引。不要为需要频繁更新的字段创建位图索引。不要为唯一性字段，基数非常高或者非常低的字段创建位图索引。不要为事务性负载创建位图索引。一般
9、来说不要索引分区表。如果需要建立索引，则选择与分区键不同的字段。详见索引（后续章节)资源队列使用资源队列管理集群的负载。为所有角色定义适当的资源队列。使用 ACTIVE_STATEMENTS 参数限制队列成员可以并发运行的查询总数。使用 MEMORY_LIMIT 参数限制队列中查询可以使用的内存总量。不要设置所有队列为 MEDIUM，这样起不到管理负载的作用。根据负载和时间段动态调整资源队列。详见配置资源队列（后续章节)监控和维护根据Greenplum 数据库管理员指南 实现该书推荐的监控和管理任务。安装 Greenplum 数据库前建议运行 gpcheckperf，安装后定期运行。保存输出结
10、果，随着时间推移对系统性能进行比较。使用所有您可用的工具，以了解系统不同负载下的表现。检查任何不寻常的事件并确定原因。通过定期运行解释计划监控系统查询活动，以确保查询处于最佳运行状态。检查查询计划，以确定是否按预期使用了索引和进行了分区裁剪。了解系统日志文件的位置和内容，定期监控日志文件，而不是在出现问题时才查看。详见系统监控和维护以及监控 GPDB 日志文件。（后续章节 )ANALYZE不要对整个数据库运行 ANALYZE，只对需要的表运行该命令。建议数据加载后即刻运行 ANALYZE。如果 INSERT、UPDATE 和 DELETE 等操作修改大量数据，建议运行 ANALYZE。执行 C
11、REATE INDEX 操作后建议运行 ANALYZE。如果对大表 ANALYZE 耗时很久，则只对 JOIN 字段、WHERE、SORT、GROUP BY 或 HAVING 字句的字段运行 ANALYZE。详见使用 ANALYZE 更新统计信息。（后续章节)Vaccum批量 UPDATE 和 DELETE 操作后建议执行 VACUUM。不建议使用 VACUUM FULL。建议使用 CTAS（CREATE TABLE.AS） 操作，然后重命名表名，并删除原来的表。对系统表定期运行 VACUUM，以避免系统表臃肿和在系统表上执行 VACUUM FULL 操作。禁止杀死系统表的 VACUUM 任务
12、。不建议使用 VACUUM ANALYZE。详见消除系统表臃肿。（后续章节)加载使用 gpfdist 进行数据的加载和导出。随着段数据库个数的增加，并行性增加。尽量将数据均匀地分布到多个 ETL 节点上。将非常大的数据文件切分成相同大小的块，并放在尽量多的文件系统上。一个文件系统运行两个 gpfdist 实例。在尽可能多的网络接口上运行 gpfdsit。使用 gp_external_max_segs 控制访问每个 gpfdist 服务器的段数据库的个数。建议 gp_external_max_segs 的值 和 gpfdist 进程个数为偶数。数据加载前删除索引；加载完后重建索引。数据加载完成后
13、运行 ANALYZE 操作。数据加载过程中，设置 gp_autostats_mode 为 NONE，取消统计信息的自动收集。若数据加载失败，使用 VACUUM 回收空间。详见加载数据。（后续章节)gptransfer为了更好的性能，建议使用 gptransfer 迁移数据到相同大小或者更大的集群。避免使用 -full 或者 -schema-only 选项。建议使用其他方法拷贝数据库模式到目标数据库，然后迁移数据。迁移数据前删除索引，迁移完成后重建索引。使用 SQL COPY 命令迁移小表到目标数据库。使用 gptransfer 批量迁移大表。在正式迁移生产环境前测试运行 gptransfer。
14、试验 -batch-size 和 -sub-batch-size 选项以获得最大平行度。如果需要，迭代运行多次 gptransfer 来确定每次要迁移的表的批次。仅使用完全限定的表名。表名字中若含有点、空格、单引号和双引号，可能会导致问题。如果使用 -validation 选项在迁移后验证数据，则需要同时使用 -x 选项，以在源表上加排它锁。确保在目标数据库上创建了相应的角色、函数和资源队列。gptransfer -t 不会迁移这些对象。从源数据库拷贝 postgres.conf 和 pg_hba.conf 到目标数据库集群。使用 gppkg 在目标数据库上安装需要的扩展。详见使用 gptra
15、nsfer 迁移数据（后续章节)安全妥善保护 gpadmin 账号，只有在必要的时候才能允许系统管理员访问它。仅当执行系统维护任务（例如升级或扩容），管理员才能以 gpadmin 登录 Greenplum 集群。限制具有 SUPERUSER 角色属性的用户数。 GPDB 中，身为超级用户的角色会跳过所有访问权限检查和资源队列限制。仅有系统管理员具有数据库超级用户权限。参考Greenplum 数据库管理员指南 中的“ 修改角色属性”。严禁数据库用户以 gpadmin 身份登录，严禁以 gpadmin 身份执行 ETL 或者生产任务。为有登录需求的每个用户都分配一个不同的角色。考虑为每个应用或者网
16、络服务分配一个不同的角色。使用用户组管理访问权限。保护好 ROOT 的密码。对于操作系统密码，强制使用强密码策略。确保保护好操作系统的重要文件。详见安全。（后续章节)加密加密和解密数据会影响性能，仅加密需要加密的数据。在生产系统中实现任何加密解决方案之前都要做性能测试。GPDB 生产系统使用的服务器证书应由证书签名颁发机构（CA）签名，这样客户端可以验证服务器。如果所有客户端都是本地的，则可以使用本地 CA。如果客户端与 GPDB 的连接会经过不安全的链路，则使用 SSL 加密。加密和解密使用相同密钥的对称加密方式比非对称加密具有更好的性能，如果密钥可以安全共享，则建议使用对称加密方式。使用
17、pgcrypto 包中的函数加密磁盘上的数据。数据的加密和解密都由数据库进程完成，为了避免传输明文数据，需要使用 SSL 加密客户端和数据库间的连接。数据加载和导出时，使用 gpfdists 协议保护 ETL 数据安全。详见加密数据和数据库连接。（后续章节)高可用使用 8 到 24 个磁盘的硬件 RAID 存储解决方案。使用 RAID1、 5 或 6，以使磁盘阵列可以容忍磁盘故障。为磁盘阵列配备热备磁盘，以便在检测到磁盘故障时自动开始重建。在重建时通过 RAID 卷镜像防止整个磁盘阵列故障和性能下降。定期监控磁盘利用率，并在需要时增加额外的空间。定期监控段数据库倾斜，以确保在所有段数据库上数据
18、均匀分布，存储空间均匀消耗。配置备用主服务器，当主服务器发生故障时由备用主服务器接管。规划好当主服务器发生故障时如何切换客户端连接到新的主服务器实例，例如通过更新DNS 中主服务器的地址。建立监控系统，当主服务器发生故障时，可以通过系统监控应用或电子邮件发送通知。分配主段数据库和其镜像到不同的主机上，以防止主机故障。建立监控系统，当主段数据库发生故障时，可以通过系统监控应用或电子邮件发送通知。使用 gprecoverseg 工具及时恢复故障段，并使系统返回最佳平衡状态。在主服务器上配置并运行 gpsnmpd 以发送 SNMP 通知给网络监控器。在 $Master_DATA_DIRECTORY/
19、postgresql.conf 配置文件中设置邮件通知，以便检测到关键问题时，Greenplum 系统可以通过电子邮件通知管理员。考虑双集群配置，提供额外的冗余和查询处理能力。除非 Greenplum 数据库的数据很容易从数据源恢复，否则定期备份。如果堆表相对较小，或者两次备份之间仅有少量 AO 或列存储分区有变化，则使用增量备份。如果备份保存在集群的本地存储系统上，则备份结束后，将文件移到其他的安全存储系统上。如果备份保存到 NFS 中，则建议使用像 EMC Isilon 这样的可扩展 NFS 方案以防止 I/O瓶颈。Greenplum 集成了对 EMC 的 Data Domain 和 Sy
20、mantec 的 NetBackup 的支持，可以流式备份到 Data Domain 或 NetBackup 企业备份平台上。详见高可用性（后续章节)第二章 系统配置本节描述了 Greenplum 数据库集群关于主机配置的需求和最佳实践。 首选操作系统红帽企业级 Linux（RHEL）是首选操作系统。应使用最新支持的主版本，目前是 RHEL 6。 文件系统Greenplum 数据库的数据目录推荐使用 XFS 文件系统。使用以下选项挂载 XFS：rw,noatime,inode64,allocsize=16m 端口配置ip_local_port_range 的设置不要和 Greenplum 数据
21、库的端口范围有冲突，例如：net.ipv4.ip_local_port_range = 3000 65535PORT_BASE=2000MIRROR_PORT_BASE=2100REPLICATION_PORT_BASE=2200MIRROR_REPLICATION_PORT_BASE=2300 I/O 配置包含数据目录的设备的预读大小应设为 16384./sbin/blockdev -getra /dev/sdb16384包含数据目录的设备的 I/O 调度算法设置为 deadline。# cat /sys/block/sdb/queue/schedulernoop anticipatory
22、deadline cfq通过 /etc/security/limits.conf 增大操作系统文件数和进程数。* soft nofile 65536* hard nofile 65536* soft nproc 131072* hard nproc 131072启用 core 文件转储，并保存到已知位置。确保 limits.conf 中允许的 core 转储文件。kernel.core_pattern = /var/core/core.%h.%t# grep core /etc/security/limits.conf* soft core unlimited 操作系统内存配置Linux sy
23、sctl 的 vm.overcommit_memory 和 vm.overcommit_ratio 变量会影响操作系统对内存分配的管理。这些变量应该设置如下： vm.overcommit_memory 控制操作系统使用什么方法确定分配给进程的内存总数。对于Greenplum 数据库，唯一建议值是 2. vm.overcommit_ratio 控制分配给应用程序进程的内存百分比。建议使用缺省值 50.不要启用操作系统的大内存页。详见内存和负载管理。（后续章节) 共享内存设置Greenplum 数据库中同一数据库实例的不同 postgres 进程间通讯使用共享内存。使用sysctl 配置如下共享内
24、存参数，且不建议修改：kernel.shmmax = 500000000kernel.shmmni = 4096kernel.shmall = 4000000000 验证操作系统使用 gpcheck 验证操作系统配置。参考 Greenplum 数据库工具指南中的 gpcheck。 设置一个主机上段数据库个数确定每个段主机上段数据库的个数对整体性能有着巨大影响。这些段数据库之间共享主机的 CPU 核、内存、网卡等，且和主机上的所有进程共享这些资源。过高地估计每个服务器上运行的段数据库个数，通常是达不到最优性能的常见原因之一。以下因素确定了一个主机上可以运行多少个段数据库： CPU 核的个数 物理
25、内存容量 网卡个数及速度 存储空间 主段数据库和镜像共存 主机是否运行 ETL 进程 主机上运行的非 Greenplum 进程 段服务器内存配置服务器配置参数 gp_vmem_protect_limit 控制了每个段数据库为所有运行的查询分配的内存总量。如果查询需要的内存超过此值，则会失败。使用下面公式确定合适的值：(swap + (RAM * vm.overcommit_ratio) * .9 / number_of_Segments_per_server例如，具有下面配置的段服务器： 8GB 交换空间 128GB 内存 vm.overcommit_ratio = 50 8 个段数据库则设置
26、 gp_vmem_protect_limit 为 8GB：(8 + (128 * .5) * .9 / 8 = 8 GB参见 内存和负载管理。（后续章节 ) SQL 语句内存配置服务器配置参数 gp_statement_mem 控制段数据库上单个查询可以使用的内存总量。如果语句需要更多内存，则会溢出数据到磁盘。用下面公式确定合适的值：(gp_vmem_protect_limit * .9) / max_expected_concurrent_queries例如，如果并发度为 40， gp_vmeme_protect_limit 为 8GB，则 gp_statement_mem 为：(8192M
27、B * .9) / 40 = 184MB每个查询最多可以使用 184MB 内存，之后将溢出到磁盘。若想安全的增大 gp_statement_mem，要么增大 gp_vmem_protect_limit，要么降低并发。要增大 gp_vmem_protect_limit，必须增加物理内存和/或交换空间，或者降低单个主机上运行的段数据库个数。请注意，为集群添加更多的段数据库实例并不能解决内存不足的问题，除非引入更多新主机来降低了单个主机上运行的段数据库的个数。了解什么是溢出文件。了解 gp_workfile_limit_files_per_query 参数，其控制了单个查询最多可以创建多少个溢出文件
28、。了解 gp_workfile_limit_per_Segment。有关使用资源队列管理内存的更多信息，请参考 内存和负载管理。（后续章节) 溢出文件配置如果为 SQL 查询分配的内存不足，Greenplum 数据库会创建溢出文件（也叫工作文件）。在默认情况下，一个 SQL 查询最多可以创建 100000 个溢出文件，这足以满足大多数查询。参数 gp_workfile_limit_files_per_query 决定了一个查询最多可以创建多少个溢出文件。0 意味着没有限制。限制溢出文件数据可以防止失控查询破坏整个系统。如果分配内存不足或者出现数据倾斜，则一个 SQL 查询可能产生大量溢出文件。
29、如果超过溢出文件上限，Greenplum 数据库报告如下错误：ERROR: number of workfiles per query limit exceeded在尝试增大 gp_workfile_limit_files_per_query 前，先尝试通过修改 SQL、数据分布策略或者内存配置以降低溢出文件个数。gp_toolkit 模式包括一些视图，通过这些视图可以看到所有使用溢出文件的查询的信息。这些信息有助于故障排除和调优查询： gp_workfile_entries 视图的每一行表示一个正在使用溢出文件的操作符的信息。关于操作符，参考 如何理解查询计划解释。（后续章节 ) gp_wo
30、rkfile_usage_per_query 视图的每一行表示一个正在使用溢出文件的 SQL 查询的信息。 gp_workfile_usage_per_Segment 视图的每一行对应一个段数据库，包含了该段上使用的溢出文件占用的磁盘空间总量。关于这些视图的字段涵义，请参考Greenplum 数据库参考指南 。参数 gp_workfile_compress_algorithm 指定溢出文件的压缩算法：none 或者 zlib。第三章 数据库模式设计GPDB 是一个基于大规模并行处理（MPP ）和无共享架构的分析型数据库。这种数据库的数据模式与高度规范化的事务性 SMP 数据库显著不同。使用非规
31、范化数据库模式，例如具有大事实表和小维度表的星型或者雪花模式，处理 MPP 分析型业务时，Greenplum 数据库表现优异。 数据类型类型一致性关联列使用相同的数据类型。如果不同表中的关联列数据类型不同，GPDB 必须动态的进行类型转换以进行比较。考虑到这一点，你可能需要增大数据类型的大小，以便关联操作更高效。类型最小化建议选择最高效的类型存储数据，这可以提高数据库的有效容量及查询执行性能。建议使用 TEXT 或者 VARCHAR 而不是 CHAR。不同的字符类型间没有明显的性能差别，但是 TEXT 或者 VARCHAR 可以降低空间使用量。建议使用满足需求的最小数值类型。如果 INT 或
32、SAMLLINT 够用，那么选择 BIGINT 会浪费空间。 存储模型在 Greenplum 数据库中，创建表时可以选择不同的存储类型。需要清楚什么时候该使用堆存储、什么时候使用追加优化(AO)存储、什么时候使用行存储、什么时候使用列存储。对于大型事实表这尤为重要。相比而言，对小的维度表就不那么重要了。选择合适存储模型的常规最佳实践为：1. 对于大型事实分区表，评估并优化不同分区的存储选项。一种存储模型可能满足不了整个分区表的不同分区的应用场景，例如某些分区使用行存储而其他分区使用列存储。2. 使用列存储时，段数据库内每一列对应一个文件。对于有大量列的表，经常访问的数据使用列存储，不常访问的数
33、据使用行存储。3. 在分区级别或者在数据存储级别上设置存储类型。4. 如果集群需要更多空间，或者期望提高 I/O 性能，考虑使用压缩。堆存储和 AO 存储堆存储是默认存储模型，也是 PostgreSQL 存储所有数据库表的模型。如果表和分区经常执行 UPDATE、DELETE 操作或者单个 INSERT 操作，则使用堆存储模型。如果需要对表和分区执行并发 UPDATE、DELETE、INSERT 操作，也使用堆存储模型。如果数据加载后很少更新，之后的插入也是以批处理方式执行，则使用追加优化(AO)存储模型。千万不要对 AO 表执行单个 INSERT/UPDATE/DELETE 操作。并发批量
34、INSERT 操作是可以的，但是不要执行并发批量 UPDATE 或者 DELETE 操作。AO 表中执行删除和更新操作后行所占空间的重用效率不如堆表，所以这种存储类型不适合频繁更新的表。AO 表主要用于分析型业务中加载后很少更新的大表。行存储和列存储行存储是存储数据库元组的传统方式。一行的所有列在磁盘上连续存储，所以一次 I/O 可以从磁盘上读取整个行。列存储在磁盘上将同一列的值保存在一块。每一列对应一个单独的文件。如果表是分区表，那么每个分区的每个列对应一个单独的文件。如果列存储表有很多列，而 SQL 查询只访问其中的少量列，那么 I/O 开销与行存储表相比大大降低，因为不需要从磁盘上读取不
35、需要访问的列。交易型业务中更新和插入频繁，建议使用行存储。如果需要同时访问宽表的很多字段时，建议使用行存储。如果大多数字段会出现在 SELECT 列表中或者 WHERE 子句中，建议使用行存储。对于通用的混合型负载，建议使用行存储。行存储提供了灵活性和性能的最佳组合。列存储是为读操作而非写操作优化的一种存储方式，不同字段存储在磁盘上的不同位置。对于有很多字段的大型表，如果单个查询只需访问较少字段，那么列存储性能优异。列存储的另一个好处是相同类型的数据存储在一起比混合类型数据占用的空间少，因而列存储表比行存储表使用的磁盘空间小。列存储的压缩比也高于行存储。数据仓库的分析型业务中，如果 SELEC
36、T 访问少量字段或者在少量字段上执行聚合计算，则建议使用列存储。如果只有单个字段需要频繁更新而不修改其他字段，则建议列存储。从一个宽列存储表中读完整的行比从行存储表中读同一行需要更多时间。特别要注意的是，GPDB 每个段数据库上每一列都是一个独立的物理文件。 压缩Greenplum 数据库为 AO 表和分区提供多种压缩选项。使用压缩后，每次磁盘读操作可以读入更多的数据，因而可以提高 I/O 性能。建议在实际保存物理数据的那一层设置字段压缩方式。请注意，新添加的分区不会自动继承父表的压缩方式，必须在创建新分区时明确指定压缩选项。Delta 和 RLE 的压缩比较高。高压缩比使用的磁盘空间较少，但
37、是在写入数据或者读取数据时需要额外的时间和 CPU 周期进行压缩和解压缩。压缩和排序联合使用，可以达到最好的压缩比。在压缩文件系统上不要再使用数据库压缩。测试不同的压缩类型和排序方法以确定最适合自己数据的压缩方式。 分布(DISTRIBUTIONS)选择能够均匀分布数据的分布键对 Greenplum 数据库非常重要。在大规模并行处理无共享环境中，查询的总体响应时间取决于所有段数据库的完成时间。集群的最快速度与最慢的那个段数据库一样。如果存在严重数据倾斜现象，那么数据较多的段数据库响应时间将更久。每个段数据库最好有数量接近的数据，处理时间也相似。如果一个段数据库处理的数据显著比其他段多，那么性能
38、会很差，并可能出现内存溢出错误。确定分布策略时考虑以下最佳实践： 为所有表要么明确地指明其分布字段，要么使用随机分布。不要使用默认方式。 理想情况下，使用能够将数据均匀分布到所有段数据库上的一个字段做分布键。 不要使用常出现在查询的 WHERE 子句中的字段做分布键。 不要使用日期或者时间字段做分布键。 分布字段的数据要么是唯一值要么基数很大。 如果单个字段不能实现数据均匀分布，则考虑使用两个字段做分布键。作为分布键的字段最好不要超过两个。GPDB 使用哈希进行数据分布，使用更多的字段通常不能得到更均匀的分布，反而耗费更多的时间计算哈希值。 如果两个字段也不能实现数据的均匀分布，则考虑使用随机
39、分布。大多数情况下，如果分布键字段超过两个，那么执行表关联时通常需要节点间的数据移动操作（Motion），如此一来和随机分布相比，没有明显优势。Greenplum 数据库的随机分布不是轮询算法，不能保证每个节点的记录数相同，但是通常差别会小于 10%。关联大表时最优分布至关重要。关联操作需要匹配的记录必须位于同一段数据库上。如果分布键和关联字段不同，则数据需要动态重分发。某些情况下，广播移动操作（Motion）比重分布移动操作效果好。本地（Co-located）关联如果所用的哈希分布能均匀分布数据，并导致本地关联，那么性能会大幅提升。本地关联在段数据库内部执行，和其他段数据库没有关系，避免了网
40、络通讯开销，避免或者降低了广播移动操作和重分布移动操作。为经常关联的大表使用相同的字段做分布键可实现本地关联。本地关联需要关联的双方使用相同的字段（且顺序相同）做分布键，并且关联时所有的字段都被使用。分布键数据类型必须相同。如果数据类型不同，磁盘上的存储方式可能不同，那么即使值看起来相同，哈希值也可能不一样。数据倾斜数据倾斜是很多性能问题和内存溢出问题的根本原因。数据倾斜不仅影响扫描/读性能，也会影响很多其他查询执行操作符，例如关联操作、分组操作等。数据初始加载后，验证并保证数据分布的均匀性非常重要；每次增量加载后，都要验证并保证数据分布的均匀性。下面的查询语句统计每个段数据库上的记录的条数，
41、并根据最大和最小行数计算方差：SELECT Example Table AS “Table Name“, max(c) AS “Max Seg Rows“, min(c) AS “Min Seg Rows“, (max(c)-min(c)*100.0/max(c) AS “Percentage Difference Between Max gp_tooklit 模式中有两个视图可以帮助检查倾斜情况： 视图 gp_toolkit.gp_skew_coefficients 通过计算每个段数据库所存储数据的变异系数（coefficient of variation, CV）来显示数据倾斜情况。skc
42、coeff 字段表示变异系数，通过标准偏差除以均值计算而来。它同时考虑了数据的均值和可变性。这个值越小越好，值越高表示数据倾斜越严重。 视图 gp_toolkit.gp_skew_idle_fractions 通过计算表扫描时系统空闲的百分比显示数据分布倾斜情况，这是表示计算倾斜情况的一个指标。siffraction 字段显示了表扫描时处于空闲状态的系统的百分比。这是数据不均匀分布或者查询处理倾斜的一个指标。例如，0.1 表示 10% 倾斜，0.5 表示 50% 倾斜，以此类推。如果倾斜超过 10%，则需对其分布策略进行评估。计算倾斜（Procedding Skew）当不均衡的数据流向并被某个
43、或者少数几个段数据库处理时将出现计算倾斜。这常常是Greenplum 数据库性能和稳定性问题的罪魁祸首。关联、排序、聚合和各种 OLAP 操作中易发生计算倾斜。计算倾斜发生在查询执行时，不如数据倾斜那么容易检测，通常是由于选择了不当的分布键造成数据分布不均匀而引起的。数据倾斜体现在表级别，所以容易检测，并通过选择更好的分布键避免。如果单个段数据库失败（不是某个节点上的所有段实例），那么可能是计算倾斜造成的。识别计算倾斜目前主要靠手动。首先查看临时溢出文件，如果有计算倾斜，但是没有造成临时溢出文件，则不会影响性能。下面是检查的步骤和所用的命令：1. 找到怀疑发生计算倾斜的数据库的 OID：SEL
44、ECT oid, datname FROM pg_database;例子输出:oid | datname-+- 17088 | gpadmin 10899 | postgres 1 | template1 10898 | template0 38817 | pws 39682 | gpperfmon (6 rows)2. 使用 gpssh 检查所有 Segments 上的溢出文件大小。使用上面结果中的 OID 替换 :gpadminmdw kend$ gpssh -f /hosts -e “du -b /data1-2/primary/gpseg*/base/pgsql_tmp/*“ | gr
45、ep -v “du -b“ | sort | awk -F“ “ arr$1 = arr$1 + $2 ; tot = tot + $2 ; END for ( i in arr ) print “Segment node“ i, arr , “bytes (“ arr /(1024*3)“GB)“; print “Total“, tot, “bytes (“ tot/(1024*3)“ GB)“ -例子输出:Segment nodesdw1 2443370457 bytes (2.27557 GB)Segment nodesdw2 1766575328 bytes (1.64525 GB)S
46、egment nodesdw3 1761686551 bytes (1.6407 GB)Segment nodesdw4 1780301617 bytes (1.65804 GB)Segment nodesdw5 1742543599 bytes (1.62287 GB)Segment nodesdw6 1830073754 bytes (1.70439 GB)Segment nodesdw7 1767310099 bytes (1.64594 GB)Segment nodesdw8 1765105802 bytes (1.64388 GB)Total 14856967207 bytes (1
47、3.8366 GB)如果不同段数据库的磁盘使用量持续差别巨大，那么需要一进步查看当前执行的查询是否发生了计算倾斜（上面的例子可能不太恰当，因为没有显示出明显的倾斜）。 在很多监控系统中，总是会发生某种程度的倾斜，如果仅是临时性的，则不必深究。3. 如果发生了严重的持久性倾斜，接下来的任务是找到有问题的查询。上一步命令计算的是整个节点的磁盘使用量。现在我们要找到对应的段数据库(Segment)目录。可以从主节点（Master）上， 也可以登录到上一步识别出的 Segment 上做本操作。下面例子演示从 Master 执行操作。本例找的是排序生成的临时文件。然而并不是所有情况都是由排序引起的，需要
48、具体问题具体分析：gpadminmdw kend$ gpssh -f /hosts -e “ls -l /data1-2/primary/gpseg*/base/19979/pgsql_tmp/*“ | grep -i sort | sort下面是例子输出：sdw1 -rw- 1 gpadmin gpadmin 1002209280 Jul 29 12:48/data1/primary/gpseg2/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_19791_0001.0sdw1 -rw- 1 gpadmin gpadmin 1003356160 Jul
49、 29 12:48/data1/primary/gpseg1/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_19789_0001.0sdw1 -rw- 1 gpadmin gpadmin 288718848 Jul 23 14:58/data1/primary/gpseg2/base/19979/pgsql_tmp/pgsql_tmp_slice0_sort_17758_0001.0sdw1 -rw- 1 gpadmin gpadmin 291176448 Jul 23 14:58/data2/primary/gpseg5/base/19979/pgsql_tmp/pgsql_tmp_slice0_sort_17764_0001.0sdw1 -rw- 1 gpadmin gpadmin 988446720 Jul 29 12:48/data1/primary/gpseg0/base/199
