greenplum是乙個大規模並行處理資料庫，它由乙個master和多個segment組成，其資料按照設定的分布策略分布於各個segment上。資料表的單個行會被分配到乙個或多個segment上，但是有這麼多的segment，它到底會被分到哪個或哪些segment上呢？分布策略會告訴我們。
分布策略
在greenplum 5中，有2種分布策略：
在greenplum 6中，新增了另乙個策略：
雜湊分布：
要使用這一策略，需要在建立表使用 「distributed by(column，[...])」 子句。
雜湊演算法使分布鍵將每一行分配給特定segment。相同值的鍵將始終雜湊到同乙個segment。選擇唯一的分布鍵(例如primary key)將確保較均勻的資料分布。雜湊分布是表的預設分布策略。
如果建立表時未提供distributed子句，則將primary key(如果表真的有的話)或表的第乙個合格列用作分布鍵。什麼型別的列是合格列呢？幾何型別或使用者自定義資料型別的列不能用作greenplum分布鍵列。如果表中沒有合格的列，則退化為隨機分布策略。
但是，如果未提供distributed子句，greenplum最後會選擇哪種分布策略還會受其它因素的影響，例如：guc gp_create_table_random_default_distribution和當時使用的優化器(optimizer)也將影響最終決定。因此，請千萬不要忘記在create table時新增distributed by子句。否則，表的分布策略可能是只薛丁格的貓。
隨機分布：
要使用這一策略，需要在建立表使用 「distributed randomly」 子句。
隨機分布會將資料行按到來順序依次迴圈傳送到各個segment上。與雜湊分布策略不同，具有相同值的資料行不一定位於同乙個segment上。雖然隨機分布確保了資料的平均分布，但只要有可能，應該盡量選擇雜湊分布策略，雜湊分布的效能更加優良。
複製分布：
這種分布策略是gpdb 6的新增特性。
greenplum資料分布和分割槽策略
要使用這一策略，需要在建立表使用 「distributed replicated」 子句。
greenplum資料庫將每行資料分配到每個segment上。這種分布策略下，表資料將均勻分布，因為每個segment都儲存著同樣的資料行。當您需要在segment上執行使用者自定義的函式且這些函式需要訪問表中的所有行時，就需要用到複製分布策略。或者當有大表與小表join，把足夠小的表指定為replicated也可能提公升效能。
請注意，有乙個例外：catalog表沒有分布策略。
關於3項策略的摘要：
雜湊分布
隨機分布
複製分布
適用gp5 / 6
gp5，gp6
gp5，gp6
gp6語句
distributed by (column, [ … ])
distributed randomly
distributed replicated
預設策略？
儲存1 segment
1 segment
n segments
均勻分布
取決於選擇的分布鍵
查詢效能
分割槽策略
現在讓我們看一下分割槽，對於greenplum新手使用者，分割槽的概念會很容易地與分布混淆，其實分布與分割槽有根本上的的不同。分布是對儲存的資料進行物理劃分，而分割槽則是邏輯劃分。分割槽是通過 「partition by」 子句完成的，它允許將乙個大表劃分為多個子表。「subpartition by」 子句可以將子表劃分為更小的表 。從理論上講，greenplum對於根表(root table)可以擁有多少級(level)或多少個分割槽表(partitioned table)並沒有限制，但是對於任一級分割槽(表的層次結構級別)，乙個分割槽表最多可以有32,767個子分割槽表。
當只考慮分布時，可以只把分割槽表當作乙個普通表。對於乙個根表來說，它的資料首先會被分配到某個分割槽表，然後單個分割槽表會像普通表一樣根據分割槽表的分布策略分布在greenplum的各個segments上，這與任何未分割槽表相同。greenplum資料庫中的表物理地分布在greenplum各個segments上，使並行查詢處理成為可能。表分割槽是一種邏輯上劃分大表的工具，可提高查詢效能並促進資料倉儲維護任務。分割槽不會更改表資料在segment之間的物理分布。
greenplum支援以下分割槽型別：
對大表進行分割槽，將提高查詢效能並簡化資料庫的維護任務，例如將舊資料滾動移除出資料庫。
但是不要建立超出您需要的分割槽。建立過多的分割槽可能會拖慢管理和維護的速度，例如清理，恢復segment，擴充套件集群，檢查磁碟使用情況等等。
除非查詢優化器可以根據查詢謂詞修剪分割槽，否則使用分割槽不會提高查詢效能。需要依次掃瞄各個分割槽表的查詢比只需掃瞄無分割槽的根表的查詢執行得慢，因此，如果你的查詢中很少能用上分割槽裁剪，請盡量嘗試避免對錶進行分割槽。在gpcc中，可以檢查查詢監視器中的可視計畫，以防掃瞄無關分割槽。
您還可能會遇到另一種分割槽：預設分割槽。
當進來的資料與所有的分割槽不匹配時，它將被插入預設分割槽。如果分割槽設計沒有預設分割槽，它將拒絕其插入操作。
預設分割槽是一把雙刃劍，有了它，表的操作很安全，但是也可能會掩蓋問題。
假設您有乙個表，並根據「age」列建立分割槽。它定義了乙個list，當資料行的年齡為1時，它進入partition1；當年齡為2時，它進入partition2，…，當年齡為100時，它進入partition100。但是有一天，乙個101歲的人來了，bang，錯誤發生了，因為您尚未為age = 101建立分割槽，所以也沒有partition101表。這個人無處可去。
如果您為該錶建立了預設分割槽，則101歲的老人將轉到該預設分割槽。問題解決了，大家都很開心。
而假設某一天人類的壽命變得更長，比如200歲，那麼100歲以上的人都將被分到預設分割槽。預設分割槽會被撐的越來越大，如果沒有人注意，查詢就會越來越慢，因為該分割槽太大，以致於分割槽修剪並無多大效果。
既然表的這些分布和分割槽策略如何重要，您可能會問：我們如何監控這些情況，以及及早發現異常。
關於作者
楊茹，pivotal軟體工程師
greenplum command center(gpcc)全棧工程師。畢業於南開大學自動化系，長期從事一線軟體開發工作，是gpcc table browser功能的核心開發人員之一。
Greenplum元資料資訊
pg database 所有的資料庫資訊 pg namespace 所有的schema資訊 pg class 所有的表資訊 pg attribute 所有的屬性資訊 pg proc 函式資訊，包括自定義函式 以上都可以以select from x 去檢視 新建乙個資料庫lcc gp,新建乙個表 cr...
greenplum 資料匯入 匯出
匯出語句 匯出為csv格式的資料 新增欄位頭匯出 psql d databasename h localhost p 5432 c copy select from tablename limit 10000 to tmp my data2.csv with csv header delimiter...
關於Greenplum資料庫
關於greenplum資料庫 greenplum實現了基於資料庫的分布式資料儲存和平行計算 greenplum的資料庫引擎層是基於著名的開源資料庫postgresql greenplum建立在share nothing無共享架構上，讓每一顆cpu和每一塊磁碟io都運轉起來，無共享架構將這種並行處理發...