從oracle往greenplum遷移，查詢性能不知足要求的定位以及調優過程

1、前言

在一次對比oracle和greenplum查詢性能過程當中，因爲greenplum查詢性能不理想，所以進行定位分析，提高greenplum的查詢性能

 

2、環境信息

初始狀況下，搭建一個小的集羣，進行性能測試

磁盤	SAS
交換機	千兆
集羣大小	4segment
數據量	3億
數據文件大小	68G
表類型	Heap 行表
字段類型	全部列爲varchar
列寬	41列
索引	無
查詢語句	select count(*) from xxx where gjdqdm = 'CHN' and crrqsj >= '20100101000000' and crrqsj <= '20180101000000' and crkadm = '055'

 

 

 

 

 

 

 

 

PS:因爲要求greenplum中的表數據類型和源表類型一直，且索引一致。因此全部字段都爲varchar類型且無索引，所以這方面沒有優化空間。

 

3、優化過程

3.1 結果對比

SQL	ORACLE耗時	greenplum耗時
select count(*) from xxx where gjdqdm = 'CHN' and crrqsj >= '20100101000000' and crrqsj <= '20180101000000' and crkadm = '055'	24S	14.1S

 

 

14.1S是不能接受的速度，所以須要查找緣由，以期找出性能瓶頸，提供優化方案

 

3.2 分析過程

3.2.1 查看執行計劃

從①處能夠看出，全部的耗時都在③的操做，seq scan上。

這裏①處的意思是（摘自官網）：

The numbers that are quoted by EXPLAIN are (left to right):

    Estimated start-up cost (time expended before the output scan can start, e.g., time to do the sorting in a sort node)

    Estimated total cost (if all rows are retrieved, though they might not be; e.g., a query with a LIMIT clause will stop short of paying the total cost of the Limit plan node's input node)

    Estimated number of rows output by this plan node (again, only if executed to completion)

    Estimated average width (in bytes) of rows output by this plan node

 ③處的意思是：順序掃描磁盤

 

從②處能夠看出，全部的segment都參與了查詢

 

從④處能夠看出，全部的列設置爲varchar都進行了類型轉換，轉成了text，且沒有走索引（也無索引能用）

 

從⑤出能夠看出，實際使用的內存遠小於分配的內容，因此這裏能夠判斷出問題不在內存

 

3.2.2 查看數據分佈狀況

 

這裏能夠看到數據分佈是很是均勻的，因此不存在其中一臺計算節點耗時特別長的狀況

 

3.2.3 查看CPU狀況

既然內存沒有問題，那就能夠嘗試看CPU和磁盤的使用狀況了

在其中計算節點使用top命令查看：

這裏是其中一臺計算節點的截圖，這裏說明僅僅對於這一條SQL而言，已經消耗了CPU100%的資源，可是整機還有至關富餘的CPU資源可用

 

3.2.4 查看磁盤狀況

使用sar命令查看計算節點狀況

PS：這裏僅展現一套機器（實際狀況中每一臺計算節點都是相同的狀況）

這裏發現iowait一列是基本都爲0，可是idle也爲0，此處驗證了磁盤io沒有問題，問題出在CPU上

 

3.3 問題解決

前面說到這個greenplum集羣創建的時候只在每臺結算節點分配了一個segment，因此每臺機器上只有一個CPU是忙碌狀態的，而其餘的CPU處於空閒狀態

充分的利用CPU資源，就能夠顯著提升查詢的性能。

所以，對這套集羣的segment進行擴容，將原來的4個segment擴容爲54個，而且從新建表後將全部varchar類型換成text，將參與查詢的日期列設置爲分區鍵，分佈鍵不變，仍爲id列

 

3.4 最終結果

oracle	原集羣	擴容後的集羣
24S	14.1S	1.5S

 

 

 4、參考資料

https://www.postgresql.org/docs/9.2/static/using-explain.html