GreenPlum學習筆記：create table建立表

　　二維表一樣是GP中重要的存儲數據對象，爲了更好的支持數據倉庫海量數據的訪問，GP的表能夠分紅：

• 面向行存儲的普通堆積表
• 面向列存儲的AOT表（append only table）

　　固然AOT表也能夠是按行存儲的，可是按列存儲必須是AOT表。這樣，咱們在設計應用上能夠得到至關的靈活性。好比常常須要更新的數據，或者較小的維度數據，應該使用普通堆積表存儲。

　　例子：

create table tmp_001( month_id numeric(8), serv_id numeric(30), cust_id numeric(30) ) with ( appendonly=true, compresslevel=5, orientation=column, compresstype=zlib, oids=false ) distributed by (month_id,serv_id)

1.分佈鍵（哈希鍵）

• distributed by (a) 指定a字段爲分佈鍵
• distributer randomly 隨機分佈

注意：

• 未指定分佈鍵，默認表的主鍵爲分佈鍵，若表沒有主鍵，則默認把第一列看成哈希鍵
• 分佈鍵能夠被定義爲一個或多個
• 分佈鍵必須是惟一鍵
• 不能修改分佈鍵，且哈希鍵的列不能update
• 一個表只能定義一個惟一鍵，且主鍵和惟一鍵必須做爲哈希鍵
• 數值重複度低，保證數據均勻分佈
• 防止數據傾斜，布爾值不適合，float、double數據類型也不適合，interger、varchar比較好
• 大表常常作鏈接時，選擇相同的分佈鍵，避免跨節點進行join
• 儘可能不用序列號，無心義

2.AOT 指定按列分佈

• appendonly=true  指定是否只append追加
• compresslevel=5 zlib壓縮級別 1-9共9個級別 9壓縮最大
• orientation=column 指定是否按列存儲
• compresstype=zlib GP提供兩種壓縮算法：zlib和quicklz
• oids=false 對象標識符 不分配

3.其餘注意

　　與其它數據庫相比，GP的表最大的不一樣是它必定是分區的，也就是表中的全部記錄都會依據相關算法打散，分佈到全部的segment當中，從而在充分利用硬件資源的同時，最大化訪問數據的IO，這種特性對於數據倉庫應用是很是有幫助的。

　　GP提供兩種打散數據的算法，一種是Hash算法：distributed by (serv_id)，在定義表的時候，經過distributed by指定表中的某個列或者某個列的組合做爲Hash鍵，相同Hash鍵的記錄會放在同一個segment當中。因此，GP建議通常選擇記錄分佈均勻的鍵做爲Hash鍵使用，從而保證表中的記錄能夠均勻分佈到全部segment上。若是表上定義了主鍵或者惟一鍵，則這些鍵值列必須做前導列出如今分佈鍵當中，而且放在第一位。

　　 若是定義表的時候，沒有指定distributed子句，系統使用第一個列做爲Hash鍵使用。

　　另外一種數據打散的算法是平均分配法（ROUND-ROBIN），distributed randomly， 假設有三個段，那麼這種算法會把第一條記錄放在段1, 第二條記錄放在段2，第三條記錄放在段3，第四條記錄放在段1，以此類推，直到全部記錄發放完爲止。這種算法比較適合表中的字段存在嚴重數據傾斜的狀況。

　　在數據倉庫中，對於存儲海量少變化歷史數據的事實表的訪問，會產生大量IO。這些表除了記錄多外（縱向），同時也很寬。好比幾十列，甚至上百列的表也很常見。可是在進行數據分析和挖掘過程當中，咱們可能只用到這些列的很小一部份內容，而傳統的按行存儲的表，在訪問時老是會訪問記錄中的全部列，致使不少無效IO，當因爲表橫向尺寸過大，按行存儲的表還會出現行連接，這會使無效IO的問題更嚴重。在GP中，對於這種狀況應該考慮使用面向列存儲的AOT表，從而大幅高IO效率，獲取數據查詢性能的收益。

 　　如今硬件系統每每IO效率跟不上CPU處理的速度，而數據倉庫應用偏偏是IO敏感型的應用，因此不少數據倉庫系統上，會看到CPU很閒，可是出現大量IO等待的狀況。因此經過壓縮，尤爲是面向列壓縮，容許咱們犧牲必定的CPU效率進一步換取IO效率，提升系統的的吞吐量。

　　GP的AOT表容許使用兩種壓縮算法，一種是ZLIB，它的壓縮率較高，對CPU的消耗較多，GP中能夠指定1到9共9個級別。1的壓縮比最小，9最大。另外一種算法是QUICKLZ，它的壓縮比小，能設置1，形成的CPU負載也比ZLIB小。

　　AOT表雖然查詢和加載數據的效率很高，可是如它的名字那樣它只能支持select，insert，truncate操做，不支持update和delete操做。因此它只適合存放通過處理基本最終無變化的歷史數據，用來提供高效的查詢訪問。

　　從數據數據存放的生命週期看，前面介紹的表都稱之爲永久表，這些表的記錄不會由於事務的結束和會話的斷開而消失。而業務中，咱們常常要使用到臨時數據集合，若是用永久表存放中間結果，一方面是在併發環境中數據不安全，另外一方面頻繁的刪除表中的記錄或者刪除表，會致使大量碎片，在字典層面形成瓶頸。所以GP也支持臨時表，不一樣鏈接共享相同的表結構。好比下面的例子：

CREATE TEMP TABLE SALES_TMP (PROD_ID numeric NOT NULL , CUST_ID numeric NOT NULL , TIME_ID DATE NOT NULL , CHANNEL_ID numeric NOT NULL , PROMO_ID numeric NOT NULL , QUANTITY_SOLD numeric(10,2) NOT NULL , AMOUNT_SOLD numeric(10,2) NOT NULL) on commit preserve rows distributed randomly;

CREATE TEMP TABLE SALES (PROD_ID numeric NOT NULL , CUST_ID numeric NOT NULL , TIME_ID DATE NOT NULL , CHANNEL_ID numeric NOT NULL , PROMO_ID numeric NOT NULL , QUANTITY_SOLD numeric(10,2) NOT NULL , AMOUNT_SOLD numeric(10,2) NOT NULL) on commit delete rows distributed by (prod_id,cust_id,time_id,channel_id,promo_id);

　　例子一是事務內有效，鏈接會話間數據獨立。完成事務後數據保留，只有鏈接會話斷開後數據才消失。

　　例子二是事務內有效，也就是提交事務後（commit）數據就會消失。

　　若是臨時表的名字與永久表名字重複，臨時表的訪問優先。

　　除了普通表之外，GP還支持超大表進行分區應用，爲咱們的提升數據訪問效率的同時，也提升應用的靈活型。它能夠支持RANGE分區，LIST分區，以及靈活的複合分區（RANGE-LIST,RANGE-RANGE,LIST-RANGE,LIST-LIST,以及更多層次的分區，好比三層分區),GP的分區是基於segment基礎之上的。每一個分區的數據一樣會打散分佈到每一個segment中，當where條件上出現分區鍵時，它會進行分區裁剪，減小IO。須要注意的是，目前GreenPlum還只支持靜態分區裁剪，因此若是但願用到分區裁剪，請在Where條件中使用事實表的分區鍵做爲條件。

---

 END 2018-08-01 18:17:13