DB2分區數據庫數據分布傾斜現象與重新分布
以下的文章主要向大家講述的是DB2分區數據庫中的相關數據分布傾斜現象與重新分布的實際操作方法的描述，你如果對DB2分區數據庫中的相關數據分布傾斜現象與重新分布的實際操作方法的描述有興趣的話你就可以點擊以下的文章進行觀看了。
數據庫, 分區, 現象數據庫, 分區, 現象
環境
產品：DB2 UDB
平臺：跨平臺
軟件：V8，V9
問題
主要描述了DB2分區數據庫中的數據分布不均現象，以及如何對數據進行重新分布的方法。
解答
DB2的數據庫分區功能使用戶能更具靈活的控制數據的分布,通過對分區鍵(partition key)的選擇,用戶可以控制他們數據的分布，同時也能通過選擇分區組(partition group)決定把他們的數據分布在哪些分區上，此外還提供了一個分區鍵在分區上的詳細分區映射(partition map)。
分區數據庫通過提供對分布在各個分區上的數據的并發訪問，提高了應用程序訪問操作的性能，但這同時也增加了分區數據庫日常維護的復雜性.
數據在DB2分區數據庫的存取分布策略是用分區鍵值通過哈希算法(hashing algorithm)得到的值，根據對應的分區映射(partition map)散列到各個分區的.而用戶數據的差異以及分區鍵選擇的不合理導致最終的分布往往發生數據傾斜(data skew).
下面這個例子是一個兩臺物理機器4個邏輯節點的數據庫,我向一個空表導入10240條數據(由1-20的int數字循環組成)后查看數據在各個分區節點中的分布情況是:
例1：
- db2 "select dbpartitionnum(i),count(*) from load_dpf group by dbpartitionnum(i) order by dbpartitionnum(i)"
可以看到數據并沒有在各個節點上均勻分布,而是發生了一定的數據傾斜(data skew)。通常情況下，數據在分區中的分布都會發生一定的傾斜,如果傾斜程度不大，就不會有太大影響，所以不用人為干預,但是在下面所列情況下就需要對數據在各分區的分布進行調整了：
A. 如果傾斜過大，將會使系統I/O的負荷也隨之傾斜，導致某些分區的I/O過大而產生瓶頸，而不能均勻發揮所有I/O的性能.在這種情況下需要人為干預，利用redistribute partition group 命令來重新分布數據.
B. 如果需要從分區組中移出某個分區,也同樣需要利用redistribute partition group 命令來重新分布數據,把數據從那個即將移出的分區上重新分布到其他分區.
C. 將一個新的分區加入分區組后，同樣需要把其他分區上的數據分布到新添加分區,類似rebalance操作.
下面是redistribute的語法:
其中各個參數的詳細解釋可以參閱信息中心的相關解釋：
http://publib.boulder.ibm.com/in ... /core/r0002069.htm?
默認分區映射如下:
1. UNIFORM : 這種形式的重分布是將數據盡量均勻的分布到各個哈希分區(hash partition)(hash partition 共有4096個)。雖然數據均勻分布到各個哈希分區(hash partition)上,但是同樣的哈希分區(hash parititon)數并不一定映射到每個數據庫分區(database partition)上.在重分布完成后，各個數據庫分區將擁有相近的哈希分區(hash partition)個數
在分區鍵值沒有發生傾斜的時候，UNIFORM能夠將數據接近平均的分布到每個數據庫分區上,所以此方法大多數用于第上面C類情況.
2. USING DISTFILE : 這種形式的分布多用于分區鍵本身的值就已經發生了傾斜,如上例1的分區鍵就是1-20的循環數字.在這種情況下，根據hash算法產生的結果發生了傾斜.這時候就需要人工指定一個分布文件來替代系統產生的結果.#p#
這個文件包含4096個值（類似如下命令產生的分布文件 dist.out 文件）,用于標記每個hash分區的權重.這些值的總和要大于0不大于4,294,967,295。
如:
- 1024
- 0
- 412
- ...
- 612
- ...
- ...
- 2048
這個文件可以按上面格式手工生成,但是通常情況下是利用load對分區導入的analyze模式來生成的。
首先用 db2gpmap -d <db name> -g <partition group> 生成作為分區映射的 mygroup.out 文件，然后執行：
- db2 "load from load.del of del messages msg.txt replace into load_dpf partitioned db config mode
analyze map_file_input mygroup.out map_file_output analyze.out distfile dist.out"
此方法可以認為干預現有數據的分布,但是無法改變后續數DB2分區數據庫據分布策略.所以如果可能還是調整分區鍵重新選擇合適的分區鍵.
例2：
- [db2inst1@rhel5 tmp]$ db2 "redistribute database partition group ibmdefaultgroup using distfile dist.out"
- [db2inst1@rhel4 tmp]$ db2 "select dbpartitionnum(i),count(*) from load_dpf group by dbpartitionnum(i) order by dbpartitionnum(i)"
- [db2inst1@rhel4 tmp]$ db2 "insert into load_dpf values(1234)"
- DB20000I The SQL command completed successfully.
- [db2inst1@rhel4 tmp]$ db2 "insert into load_dpf values(1234324)"
- DB20000I The SQL command completed successfully.
- [db2inst1@rhel4 tmp]$ db2 "insert into load_dpf values(123123)"
- DB20000I The SQL command completed successfully.
- [db2inst1@rhel4 tmp]$ db2 "select dbpartitionnum(i),count(*) from load_dpf group by dbpartitionnum(i) order by dbpartitionnum(i)"
從上面結果可以看出新插入的數據并沒有根據dist.out的權重策略去分配,數據依然是根據分區鍵的哈希(hash)值對應的分區映射來分布的.
3. USING TARGETMAP : 用目標分區映射來進行重分布主要適用于類型B,通過人工調整可以把某個分區的數據分布到其他分區上。
例3：
如果手工把分區映射中0號節點替換成2號節點，分區映射文件 mygroup.out 內容類似：
- 2 1 2 3 2 1 2 3 2 1 2 3 2 1 2 3 2 1 2 3 2 1 2 3 2 1 2 3 2 1 ...
則運行：
- db2 "redistribute database partition group ibmdefaultgroup using targetmap mygroup.out"
的結果是:
如果用如上的load的分析功能對mygroup.out分區映射產生的新分區映射analyze.out進行重分布的結果是:
從上面結果可以看出load加analyze選項的分析結果比原始文件更加優化,所以建議使用load分析功能對分區映射進行進一步的優化后再進行重分布.
NOTE:
在做完 REDISTRIBUTE DATABASE PARTITION GROUP 操作后，需要運行 RUNSTATS 來更新統計信息.由于REDISTRIBUTE對表的數據操作是作為一個完整的事務,所以如果表的數據量很大，則需要提前調高活動日志大小或數目.
REDISTRIBUTE DATABASE PARTITION GROUP 在db2v9.5中得到了增強,原來添加和刪除節點是和redistribute 操作分開的,在db2v9.5中被整合成redistribute的一部分"Add/Drop DB partition",減少了操作步驟,大大方便了用戶的操作.以上的相關內容就是對DB2分區數據庫中的相關數據分布傾斜現象與重新分布的實際操作方法的介紹，望你能有所收獲。
【編輯推薦】
- DB2***SQL性能調節技術經典版
- IBM DB2數據庫與注意事項_DB2編程的描述
- DB2 并行版本中的查詢優化登峰造極！
- 對DB2 增量備份的正確運用描述
- DB2 存儲過程的異常處理器類型有幾種？
