Greenplum是一個大規模並行處理數據庫,它由一個master和多個segment組成,其數據按照設定的分佈策略分佈於各個segment上。數據表的單個行會被分配到一個或多個segment上,可是有這麼多的segment,它到底會被分到哪一個或哪些segment上呢?分佈策略會告訴咱們。算法
在Greenplum 5中,有2種分佈策略:數據庫
在Greenplum 6中,添加了另外一個策略:安全
哈希分佈:dom
要使用這一策略,須要在建立表使用 「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歲以上的人都將被分到默認分區。默認分區會被撐的愈來愈大,若是沒有人注意,查詢就會愈來愈慢,由於該分區太大,以至於分區修剪並沒有多大效果。
既然表的這些分佈和分區策略如何重要,您可能會問:咱們如何監控這些狀況,以及及早發現異常。
咱們將在下一篇《GPCC如何提供幫助》詳細解答。