Sybase到GreenPlum迁移的POC

应客户一次需求，去客户现场做了次GreenPlum的POC。

GreenPlum环境是

•    1台master
  
•    6台segment host，每个host上2个segment实例
  

不过GreenPlum是装在一个有hadoop并存的机器上的，硬件资源不是很充足。

整个过程有三部：数据导出、数据导入、Query性能评价

• 数据导出

   迁移的对象从Sybase导出数据。

   这里主要的内容有三个：文字编码转码、导出速度、分隔符的选择

   原来Sybase的编码是CP936，也就是GBK，因为GP／PG的server都不支持CP936，打算转成默认的UTF－8数据。起先用linux的iconv，发现超过20M的文件，就会转码失败。好在后来用kettle转码比较正常。

  sybase的bcp导出数据，有些慢。刚好周末两天，开了多个终端，同时导出，计划七天的数据，两天就做完了。

   至于分隔符，理想的是不可见字符，当时对PG的转义没搞清楚，暂时用了^。数据大都是从业务系统过来的，不会输入这样的内容

• 数据load
  

   因为GP的一个亮点就在于IO的分离和并行。数据load过程也能体验到这种效果，所以数据load也作为POC内容。

   导出数据的存放，先后用了三种方式

   1.数据放在master上，从master导入数据 非常慢

   2.数据散落在6个segment host上，使用gpfdist启动服务，速度大幅改善

   3.找了一台独立的机器，使用gpdist服务，因为IO并行做的好，速度是最理想的

load是用的外部表的方式

   insert into 实表 select ＊ from 外部表；

产生的错误不多，低于万分之一。

• query

   实际query测试了下，性能跟sybase差不多。

   主要原因是GP的硬件资源没有配置好。

   1） segment实例太少，CPU多核没有充分利用

   2） 内存资源不足，mem长时间都是0的

   3）通过gpcheckperf来看，磁盘的IO也是很差的，读的速度只有80M／s

而query本身的特征，也存在分表的可能性。