摘要：最近在做oracle到greenplum的迁移实践,步骤如下:1. 使用ora2pg实现Oracle的数据结构迁移到GP的实现过程2. Oracle的数据迁移到GP的实现过程1. ora2pg的使用地址: https://github.com/darold/ora2p关系图如下:需要安装DBD-or... 阅读全文

摘要：greenplum属于分布式的数据库,MPP+Share nothing的体系,查询的效率很快.不过,这是建立在数据分散均匀的基础上的.如果DK值设置不合理的话,完全有可能出现所有数据落在单个节点上的情况,这就体现不出优势来.因此,DK值的设置是否合适是建表的时候,需要考虑的重要因素之一. 查看表(table_name)的数据在节点的分布情况:select gp_segment_id,count(*) from table_name group by gp_segment_id; 如果数据有严重倾斜的话,即某些节点的数据量过大,表示DK值需要重新调整.调整语句为alter table t... 阅读全文

摘要：前面一篇文章写到如何通过gp_segment_id来判断表的DK值设置有数据，下面是通过查看占用空间的量来检查分配不平衡的表，并重新调整着DK值。我的一台greenplum机器，其中的一个节点的数据量比其它的节点多很多，说明数据分布的不平衡，如下所示：以sdw16为例:$du -sh /gpdata{1,2}/data/gp*347G /gpdata1/data/gp30412G /gpdata1/data/gp62357G /gpdata1/data/gp63336G /gpdata2/data/gp31338G /gpdata2/data/gp94343G /gpdata2/data/gp 阅读全文

摘要：最近正在进行ETL后台系统数据的日志分析,查看运行耗时长的TASK,并找出耗时长的JOB,进行逻辑层面和数据库层面的优化.本文仅从数据库层面上的优化着手(包括SQL语句的调整以及greenplum table dk的调整).查看一个耗时30分钟左右的JOB,找到相应的源表,进行如下分析:dw=#select gp_segment_id,count(*) from tb_name group by gp_segment_id order by count(*) descgp_segment_id count---------------------- 65 166... 阅读全文

摘要：最近处于系统不活跃期，没怎么升级，因此有了时间可以对整个ETL系统在稳定的基础上进行优化。每天列出TOP 10 COST TIME JOB进行分析，其中TOP1 COSTTIME JOB采用了窗口函数first_value和last_value,结果SQL全部使用的是first_value,并且为了全部使用first_value,对窗口函数进行了二次排序。通过explain这段代码，可以发现两次sort消耗的时候大概是一次sort的1.7倍，把sort二次改进成一次，并且把SQL从datastage迁移到greenplum的function里面，整个过程由24分钟降至40秒。分析为什么只使用f 阅读全文

摘要：在使用greenplum数据库的时候,有的时候想要查看表所占用空间的大小,会使用如下二个函数pg_relation_size和pg_size_pretty. 前者用来查看数据大小,后者是human readable的调整.方法如下:select pg_size_pretty(pg_relation_size('relation_name')) ;select pg_size_pretty(pg_relation_size(oid)) ;但是,对于分区表而言,这个方法就没有用了,会发现使用后表的大小为0bytes.原因在于:GP的分区表的主表只是一个表定义,其实际数据内容存储在继 阅读全文