应客户一次需求，去客户现场做了次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本身的特征，也存在分表的可能性。