第3篇：分布式資料庫存盤

一、分布式資料庫存盤

在前面的章節；GreenPlum資料庫是分布式架構資料庫；表的資料分布在segment節點，那么表的資料根據什么策略來分布的？

GreenPlum資料庫性能依賴于跨資料節點均勻分布

1. GreenPlum資料庫查詢回應時間由所有資料節點完成時間來度量，系統只能跟最慢資料節點完成時間來決定，如果資料存盤傾斜，一個資料節點比其他節點需要花更多的時間來處理資料，資料存盤傾斜只會存在哈希分布的情況，
2. 在GreenPlum資料庫中；表關聯查詢最常見，若兩個或者多個表關聯的欄位非分布鍵或者采用隨機分布，在其他分布式架構這表之間的關系不是親和表，要執行連接，匹配的行必須位于同一節點上， 如果資料未在同一連接列上分發，則其中一個表所需的行將動態重新分發到其他節點， 有些情況下，執行廣播動作，每個節點將其各個行發送到所有其他節點上，而不是每個節點重新哈希資料并根據哈希值將行發送到適當的節點的重新分配，
3. 是不是還有一種復制表？在GreenPlum6.0以上的版本支持復制表，正好避免2中的廣播或者重分布動作，

二、分布策略

在GreenPlum資料庫在創建表時可以指定分布策略：哈希分布(DISTRIBUTED BY)、隨機分布(DISTRIBUTED RANDOMLY)、復制分布(DISTRIBUTED REPLICATED)，

• 哈希分布：需要指定分布鍵，會根據分布鍵的哈希值分配到對應的segment資料節點，相近的值會分配到同一個資料節點，
• 隨機分布：隨機分布無需指定分布鍵，這樣無法保證表中欄位的唯一性，因為同個值可能會分布在不同的資料節點，
• 復制分布：在GreenPlum6.0以上的版本支持復制表；Greenplum資料庫會將每個表行分發到每個節點實體， 復制表的資料均勻分布，因為每個節點具有相同的行，

如何選擇分布策略呢？我們現在來分析

2.1、單表查詢情況

結果驗證：好像沒區別

 2.2、表關聯查詢

現在我們創建一個表t_lottu;也插入10000條記錄

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

隨機策略：通過t_random_01與表t_lottu關聯

 哈希策略：

 通過上兩圖比較：可以判斷哈希策略略好；我這環境只有2個segment節點，效果不明顯，我們可以明顯可以看到在隨機策略查詢計劃里面那有Redistribute Motion， 這個在后面講解查詢計劃，這個叫資料重分布，后須講解，

為什么隨機策略會Redistribute Motion？

在哈希策略中；同樣的分布鍵的值肯定會分布到同一個segment節點，所以上面表t_hash_01和表t_lottu的分布鍵都是id欄位，所就可以在每個Segment節點關聯后，Segment節點把結果發送到Master節點，再由Master節點匯總，將最終的結果返還客戶端，而隨機分布則不能保證同樣分布鍵的資料分布在同一個Segment節點上，這樣在表關聯的時候，就需要將資料發送到所有Segment節點去做運算，這樣網路傳輸和大量資料運算都需要較長的時間，性能非常低下，所以在關聯的時候不建議使用隨機策略，

這里有一個問題了；是不是哈希策略查詢計劃就不會出現Redistribute Motion/Broadcast Motion(廣播)，答案是錯誤的，若分布鍵跟關聯的欄位不一致的情況，就會出現，分布鍵跟關聯的欄位是否一致？在其它分布式架構叫表的親和度，

2.3、資料分布傾斜的問題

既然不建議使用隨機策略；那我們都是用哈希策略不就好了嗎？

哈希策略是同樣的分布鍵的值肯定會分布到同一個segment節點，有可能造成資料分布傾斜的問題，在隨機策略不會出現這種情況，

資料分布傾斜的問題；待定，

-- 重新分布表資料

2.4、資料復制分布

在GreenPlum6.0版本中支持復制表，作用消除多表關聯中Redistribute Motion/Broadcast Motion帶來的性能消耗，也可用于單表的負載均衡，

在用于單表查詢；可以看出只需查詢一個節點即可，

 用于多表關聯消除多表關聯中Redistribute Motion/Broadcast Motion帶來的性能消耗 

 三、資料是如何存盤

創建表的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:

在前面有說到

參考：https://github.com/digoal/blog/blob/master/201708/20170818_02.md

Greenplum資料庫可以使用追加優化（append-optimized，AO）的存盤個事來批量裝載和讀取資料，并且能提供HEAP表上的性能優勢， 追加優化的存盤為資料保護、壓縮和行/列方向提供了校驗和，行式或者列式追加優化的表都可以被壓縮，

在創建表指定 APPENDONLY = TRUE為AO表，若不指定或者APPENDONLY = FALSE為堆表，

3.1、堆表

堆表是PostgreSQL資料庫原生存盤格式，GreenPlum默認的存盤格式，堆表存盤在OLTP型別負載下表現最好，這種環境中資料會在初始載入后被頻繁地修改， UPDATE和DELETE操作要求存盤行級版本資訊來確保可靠的資料庫事務處理， 堆表最適合于較小的表，例如維度表，它們在初始載入資料后會經常被更新，

多適合用于OLTP系統，但GreenPlum常定位是用于OLAP系統，為了更適合OLAP系統，GreenPlum提供來AO表

應用場景：

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

3.2、AO表

AO表在4.3版本之前取意為（APPEND-ONLY，AO），根據其意義只能追加，在4.3版本之后取意為（append-optimized，AO）追加優化，支持update/delete，跟堆表一樣，但實作原理不一樣，洗掉更新資料時，通過另一個BITMAP檔案來標記被洗掉的行，通過bit以及偏移對齊來判定AO表上的某一行是否被洗掉，

追加優化表存盤在資料倉庫環境中的非規范表表現最好， 非規范表通常是系統中最大的表， 事實表通常成批地被載入并且被只讀查詢訪問， 將大型的事實表改為追加優化存盤模型可以消除每行中的更新可見性資訊負擔，這可以為每一行節約大概20位元組， 這可以得到一種更加簡潔并且更容易優化的頁面結構， 追加優化表的存盤模型是為批量資料裝載優化的，因此不推薦單行的INSERT陳述句

AO支持壓縮以及列存

應用場景：

• 使用列存、壓縮資料使用AO表，
• 資料批量寫入使用AO表

3.3、行存和列存

ORIENTATION=COLUMN可以指定創建列存的AO表，列存的表只能是AO表，

• 行存：以行形式存盤表中，一行資料存在一個資料檔案中，適用于具有許多迭代事務的OLTP型別的作業負載以及一次需要多列的單行，因此檢索是高效的
• 列存：以列為形式組織存盤，每列對應一個或一批檔案，而且壓縮比例比較高，適合于在少量列上計算資料聚集的資料倉庫負載，或者是用于需要對單列定期更新但不修改其他列資料的情況

若一個寬表，在讀取某一個列資料；行存需要把匹配的列的所在的行資料塊都要掃描一遍，整好列存可以避免，但是帶來的問題是一個表對應多個資料檔案，

行存與列存的選擇以及轉換方法

備注：以上為本人理解；若有不對的地方；煩請指出，謝謝！

標籤：PostgreSQL

上一篇：sql注入基本原理

下一篇：一條查詢的SQL陳述句到底怎么執行的？