1.分布式數(shù)據(jù)庫存儲

在前面的章節(jié);GreenPlum數(shù)據(jù)庫是分布式架構(gòu)數(shù)據(jù)庫;表的數(shù)據(jù)分布在segment節(jié)點(diǎn)。那么表的數(shù)據(jù)根據(jù)什么策略來分布的?

GreenPlum數(shù)據(jù)庫性能依賴于跨數(shù)據(jù)節(jié)點(diǎn)均勻分布

GreenPlum數(shù)據(jù)庫查詢響應(yīng)時(shí)間由所有數(shù)據(jù)節(jié)點(diǎn)完成時(shí)間來度量。系統(tǒng)只能跟最慢數(shù)據(jù)節(jié)點(diǎn)完成時(shí)間來決定。如果數(shù)據(jù)存儲傾斜。一個數(shù)據(jù)節(jié)點(diǎn)比其他節(jié)點(diǎn)需要花更多的時(shí)間來處理數(shù)據(jù)，數(shù)據(jù)存儲傾斜只會存在哈希分布的情況。

在GreenPlum數(shù)據(jù)庫中;表關(guān)聯(lián)查詢最常見。若兩個或者多個表關(guān)聯(lián)的字段非分布鍵或者采用隨機(jī)分布。在其他分布式架構(gòu)這表之間的關(guān)系不是親和表。要執(zhí)行連接，匹配的行必須位于同一節(jié)點(diǎn)上。 如果數(shù)據(jù)未在同一連接列上分發(fā)，則其中一個表所需的行將動態(tài)重新分發(fā)到其他節(jié)點(diǎn)。 有些情況下，執(zhí)行廣播動作，每個節(jié)點(diǎn)將其各個行發(fā)送到所有其他節(jié)點(diǎn)上，而不是每個節(jié)點(diǎn)重新哈希數(shù)據(jù)并根據(jù)哈希值將行發(fā)送到適當(dāng)?shù)墓?jié)點(diǎn)的重新分配。

是不是還有一種復(fù)制表?在GreenPlum6.0以上的版本支持復(fù)制表。正好避免2中的廣播或者重分布動作。

2.分布策略

在GreenPlum數(shù)據(jù)庫在創(chuàng)建表時(shí)可以指定分布策略：哈希分布(DISTRIBUTED BY)、隨機(jī)分布(DISTRIBUTED RANDOMLY)、復(fù)制分布(DISTRIBUTED REPLICATED)。

哈希分布：需要指定分布鍵。會根據(jù)分布鍵的哈希值分配到對應(yīng)的segment數(shù)據(jù)節(jié)點(diǎn)。相近的值會分配到同一個數(shù)據(jù)節(jié)點(diǎn)。

隨機(jī)分布：隨機(jī)分布無需指定分布鍵。這樣無法保證表中字段的唯一性。因?yàn)橥瑐€值可能會分布在不同的數(shù)據(jù)節(jié)點(diǎn)。

復(fù)制分布：在GreenPlum6.0以上的版本支持復(fù)制表;Greenplum數(shù)據(jù)庫會將每個表行分發(fā)到每個節(jié)點(diǎn)實(shí)例。 復(fù)制表的數(shù)據(jù)均勻分布，因?yàn)槊總€節(jié)點(diǎn)具有相同的行。

如何選擇分布策略呢?我們現(xiàn)在來分析

(1)單表查詢情況

結(jié)果驗(yàn)證：好像沒區(qū)別

(2)表關(guān)聯(lián)查詢

現(xiàn)在我們創(chuàng)建一個表t_lottu;也插入10000條記錄

lottu=# truncate table t_lottu;
TRUNCATE TABLE
lottu=# insert into t_lottu select generate_series(1,10000),'lottu';
INSERT 0 10000

隨機(jī)策略：通過t_random_01與表t_lottu關(guān)聯(lián)

哈希策略：

通過上兩圖比較：可以判斷哈希策略略好;我這環(huán)境只有2個segment節(jié)點(diǎn)。效果不明顯。我們可以明顯可以看到在隨機(jī)策略查詢計(jì)劃里面那有Redistribute Motion。 這個在后面講解查詢計(jì)劃。這個叫數(shù)據(jù)重分布。后須講解。

為什么隨機(jī)策略會Redistribute Motion?

在哈希策略中;同樣的分布鍵的值肯定會分布到同一個segment節(jié)點(diǎn)。所以上面表t_hash_01和表t_lottu的分布鍵都是id字段。所就可以在每個Segment節(jié)點(diǎn)關(guān)聯(lián)后，Segment節(jié)點(diǎn)把結(jié)果發(fā)送到Master節(jié)點(diǎn)，再由Master節(jié)點(diǎn)匯總，將最終的結(jié)果返還客戶端。而隨機(jī)分布則不能保證同樣分布鍵的數(shù)據(jù)分布在同一個Segment節(jié)點(diǎn)上，這樣在表關(guān)聯(lián)的時(shí)候，就需要將數(shù)據(jù)發(fā)送到所有Segment節(jié)點(diǎn)去做運(yùn)算，這樣網(wǎng)絡(luò)傳輸和大量數(shù)據(jù)運(yùn)算都需要較長的時(shí)間，性能非常低下。所以在關(guān)聯(lián)的時(shí)候不建議使用隨機(jī)策略。

這里有一個問題了;是不是哈希策略查詢計(jì)劃就不會出現(xiàn)Redistribute Motion/Broadcast Motion(廣播)。答案是錯誤的。若分布鍵跟關(guān)聯(lián)的字段不一致的情況。就會出現(xiàn)。分布鍵跟關(guān)聯(lián)的字段是否一致?在其它分布式架構(gòu)叫表的親和度。

(3)數(shù)據(jù)分布傾斜的問題

既然不建議使用隨機(jī)策略;那我們都是用哈希策略不就好了嗎?

哈希策略是同樣的分布鍵的值肯定會分布到同一個segment節(jié)點(diǎn)。有可能造成數(shù)據(jù)分布傾斜的問題。在隨機(jī)策略不會出現(xiàn)這種情況。

數(shù)據(jù)分布傾斜的問題;待定。

-- 重新分布表數(shù)據(jù)

(4)數(shù)據(jù)復(fù)制分布

在GreenPlum6.0版本中支持復(fù)制表。作用消除多表關(guān)聯(lián)中Redistribute Motion/Broadcast Motion帶來的性能消耗。也可用于單表的負(fù)載均衡。

在用于單表查詢;可以看出只需查詢一個節(jié)點(diǎn)即可。

用于多表關(guān)聯(lián)消除多表關(guān)聯(lián)中Redistribute Motion/Broadcast Motion帶來的性能消耗

3.數(shù)據(jù)是如何儲存

創(chuàng)建表的DDL語句還可以通過with子句來定義表的存儲類型

where storage_parameter is:
   APPENDONLY={TRUE|FALSE}
   BLOCKSIZE={8192-2097152}
   ORIENTATION={COLUMN|ROW}
   COMPRESSTYPE={ZLIB|QUICKLZ|RLE_TYPE|NONE}
   COMPRESSLEVEL={0-9}
   CHECKSUM={TRUE|FALSE}
   FILLFACTOR={10-100}
   OIDS[=TRUE|FALSE]
where column_constraint is:

(1)堆表

堆表是PostgreSQL數(shù)據(jù)庫原生存儲格式，GreenPlum默認(rèn)的存儲格式。堆表存儲在OLTP類型負(fù)載下表現(xiàn)最好，這種環(huán)境中數(shù)據(jù)會在初始載入后被頻繁地修改。 UPDATE和DELETE操作要求存儲行級版本信息來確保可靠的數(shù)據(jù)庫事務(wù)處理。 堆表最適合于較小的表，例如維度表，它們在初始載入數(shù)據(jù)后會經(jīng)常被更新。

多適合用于OLTP系統(tǒng)。但GreenPlum常定位是用于OLAP系統(tǒng)。為了更適合OLAP系統(tǒng)。GreenPlum提供來AO表

應(yīng)用場景：

堆表是萬油金;只是有些場景其他存儲方式更加適合。更能提升性能。

(2)AO表

AO表在4.3版本之前取意為(APPEND-ONLY，AO)。根據(jù)其意義只能追加，在4.3版本之后取意為(append-optimized，AO)追加優(yōu)化。支持update/delete。跟堆表一樣。但實(shí)現(xiàn)原理不一樣。刪除更新數(shù)據(jù)時(shí)，通過另一個BITMAP文件來標(biāo)記被刪除的行，通過bit以及偏移對齊來判定AO表上的某一行是否被刪除。

追加優(yōu)化表存儲在數(shù)據(jù)倉庫環(huán)境中的非規(guī)范表表現(xiàn)最好。 非規(guī)范表通常是系統(tǒng)中最大的表。 事實(shí)表通常成批地被載入并且被只讀查詢訪問。 將大型的事實(shí)表改為追加優(yōu)化存儲模型可以消除每行中的更新可見性信息負(fù)擔(dān)，這可以為每一行節(jié)約大概20字節(jié)。 這可以得到一種更加簡潔并且更容易優(yōu)化的頁面結(jié)構(gòu)。 追加優(yōu)化表的存儲模型是為批量數(shù)據(jù)裝載優(yōu)化的，因此不推薦單行的INSERT語句

AO支持壓縮以及列存

應(yīng)用場景：

使用列存、壓縮數(shù)據(jù)使用AO表。

數(shù)據(jù)批量寫入使用AO表

(3)行存和列存

ORIENTATION=COLUMN可以指定創(chuàng)建列存的AO表。列存的表只能是AO表。

行存：以行形式存儲表中。一行數(shù)據(jù)存在一個數(shù)據(jù)文件中。適用于具有許多迭代事務(wù)的OLTP類型的工作負(fù)載以及一次需要多列的單行，因此檢索是高效的

列存：以列為形式組織存儲，每列對應(yīng)一個或一批文件。而且壓縮比例比較高。適合于在少量列上計(jì)算數(shù)據(jù)聚集的數(shù)據(jù)倉庫負(fù)載，或者是用于需要對單列定期更新但不修改其他列數(shù)據(jù)的情況

若一個寬表。在讀取某一個列數(shù)據(jù);行存需要把匹配的列的所在的行數(shù)據(jù)塊都要掃描一遍。整好列存可以避免。但是帶來的問題是一個表對應(yīng)多個數(shù)據(jù)文件。

以上就是關(guān)于“數(shù)據(jù)庫分布式存儲詳解”的介紹，大家如果想了解更多相關(guān)知識，不妨來關(guān)注一下動力節(jié)點(diǎn)的Java在線學(xué)習(xí)，里面的課程內(nèi)容詳細(xì)，從入門到精通，適合沒有基礎(chǔ)的小白學(xué)習(xí)，希望對大家能夠有所幫助。