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本身的特征，也存在分表的可能性。