Greenplum 数据库最佳实践(14)

数据加载后对表运行ANALYZE。加载过程中通过设置gp_autostats_mode 为NONE禁用统计信息自动收集。

对有大量分区的列表频繁执行少量数据加载会严重影响系统性能，因为每次访问的物理文件很多。

? gpload

gpload 是一个数据加载工具，是Greenplum外部表并行数据加载特性的一个接口。 小心使用gpload，因为它会创建和删除外部表而造成系统表膨胀。建议使用性能最好的gpfdist。

gpload 使用YAML格式的控制文件来定义数据加载规范，执行下面操作：

? ? ? ? ?

启动 gpfdist 进程；

基于定义的外部数据创建临时外部表；

执行INSERT、UPDATE或者MERGE操作，加载数据到数据库中的目标表； 删除临时外部表； 清理 gpfdist 进程。

加载操作处于单个事务之中。

? 最佳实践

? ? ? ? ?

加载数据到现有表前删除索引，加载完成后重建索引。创建新索引比边加载边更新索引快。 加载过程中，设置gp_autostats_mode为 NONE，禁用统计信息自动收集。 外部表不适合频繁访问或者ad-hoc访问。

外部表没有统计数据。可以使用下面的语句为外部表设置大概估计的行数和磁盘页数： UPDATE pg_class SET reltuples=400000, relpages=400WHERE relname='myexttable'; 使用gpfdist时，为ETL服务器上的每个NIC运行一个 gpfdist 实例以最大化利用网络带宽。均匀分布数据到多个 gpfdist 实例上。

? 使用 gpload 时，运行尽可能多的 gpload。充分利用CPU、内存和网络资源以提高从ETL服务器加载数据到Greenplum数据库的速度。

? 使用 LOG ERRORS INTO 子句保存错误行。错误行 -- 例如，缺少字段值或者多了额外值，或者不正确的数据类型 -- 保存到错误表中，加载继续执行。Segment REJECT LIMIT 子句设置命令中止前允许的错误行的数目或者百分比。

? ?

如果加载报错，对目标表运行VACUUM释放空间。

数据加载完成后，对堆表包括系统表运行 VACUUM，对所有表运行 ANALYZE。对AO表不必运行 VACUUM。如果表是分区表，则可以仅对数据加载影响的分区执行VACUUM和ANALYZE。这样可以清除失败的加载占用的空间、删除或者更新的行占用的空间，并更新统计数据。

?

加载大量数据后重新检查数据倾斜。使用下面查询检查倾斜状况： SELECT gp_Segment_id, count(*)

FROM schema.table GROUP BY gp_Segment_id ORDER BY 2;

? 默认情况，gpfdist可以处理的最大行为 32K。如果行大于32K，则需要使用gpfdist的-m 选项增大最大行长度。如果使用gpload，配置控制文件中的 MAX_LINE_LENGTH 参数。 注意：Informatica Power Exchange 目前还不能处理大于32K的行。

? 额外信息

关于 gpfdist和gpload的更多信息，请参考《Greenplum数据库参考指南》

第七章 SQL查询调优

Greenplum数据库采用基于成本的优化器来评估执行查询的不同策略，并选择成本最低的方法。和其他关系数据库系统的优化器相似，在计算不同执行计划的成本时，Greenplum的优化器会考虑诸如关联表的行数、是否有索引、字段数据的基数等因素。还会考虑到数据的位置，尽可能在段数据库(Segment)上完成任务，降低在不同Segments间传输的数据量。 在一个查询运行速度比预期慢时，可以查看优选器生成的查询计划以及执行每一步的代价。这有助于确定哪一步最耗资源，进而可以修改查询或者模式，以便生成更好的计划。查看查询计划使用 EXPLAIN 语句。

优化器基于每个表的统计信息生成计划，所以准确的统计信息对生成最有计划至关重要。关于更新统计信息，请参看本文档的\使用ANALYZE更新统计信息\一节。

?如何生成查询计划解释

EXPLAIN 和 EXPLAIN ANALYZE 语句有助于改进查询性能。EXPLAIN 显示一个查询的执行计划以及估算的代价，但是不执行该查询。EXPLAIN ANALYZE除了显示执行计划外还

会执行查询。EXPLAIN ANALYZE 会丢弃SELECT语句的输出，其他操作会被执行（例如INSERT，UPDATE和DELETE）。若需对DML语句使用EXPLAIN ANALYZE而不影响数据，可置EXPLAIN ANALYZE 于事务中（BEGIN; EXPLAIN ANALYZE ...; ROLLBACK;）。 EXPLAIN ANALYZE 除了执行查询、显示查询计划外，还显示如下信息：

? ? ? ? ?

执行查询的总时间（以毫秒为单位）； 查询节点需要的工作进程个数；

每个操作中处理最多行的Segment处理的最大行数以及Segment的序号； 内存使用量；

从处理最多行的Segment上获得第一行花费的时间（单位是毫秒）及从该Segment获得所有行花费的时间。

?如何理解查询计划解释

解释计划详细描述了Greenplum数据库执行查询的步骤。查询计划是颗节点树，从下向上读数据，每个节点将它的执行结果数据传递给其上的节点。每个节点表示查询计划的一个步骤，每个节点都有一行信息描述了该步骤执行的操作 -- 例如扫描、关联、聚合或者排序操作等，此外还有显示执行该操作的具体方法。例如，扫描操作可能是顺序扫描或者索引扫描，关联操作可能是哈希关联或者嵌套循环关联。

下面是一个简单查询的解释计划，这个查询的结果应为每个Segment上contributions表的行数。

gpacmin=# EXPLAIN SELECT gp_Segment_id, count(*) FROM contributions GROUP BY gp_Segment_id; QUERY

PLAN--------------------------------------------------------------------------------Gather Motion 2:1 (slice2; Segments: 2) (cost=0.00..4.44 rows=4 width=16) -> HashAggregate (cost=0.00..3.38 rows=4 width=16) Group By: contributions.gp_Segment_id ->

Redistribute Motion 2:2 (slice1; Segments: 2) (cost=0.00..2.12 rows=4 width=8) Hash Key: contributions.gp_Segment_id -> Sequence (cost=0.00..1.09 rows=4 width=8) -> Result (cost=10.00..100.00 rows=50 width=4) -> Function Scan on gp_partition_expansion (cost=10.00..100.00 rows=50 width=4) -> Dynamic Table Scan on contributions (partIndex: 0) (cost=0.00..0.03 rows=4 width=8)Settings: optimizer=on(10 rows) 此计划有7个节点 - Dynamic Table Scan, Function Scan, Result, Sequence, Redistribute Motion, HashAggregate 及最后的 Gather Motion。每个节点含有三个估计代价：代价（顺序读页数），行数和行的长度。

代价本身包含2个估计值。一部分是启动代价估计，即得到第一行的代价，第二部分是总代价估计，即处理完所有行的代价。代价为1.0意味着顺序读一个磁盘页。

行数是查询节点输出行数的估计。考虑到WHERE子句条件的选择性，可能比实际处理或者扫描的行数小。总代价假设处理所有行，而有些时候可能不需要（例如 LIMIT 子句）。 长度是查询节点输出的所有字段的总长度，单位是字节。

节点的估计代价包括所有子节点的代价，所以计划的最顶层节点（通常是Gather Motion）包含执行计划的总代价。优化器试图降低的也正是这个数字。

扫描操作符扫描数据库表以找到期望的数据行。不同的存储类型有不同的扫描操作：

? ? ? ? ? ?

堆表顺序扫描 - 扫描表的所有行 AO 扫描 - 扫描面向行的AO表 AO 列扫描 - 扫描面向列的AO表

索引扫描 - 遍历B树索引，从表中获取期望的行

Bitmap AO 行扫描 - 从索引中获得AO表 …… 此处隐藏：3969字，全部文档内容请下载后查看。喜欢就下载吧 ……