Greenplum数据库最佳实践

介绍本文介绍PivotalGreenplumDatabase数据库（以下简称：Greenplum数据库，或GPDB）的最佳实践。最佳实践是指能持续产生比其他方法更好结果的方法或者技术，它来自于实战经验，并被证实了遵循这些方法可以获得可靠的预期结果。本最佳实践旨在通过利用所有可能的知识和技术为正确使用GPDB提供有效参考。本文不是在教您如何使用Greenplum数据库的功能，而是帮助您在设计、实现和使用Greenplum数据库时了解需要遵循哪些最佳实践。关于如何使用和实现具体的Greenplum数据库特性，请参考http://gpdb.docs.pivotal.io上的Greenplum数据库帮助文档以及http://greenplum.org上的Sandbox和实践指南。本文目的不是要涵盖整个产品或者产品特性，而是概述GPDB实践中最重要的因素。本文不涉及依赖于GPDB具体特性的边缘用例，后者需要精通数据库特性和您的环境，包括SQL访问、查询执行、并发、负载和其他因素。通过掌握这些最佳实践知识，会增加GPDB集群在维护、支持、性能和可扩展性等方面的成功率。第一章最佳实践概述本部分概述了Greenplum数据库最佳实践所涉及的概念与要点。数据模型GPDB是一个基于大规模并行处理(MPP)和无共享架构的分析型数据库。这种数据库的数据模式与高度规范化的事务性SMP数据库显著不同。通过使用非规范化数据库模式，例如具有大事实表和小维度表的星型或者雪花模式，GPDB在处理MPP分析型业务时表现优异。跨表关联(JOIN)时字段使用相同的数据类型。详见数据库模式设计（后续章节)堆存储和追加优化存储(Append-Optimized，下称AO)若表和分区表需要进行迭代式的批处理或者频繁执行单个UPDATE、DELETE或INSERT操作，使用堆存储。若表和分区表需要并发执行UPDATE、DELETE或INSERT操作，使用堆存储。若表和分区表在数据初始加载后更新不频繁，且仅以批处理方式插入数据，则使用AO存储。不要对AO表执行单个INSERT、UPDATE或DELETE操作。不要对AO表执行并发批量UPDATE或DELETE操作，但可以并发执行批量INSERT操作。详见堆存储和AO存储（后续章节)行存储和列存储若数据需要经常更新或者插入，则使用行存储。若需要同时访问一个表的很多字段，则使用行存储。对于通用或者混合型业务，建议使用行存储。若查询访问的字段数目较少，或者仅在少量字段上进行聚合操作，则使用列存储。若仅常常修改表的某一字段而不修改其他字段，则使用列存储。详见行存储和列存储（后续章节)压缩对于大AO表和分区表使用压缩，以提高系统I/O。在字段级别配置压缩。考虑压缩比和压缩性能之间的平衡。详见压缩（后续章节)分布为所有表定义分布策略：要么定义分布键，要么使用随机分布。不要使用缺省分布方式。优先选择可均匀分布数据的单个字段做分布键。不要选择经常用于WHERE子句的字段做分布键。不要使用日期或时间字段做分布键。分布键和分区键不要使用同一字段。对经常执行JOIN操作的大表，优先考虑使用关联字段做分布键，尽量做到本地关联，以提高性能。数据初始加载后或者每次增量加载后，检查数据分布是否均匀。尽可能避免数据倾斜。详见分布（后续章节)内存管理设置vm.overcommit_memory为2不要为操作系统的页设置过大的值使用gp_vmem_protect_limit设置单个节点数据库（分配的最大内存量。SegmentDatabase）可以为所有查询不要设置过高的gp_vmem_protect_limit值，也不要大于系统的物理内存。gp_vmem_protect_limit的建议值计算公式为：(SWAP+(RAM*vm.overcommit_ratio))*0.9/number_Segments_per_server使用statement_mem控制节点数据库为单个查询分配的内存量。使用资源队列设置队列允许的当前最大查询数（ACTIVE_STATEMENTS）和允许使用的内存大小（MEMORY_LIMIT）。不要使用默认的资源队列，为所有用户都分配资源队列。根据负载和时间段，设置和队列实际需求相匹配的优先级（PRIORITY）。保证资源队列的内存配额不超过gp_vmem_protect_limit。动态更新资源队列配置以适应日常工作需要。详见内存和负载管理（后续章节)分区只为大表设置分区，不要为小表设置分区。仅在根据查询条件可以实现分区裁剪时使用分区表。建议优先使用范围(Range)分区，否则使用列表(List)分区。根据查询特点合理设置分区。不要使用相同的字段即做分区键又做分布键。不要使用默认分区。避免使用多级分区；尽量创建少量的分区，每个分区的数据更多些。通过查询 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 的EXPLAIN结果来验证查询对分区表执行的是选择性扫描（分区裁剪）。对于列存储的表，不要创建过多的分区，否则会造成物理文件过多：Physicalfiles=Segments*Columns*Partitions。详见分区（后续章节)索引一般来说GPDB中索引不是必需的。对于高基数的列存储表，如果需要遍历且查询选择性较高，则创建单列索引。频繁更新的列不要建立索引。在加载大量数据之前删除索引，加载结束后再重新创建索引。优先使用B树索引。不要为需要频繁更新的字段创建位图索引。不要为唯一性字段，基数非常高或者非常低的字段创建位图索引。不要为事务性负载创建位图索引。一般来说不要索引分区表。如果需要建立索引，则选择与分区键不同的字段。详见索引（后续章节)资源队列使用资源队列管理集群的负载。为所有角色定义适当的资源队列。使用ACTIVE_STATEMENTS参数限制队列成员可以并发运行的查询总数。使用MEMORY_LIMIT参数限制队列中查询可以使用的内存总量。不要设置所有队列为MEDIUM，这样起不到管理负载的作用。根据负载和时间段动态调整资源队列。详见配置资源队列（后续章节)监控和维护根据《Greenplum数据库管理员指南》实现该书推荐的监控和管理任务。安装Greenplum数据库前建议运行gpcheckperf，安装后定期运行。保存输出结果，随着时间推移对系统性能进行比较。使用所有您可用的工具，以了解系统不同负载下的表现。检查任何不寻常的事件并确定原因。通过定期运行解释计划监控系统查询活动，以确保查询处于最佳运行状态。检查查询计划，以确定是否按预期使用了索引和进行了分区裁剪。了解系统日志文件的位置和内容，定期监控日志文件，而不是在出现问题时才查看。详见系统监控和维护以及监控GPDB日志文件。（后续章节)ANALYZE不要对整个数据库运行ANALYZE，只对需要的表运行该命令。建议数据加载后即刻运行ANALYZE。如果INSERT、UPDATE和DELETE等操作修改大量数据，建议运行ANALYZE。执行CREATEINDEX操作后建议运行ANALYZE。如果对大表ANALYZE耗时很久，则只对JOIN字段、WHERE、SORT、GROUPBY或HAVING字句的字段运行ANALYZE。详见使用ANALYZE更新统计信息。（后续章节)Vaccum批量UPDATE和DELETE操作后建议执行VACUUM。不建议使用VACUUMFULL。建议使用CTAS（CREATETABLE...AS）操作，然后重命名表名，并删除原来的表。对系统表定期运行VACUUM，以避免系统表臃肿和在系统表上执行VACUUMFULL操作。禁止杀死系统表的VACUUM任务。不建议使用VACUUMANALYZE。详见消除系统表臃肿。（后续章节)加载使用gpfdist进行数据的加载和导出。随着段数据库个数的增加，并行性增加。尽量将数据均匀地分布到多个ETL节点上。将非常大的数据文件切分成相同大小的块，并放在尽量多的文件系统上。一个文件系统运行两个gpfdist实例。在尽可能多的网络接口上运行gpfdsit。使用gp_external_max_segs控制访问每个gpfdist服务器的段数据库的个数。建议gp_external_max_segs的值和gpfdist进程个数为偶数。数据加载前删除索引；加载完后重建索引。数据加载完成后运行ANALYZE操作。数据加载过程中，设置gp_autostats_mode为NONE，取消统计信息的自动收集。若数据加载失败，使用VACUUM回收空间。详见加载数据。（后续章节)gptransfer为了更好的性能，建议使用gptransfer迁移数据到相同大小或者更大的集群。避免使用--full或者--schema-only选项。建议使用其他方法拷贝数据库模式到目标数据库，然后迁移数据。迁移数据前删除索引，迁移完成后重建索引。使用SQLCOPY命令迁移小表到目标数据库。使用gptransfer批量迁移大表。在正式迁移生产环境前测试运行gptransfer。试验--batch-size和--sub-batch-size选项以获得最大平行度。如果需要，迭代运行多次gptransfer来确定每次要迁移的表的批次。仅使用完全限定的表名。表名字中若含有点、空格、单引号和双引号，可能会导致问题。如果使用--validation选项在迁移后验证数据，则需要同时使用-x选项，以在源表上加排它锁。确保在目标数据库上创建了相应的角色、函数和资源队列。gptransfer-t不会迁移这些对象。从源数据库拷贝postgres.conf和pg_hba.conf到目标数据库集群。使用gppkg在目标数据库上安装需要的扩展。详见使用gptransfer迁移数据（后续章节)安全妥善保护gpadmin账号，只有在必要的时候才能允许系统管理员访问它。仅当执行系统维护任务（例如升级或扩容），管理员才能以gpadmin登录Greenplum集群。限制具有SUPERUSER角色属性的用户数。GPDB中，身为超级用户的角色会跳过所有访问权限检查和资源队列限制。仅有系统管理员具有数据库超级用户权限。参考《Greenplum数据库管理员指南》中的“修改角色属性”。严禁数据库用户以gpadmin身份登录，严禁以gpadmin身份执行ETL或者生产任务。为有登录需求的每个用户都分配一个不同的角色。考虑为每个应用或者网络服务分配一个不同的角色。使用用户组管理访问权限。保护好ROOT的密码。对于操作系统密码，强制使用强密码策略。确保保护好操作系统的重要文件。详见安全。（后续章节)加密加密和解密数据会影响性能，仅加密需要加密的数据。在生产系统中实现任何加密解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 之前都要做性能测试。GPDB生产系统使用的服务器证书应由证书签名颁发机构（CA）签名，这样客户端可以验证服务器。如果所有客户端都是本地的，则可以使用本地CA。如果客户端与GPDB的连接会经过不安全的链路，则使用SSL加密。加密和解密使用相同密钥的对称加密方式比非对称加密具有更好的性能，如果密钥可以安全共享，则建议使用对称加密方式。使用pgcrypto包中的函数加密磁盘上的数据。数据的加密和解密都由数据库进程完成，为了避免传输明文数据，需要使用SSL加密客户端和数据库间的连接。数据加载和导出时，使用gpfdists 协议 离婚协议模板下载合伙人协议 下载渠道分销协议免费下载敬业协议下载授课协议下载 保护ETL数据安全。详见加密数据和数据库连接。（后续章节)高可用使用8到24个磁盘的硬件RAID存储解决方案。使用RAID1、5或6，以使磁盘阵列可以容忍磁盘故障。为磁盘阵列配备热备磁盘，以便在检测到磁盘故障时自动开始重建。在重建时通过RAID卷镜像防止整个磁盘阵列故障和性能下降。定期监控磁盘利用率，并在需要时增加额外的空间。定期监控段数据库倾斜，以确保在所有段数据库上数据均匀分布，存储空间均匀消耗。配置备用主服务器，当主服务器发生故障时由备用主服务器接管。规划好当主服务器发生故障时如何切换客户端连接到新的主服务器实例，例如通过更新DNS中主服务器的地址。建立监控系统，当主服务器发生故障时，可以通过系统监控应用或电子邮件发送通知。分配主段数据库和其镜像到不同的主机上，以防止主机故障。建立监控系统，当主段数据库发生故障时，可以通过系统监控应用或电子邮件发送通知。使用gprecoverseg工具及时恢复故障段，并使系统返回最佳平衡状态。在主服务器上配置并运行gpsnmpd以发送SNMP通知给网络监控器。在$Master_DATA_DIRECTORY/postgresql.conf配置文件中设置邮件通知，以便检测到关键问题时，Greenplum系统可以通过电子邮件通知管理员。考虑双集群配置，提供额外的冗余和查询处理能力。除非Greenplum数据库的数据很容易从数据源恢复，否则定期备份。如果堆表相对较小，或者两次备份之间仅有少量AO或列存储分区有变化，则使用增量备份。如果备份保存在集群的本地存储系统上，则备份结束后，将文件移到其他的安全存储系统上。如果备份保存到NFS中，则建议使用像EMCIsilon这样的可扩展NFS方案以防止I/O瓶颈。Greenplum集成了对EMC的DataDomain和Symantec的NetBackup的支持，可以流式备份到DataDomain或NetBackup企业备份平台上。详见高可用性（后续章节)第二章系统配置本节描述了Greenplum数据库集群关于主机配置的需求和最佳实践。首选操作系统红帽企业级Linux（RHEL）是首选操作系统。应使用最新支持的主版本，目前是RHEL6。文件系统Greenplum数据库的数据目录推荐使用XFS文件系统。使用以下选项挂载XFS：rw,noatime,inode64,allocsize=16m端口配置ip_local_port_range的设置不要和Greenplum数据库的端口范围有冲突，例如：net.ipv4.ip_local_port_range=300065535PORT_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/schedulernoopanticipatory[deadline]cfq通过/etc/security/limits.conf增大操作系统文件数和进程数。*softnofile65536*hardnofile65536*softnproc131072*hardnproc131072启用core文件转储，并保存到已知位置。确保limits.conf中允许的core转储文件。kernel.core_pattern=/var/core/core.%h.%t#grepcore/etc/security/limits.conf*softcoreunlimited操作系统内存配置Linuxsysctl的vm.overcommit_memory和vm.overcommit_ratio变量会影响操作系统对内存分配的管理。这些变量应该设置如下：?vm.overcommit_memory控制操作系统使用什么方法确定分配给进程的内存总数。对于Greenplum数据库，唯一建议值是2.?vm.overcommit_ratio控制分配给应用程序进程的内存百分比。建议使用缺省值50.不要启用操作系统的大内存页。详见内存和负载管理。（后续章节)共享内存设置Greenplum数据库中同一数据库实例的不同postgres进程间通讯使用共享内存。使用sysctl配置如下共享内存参数，且不建议修改：kernel.shmmax=500000000kernel.shmmni=4096kernel.shmall=4000000000验证操作系统使用gpcheck验证操作系统配置。参考《Greenplum数据库工具指南》中的gpcheck。设置一个主机上段数据库个数确定每个段主机上段数据库的个数对整体性能有着巨大影响。这些段数据库之间共享主机的CPU核、内存、网卡等，且和主机上的所有进程共享这些资源。过高地估计每个服务器上运行的段数据库个数，通常是达不到最优性能的常见原因之一。以下因素确定了一个主机上可以运行多少个段数据库：?CPU核的个数?物理内存容量?网卡个数及速度?存储空间?主段数据库和镜像共存?主机是否运行ETL进程?主机上运行的非Greenplum进程段服务器内存配置服务器配置参数gp_vmem_protect_limit控制了每个段数据库为所有运行的查询分配的内存总量。如果查询需要的内存超过此值，则会失败。使用下面公式确定合适的值：(swap+(RAM*vm.overcommit_ratio))*.9/number_of_Segments_per_server例如，具有下面配置的段服务器：?8GB交换空间?128GB内存?vm.overcommit_ratio=50?则设置8个段数据库gp_vmem_protect_limit为8GB：(8+(128*.5))*.9/8=8GB参见内存和负载管理。（后续章节)?SQL语句内存配置服务器配置参数gp_statement_mem控制段数据库上单个查询可以使用的内存总量。如果语句需要更多内存，则会溢出数据到磁盘。用下面公式确定合适的值：(gp_vmem_protect_limit*.9)/max_expected_concurrent_queries例如，如果并发度为40，gp_vmeme_protect_limit为8GB，则gp_statement_mem为：(8192MB*.9)/40=184MB每个查询最多可以使用184MB内存，之后将溢出到磁盘。若想安全的增大gp_statement_mem，要么增大gp_vmem_protect_limit，要么降低并发。要增大gp_vmem_protect_limit，必须增加物理内存和/或交换空间，或者降低单个主机上运行的段数据库个数。请注意，为集群添加更多的段数据库实例并不能解决内存不足的问题，来降低了单个主机上运行的段数据库的个数。除非引入更多新主机了解什么是溢出文件。了解gp_workfile_limit_files_per_query参数，其控制了单个查询最多可以创建多少个溢出文件。了解gp_workfile_limit_per_Segment。有关使用资源队列管理内存的更多信息，请参考内存和负载管理。（后续章节)溢出文件配置如果为SQL查询分配的内存不足，Greenplum数据库会创建溢出文件（也叫工作文件）。在默认情况下，一个SQL查询最多可以创建100000个溢出文件，这足以满足大多数查询。参数gp_workfile_limit_files_per_query决定了一个查询最多可以创建多少个溢出文件。0意味着没有限制。限制溢出文件数据可以防止失控查询破坏整个系统。如果分配内存不足或者出现数据倾斜，则一个SQL溢出文件上限，Greenplum数据库报告如下错误：查询可能产生大量溢出文件。如果超过ERROR:numberofworkfilesperquerylimitexceeded在尝试增大gp_workfile_limit_files_per_query前，先尝试通过修改SQL、数据分布策略或者内存配置以降低溢出文件个数。gp_toolkit模式包括一些视图，通过这些视图可以看到所有使用溢出文件的查询的信息。这些信息有助于故障排除和调优查询：?gp_workfile_entries视图的每一行表示一个正在使用溢出文件的操作符的信息。关?于操作符，参考如何理解查询计划解释。（后续章节)gp_workfile_usage_per_query视图的每一行表示一个正在使用溢出文件的SQL查询的信息。?gp_workfile_usage_per_Segment视图的每一行对应一个段数据库，包含了该段上使用的溢出文件占用的磁盘空间总量。关于这些视图的字段涵义，请参考《Greenplum数据库参考指南》。参数gp_workfile_compress_algorithm指定溢出文件的压缩算法：none或者zlib。第三章数据库模式设计GPDB是一个基于大规模并行处理（MPP）和无共享架构的分析型数据库。这种数据库的数据模式与高度规范化的事务性SMP数据库显著不同。使用非规范化数据库模式，例如具有大事实表和小维度表的星型或者雪花模式，处理MPP分析型业务时，Greenplum数据库表现优异。数据类型类型一致性关联列使用相同的数据类型。如果不同表中的关联列数据类型不同，GPDB行类型转换以进行比较。考虑到这一点，你可能需要增大数据类型的大小，高效。必须动态的进以便关联操作更类型最小化建议选择最高效的类型存储数据，这可以提高数据库的有效容量及查询执行性能。建议使用TEXT但是TEXT或者或者VARCHAR而不是CHAR。不同的字符类型间没有明显的性能差别，VARCHAR可以降低空间使用量。建议使用满足需求的最小数值类型。如果INT或SAMLLINT够用，那么选择BIGINT会浪费空间。存储模型在Greenplum数据库中，创建表时可以选择不同的存储类型。需要清楚什么时候该使用堆存储、什么时候使用追加优化(AO)存储、什么时候使用行存储、什么时候使用列存储。对于大型事实表这尤为重要。相比而言，对小的维度表就不那么重要了。选择合适存储模型的常规最佳实践为：1.对于大型事实分区表，评估并优化不同分区的存储选项。一种存储模型可能满足不了整个分区表的不同分区的应用场景，例如某些分区使用行存储而其他分区使用列存储。2.使用列存储时，段数据库内每一列对应一个文件。对于有大量列的表，经常访问的数据使用列存储，不常访问的数据使用行存储。3.在分区级别或者在数据存储级别上设置存储类型。4.如果集群需要更多空间，或者期望提高I/O性能，考虑使用压缩。堆存储和AO存储堆存储是默认存储模型，也是PostgreSQL存储所有数据库表的模型。如果表和分区经常执行UPDATE、DELETE操作或者单个INSERT操作，则使用堆存储模型。如果需要对表和分区执行并发UPDATE、DELETE、INSERT操作，也使用堆存储模型。如果数据加载后很少更新，之后的插入也是以批处理方式执行，则使用追加优化模型。千万不要对AO表执行单个INSERT/UPDATE/DELETE操作。并发批量作是可以的，但是不要执行并发批量UPDATE或者DELETE操作。(AO)存储INSERT操AO表中执行删除和更新操作后行所占空间的重用效率不如堆表，频繁更新的表。AO表主要用于分析型业务中加载后很少更新的大表。所以这种存储类型不适合行存储和列存储行存储是存储数据库元组的传统方式。一行的所有列在磁盘上连续存储，所以一次I/O可以从磁盘上读取整个行。列存储在磁盘上将同一列的值保存在一块。每一列对应一个单独的文件。如果表是分区表，那么每个分区的每个列对应一个单独的文件。如果列存储表有很多列，而SQL查询只访问其中的少量列，那么I/O开销与行存储表相比大大降低，因为不需要从磁盘上读取不需要访问的列。交易型业务中更新和插入频繁，建议使用行存储。如果需要同时访问宽表的很多字段时，建议使用行存储。如果大多数字段会出现在SELECT列表中或者WHERE子句中，建议使用行存储。对于通用的混合型负载，建议使用行存储。行存储提供了灵活性和性能的最佳组合。列存储是为读操作而非写操作优化的一种存储方式，不同字段存储在磁盘上的不同位置。于有很多字段的大型表，如果单个查询只需访问较少字段，那么列存储性能优异。对列存储的另一个好处是相同类型的数据存储在一起比混合类型数据占用的空间少，储表比行存储表使用的磁盘空间小。列存储的压缩比也高于行存储。因而列存数据仓库的分析型业务中，如果SELECT访问少量字段或者在少量字段上执行聚合计算，则建议使用列存储。如果只有单个字段需要频繁更新而不修改其他字段，则建议列存储。从一个宽列存储表中读完整的行比从行存储表中读同一行需要更多时间。特别要注意的是，GPDB每个段数据库上每一列都是一个独立的物理文件。压缩Greenplum数据库为AO表和分区提供多种压缩选项。使用压缩后，每次磁盘读操作可以读入更多的数据，因而可以提高I/O性能。建议在实际保存物理数据的那一层设置字段压缩方式。请注意，新添加的分区不会自动继承父表的压缩方式，项。必须在创建新分区时明确指定压缩选Delta和RLE的压缩比较高。高压缩比使用的磁盘空间较少，但是在写入数据或者读取数据时需要额外的时间和CPU周期进行压缩和解压缩。压缩和排序联合使用，可以达到最好的压缩比。在压缩文件系统上不要再使用数据库压缩。测试不同的压缩类型和排序方法以确定最适合自己数据的压缩方式。?分布(DISTRIBUTIONS)选择能够均匀分布数据的分布键对Greenplum数据库非常重要。在大规模并行处理无共享环境中，查询的总体响应时间取决于所有段数据库的完成时间。集群的最快速度与最慢的那个段数据库一样。如果存在严重数据倾斜现象，那么数据较多的段数据库响应时间将更久。每个段数据库最好有数量接近的数据，处理时间也相似。如果一个段数据库处理的数据显著比其他段多，那么性能会很差，并可能出现内存溢出错误。确定分布策略时考虑以下最佳实践：?为所有表要么明确地指明其分布字段，要么使用随机分布。不要使用默认方式。?理想情况下，使用能够将数据均匀分布到所有段数据库上的一个字段做分布键。?不要使用常出现在查询的WHERE子句中的字段做分布键。?不要使用日期或者时间字段做分布键。?分布字段的数据要么是唯一值要么基数很大。?如果单个字段不能实现数据均匀分布，则考虑使用两个字段做分布键。作为分布键的字段最好不要超过两个。GPDB使用哈希进行数据分布，使用更多的字段通常不能得到更均匀的分布，反而耗费更多的时间计算哈希值。?如果两个字段也不能实现数据的均匀分布，则考虑使用随机分布。大多数情况下，如果分布键字段超过两个，那么执行表关联时通常需要节点间的数据移动操作（Motion），如此一来和随机分布相比，没有明显优势。Greenplum数据库的随机分布不是轮询算法，不能保证每个节点的 记录 混凝土 养护记录下载土方回填监理旁站记录免费下载集备记录下载集备记录下载集备记录下载 数相同，但是通常差别会小于10%。关联大表时最优分布至关重要。关联操作需要匹配的记录必须位于同一段数据库上。如果分布键和关联字段不同，则数据需要动态重分发。某些情况下，广播移动操作（Motion）比重分布移动操作效果好。本地（Co-located）关联如果所用的哈希分布能均匀分布数据，并导致本地关联，那么性能会大幅提升。本地关联在段数据库内部执行，和其他段数据库没有关系，避免了网络通讯开销，避免或者降低了广播移动操作和重分布移动操作。为经常关联的大表使用相同的字段做分布键可实现本地关联。本地关联需要关联的双方使用相同的字段（且顺序相同）做分布键，并且关联时所有的字段都被使用。分布键数据类型必须相同。如果数据类型不同，磁盘上的存储方式可能不同，那么即使值看起来相同，哈希值也可能不一样。数据倾斜数据倾斜是很多性能问题和内存溢出问题的根本原因。数据倾斜不仅影响扫描会影响很多其他查询执行操作符，例如关联操作、分组操作等。/读性能，也数据初始加载后，验证并保证数据分布的均匀性非常重要；每次增量加载后，都要验证并保证数据分布的均匀性。下面的查询语句统计每个段数据库上的记录的条数，并根据最大和最小行数计算方差：SELECT'ExampleTable'AS"TableName",max(c)AS"MaxSegRows",min(c)AS"MinSegRows",(max(c)-min(c))*100.0/max(c)AS"PercentageDifferenceBetweenMax&Min"FROM(SELECTcount(*)c,gp_Segment_idFROMfactsGROUPBY2)ASa;gp_tooklit模式中有两个视图可以帮助检查倾斜情况：?视图gp_toolkit.gp_skew_coefficients通过计算每个段数据库所存储数据的变异系数（coefficientofvariation,CV 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 偏差除以均值计算而来。）来显示数据倾斜情况。skccoeff它同时考虑了数据的均值和可变性。字段表示变异系数，通过这个值越小越好，值越高表示数据倾斜越严重。?视图gp_toolkit.gp_skew_idle_fractions通过计算表扫描时系统空闲的百分比显示数据分布倾斜情况，这是表示计算倾斜情况的一个指标。siffraction字段显示了表扫描时处于空闲状态的系统的百分比。这是数据不均匀分布或者查询处理倾斜的一个指标。例如，0.1表示10%倾斜，0.5表示50%倾斜，以此类推。如果倾斜超过10%，则需对其分布策略进行评估。计算倾斜（ProceddingSkew）当不均衡的数据流向并被某个或者少数几个段数据库处理时将出现计算倾斜。这常常是Greenplum数据库性能和稳定性问题的罪魁祸首。关联、排序、聚合和各种OLAP操作中易发生计算倾斜。计算倾斜发生在查询执行时，不如数据倾斜那么容易检测，通常是由于选择了不当的分布键造成数据分布不均匀而引起的。数据倾斜体现在表级别，所以容易检测，并通过选择更好的分布键避免。如果单个段数据库失败（不是某个节点上的所有段实例），那么可能是计算倾斜造成的。识别计算倾斜目前主要靠手动。首先查看临时溢出文件，如果有计算倾斜，但是没有造成临时溢出文件，则不会影响性能。下面是检查的步骤和所用的命令：找到怀疑发生计算倾斜的数据库的OID：SELECToid,datnameFROMpg_database;例子输出:oid|datname-------+-----------17088|gpadmin10899|postgres1|template110898|template038817|pws39682|gpperfmon(6rows)2.使用gpssh检查所有Segments上的溢出文件大小。使用上面结果中的OID替换:[gpadmin@mdwkend]$gpssh-f~/hosts-e\"du-b/data[1-2]/primary/gpseg*/base//pgsql_tmp/*"|\grep-v"du-b"|sort|\awk-F""'{arr[$1]=arr[$1]+$2;tot=tot+$2};\END{for(iinarr)print"Segmentnode"i,arr,\"bytes("arr/(1024**3)"GB)";\print"Total",tot,"bytes("tot/(1024**3)"GB)"}'-例子输出:Segmentnode[sdw1]2443370457bytes(2.27557GB)Segmentnode[sdw2]1766575328bytes(1.64525GB)Segmentnode[sdw3]1761686551bytes(1.6407GB)Segmentnode[sdw4]1780301617bytes(1.65804GB)Segmentnode[sdw5]1742543599bytes(1.62287GB)Segmentnode[sdw6]1830073754bytes(1.70439GB)Segmentnode[sdw7]1767310099bytes(1.64594GB)Segmentnode[sdw8]1765105802bytes(1.64388GB)Total14856967207bytes(13.8366GB)如果不同段数据库的磁盘使用量持续差别巨大，那么需要一进步查看当前执行的查询是否发生了计算倾斜（上面的例子可能不太恰当，因为没有显示出明显的倾斜）。在很多监控系统中，总是会发生某种程度的倾斜，如果仅是临时性的，则不必深究。如果发生了严重的持久性倾斜，接下来的任务是找到有问题的查询。上一步命令计算的是整个节点的磁盘使用量。现在我们要找到对应的段数据库录。可以从主节点（Master）上，也可以登录到上一步识别出的Segment下面例子演示从Master执行操作。(Segment)上做本操作。目本例找的是排序生成的临时文件。然而并不是所有情况都是由排序引起的，需要具体问题具体分析：[gpadmin@mdwkend]$gpssh-f~/hosts-e\"ls-l/data[1-2]/primary/gpseg*/base/19979/pgsql_tmp/*"|grep-isort|sort下面是例子输出：[sdw1]-rw-------1gpadmingpadmin1002209280Jul2912:48/data1/primary/gpseg2/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_19791_0001.0[sdw1]-rw-------1gpadmingpadmin1003356160Jul2912:48/data1/primary/gpseg1/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_19789_0001.0[sdw1]-rw-------1gpadmingpadmin288718848Jul2314:58/data1/primary/gpseg2/base/19979/pgsql_tmp/pgsql_tmp_slice0_sort_17758_0001.0[sdw1]-rw-------1gpadmingpadmin291176448Jul2314:58/data2/primary/gpseg5/base/19979/pgsql_tmp/pgsql_tmp_slice0_sort_17764_0001.0[sdw1]-rw-------1gpadmingpadmin988446720Jul2912:48/data1/primary/gpseg0/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_19787_0001.0[sdw1]-rw-------1gpadmingpadmin995033088Jul2912:48/data2/primary/gpseg3/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_19793_0001.0[sdw1]-rw-------1gpadmingpadmin997097472Jul2912:48/data2/primary/gpseg5/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_19797_0001.0[sdw1]-rw-------1gpadmingpadmin997392384Jul2912:48/data2/primary/gpseg4/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_19795_0001.0[sdw2]-rw-------1gpadmingpadmin1002340352Jul2912:48/data2/primary/gpseg11/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_3973_0001.0[sdw2]-rw-------1gpadmingpadmin1004339200Jul2912:48/data1/primary/gpseg8/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_3967_0001.0[sdw2]-rw-------1gpadmingpadmin989036544Jul2912:48/data2/primary/gpseg10/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_3971_0001.0[sdw2]-rw-------1gpadmingpadmin993722368Jul2912:48/data1/primary/gpseg6/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_3963_0001.0[sdw2]-rw-------1gpadmingpadmin998277120Jul2912:48/data1/primary/gpseg7/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_3965_0001.0[sdw2]-rw-------1gpadmingpadmin999751680Jul2912:48/data2/primary/gpseg9/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_3969_0001.0[sdw3]-rw-------1gpadmingpadmin1000112128Jul2912:48/data1/primary/gpseg13/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_24723_0001.0[sdw3]-rw-------1gpadmingpadmin1004797952Jul2912:48/data2/primary/gpseg17/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_24731_0001.0[sdw3]-rw-------1gpadmingpadmin1004994560Jul2912:48/data2/primary/gpseg15/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_24727_0001.0[sdw3]-rw-------1gpadmingpadmin1006108672Jul2912:48/data1/primary/gpseg14/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_24725_0001.0[sdw3]-rw-------1gpadmingpadmin998244352Jul2912:48/data1/primary/gpseg12/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_24721_0001.0[sdw3]-rw-------1gpadmingpadmin998440960Jul2912:48/data2/primary/gpseg16/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_24729_0001.0[sdw4]-rw-------1gpadmingpadmin1001029632Jul2912:48/data2/primary/gpseg23/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29435_0001.0[sdw4]-rw-------1gpadmingpadmin1002504192Jul2912:48/data1/primary/gpseg20/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29429_0001.0[sdw4]-rw-------1gpadmingpadmin1002504192Jul2912:48/data2/primary/gpseg21/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29431_0001.0[sdw4]-rw-------1gpadmingpadmin1009451008Jul2912:48/data1/primary/gpseg19/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29427_0001.0[sdw4]-rw-------1gpadmingpadmin980582400Jul2912:48/data1/primary/gpseg18/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29425_0001.0[sdw4]-rw-------1gpadmingpadmin993230848Jul2912:48/data2/primary/gpseg22/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29433_0001.0[sdw5]-rw-------1gpadmingpadmin1000898560Jul2912:48/data2/primary/gpseg28/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_28641_0001.0[sdw5]-rw-------1gpadmingpadmin1003388928Jul2912:48/data2/primary/gpseg29/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_28643_0001.0[sdw5]-rw-------1gpadmingpadmin1008566272Jul2912:48/data1/primary/gpseg24/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_28633_0001.0[sdw5]-rw-------1gpadmingpadmin987332608Jul2912:48/data1/primary/gpseg25/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_28635_0001.0[sdw5]-rw-------1gpadmingpadmin990543872Jul2912:48/data2/primary/gpseg27/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_28639_0001.0[sdw5]-rw-------1gpadmingpadmin999620608Jul2912:48/data1/primary/gpseg26/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_28637_0001.0[sdw6]-rw-------1gpadmingpadmin1002242048Jul2912:48/data2/primary/gpseg33/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29598_0001.0[sdw6]-rw-------1gpadmingpadmin1003683840Jul2912:48/data1/primary/gpseg31/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29594_0001.0[sdw6]-rw-------1gpadmingpadmin1004732416Jul2912:48/data2/primary/gpseg34/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29600_0001.0[sdw6]-rw-------1gpadmingpadmin986447872Jul2912:48/data2/primary/gpseg35/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29602_0001.0[sdw6]-rw-------1gpadmingpadmin990543872Jul2912:48/data1/primary/gpseg30/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29592_0001.0[sdw6]-rw-------1gpadmingpadmin992870400Jul2912:48/data1/primary/gpseg32/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29596_0001.0[sdw7]-rw-------1gpadmingpadmin1007321088Jul2912:48/data2/primary/gpseg39/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_18530_0001.0[sdw7]-rw-------1gpadmingpadmin1011187712Jul2912:48/data1/primary/gpseg37/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_18526_0001.0[sdw7]-rw-------1gpadmingpadmin987332608Jul2912:48/data2/primary/gpseg41/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_18534_0001.0[sdw7]-rw-------1gpadmingpadmin994344960Jul2912:48/data1/primary/gpseg38/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_18528_0001.0[sdw7]-rw-------1gpadmingpadmin996114432Jul2912:48/data2/primary/gpseg40/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_18532_0001.0[sdw7]-rw-------1gpadmingpadmin999194624Jul2912:48/data1/primary/gpseg36/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_18524_0001.0[sdw8]-rw-------1gpadmingpadmin1002242048Jul2912:48/data2/primary/gpseg46/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15675_0001.0[sdw8]-rw-------1gpadmingpadmin1003520000Jul2912:48/data1/primary/gpseg43/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15669_0001.0[sdw8]-rw-------1gpadmingpadmin1008009216Jul2912:48/data1/primary/gpseg44/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15671_0001.0[sdw8]-rw-------1gpadmingpadmin