本文主要描述的是DB2數(shù)據(jù)庫分區(qū)管理，以及對為什么采用數(shù)據(jù)庫分區(qū)的原因描述，如果你對DB2數(shù)據(jù)庫分區(qū)，以及對為什么采用數(shù)據(jù)庫分區(qū)的原因描述以及相關內(nèi)容有興趣的話，你就可以對以下的文章點擊觀看了。

同時本文并以 Balanced Warehouse E7100 作為實例來對DB2 9.5數(shù)據(jù)庫分區(qū)管理的基本方法及應用實踐進行介紹。

DB2數(shù)據(jù)庫分區(qū)是 DB2企業(yè)版 DPF(Data Partitioning Feature)選件提供的，它主要用來為大規(guī)模數(shù)據(jù)處理、高并發(fā)數(shù)據(jù)訪問提供支持。DB2數(shù)據(jù)庫分區(qū)采用 Share-nothing 體系結構，數(shù)據(jù)庫在一個非共享的環(huán)境中被分解為獨立的分區(qū)，每個分區(qū)都具有自己的資源，例如內(nèi)存，CPU 和磁盤以及自己的數(shù)據(jù)、索引、配置文件和事務日志。數(shù)據(jù)庫分區(qū)有時稱為節(jié)點或數(shù)據(jù)庫節(jié)點。

數(shù)據(jù)通過 Hash 算法均允地散列到不同的分區(qū)內(nèi)，每個分區(qū)只負責處理自己的數(shù)據(jù)。當用戶發(fā)出 SQL 操作后，被連接的分區(qū)被稱為 Coordinate Node，它負責處理用戶的請求，并根據(jù) Partition key 將用戶的請求分解成多個子任務交由不同分區(qū)并行處理，***將不同分區(qū)的執(zhí)行結果經(jīng)過匯總返回給用戶，分區(qū)對應用來說是透明的。

在 DB2中，數(shù)據(jù)庫分區(qū)可以部署在集群或 MPP 環(huán)境下，也就是說數(shù)據(jù)庫分區(qū)分布在不同的機器上;數(shù)據(jù)庫分區(qū)也可以部署在同一臺 SMP 機器上，在同一臺機器上的分區(qū)我們稱為邏輯分區(qū)。同時，我們還可以在集群或 MPP 環(huán)境下部署多個分區(qū)，在集群或 MPP 每一個節(jié)點上部署多個邏輯分區(qū)。

DB2數(shù)據(jù)庫分區(qū)提供了強大的可擴展能力。由于采用 Share-nothing 體系結構，每個分區(qū)(節(jié)點)只處理它那一部分數(shù)據(jù)，分區(qū)之間盡可能獨立，這就減少了節(jié)點間共享資源的爭用，允許數(shù)據(jù)庫有效地伸縮以支持更大的數(shù)據(jù)規(guī)模及更多的用戶訪問。DB2數(shù)據(jù)庫分區(qū)提供 scale up (垂直擴展)及 scale out (水平擴展)能力。

垂直擴展是通過增加機器的物理資源如 cpu、磁盤、內(nèi)存來實現(xiàn)的;水平擴展是通過增加物理機器來實現(xiàn)的，DB2中，最多可以支持 1000 個分區(qū)。在規(guī)劃 DB2數(shù)據(jù)庫分區(qū)時，我們需要考慮是通過增加邏輯分區(qū)還是物理分區(qū)來實現(xiàn)擴展能力。

如果一臺物理機器上有多個 CPU，其物理資源可以允許多個分區(qū)共享該資源，我們可以通過增加邏輯分區(qū)來實現(xiàn)擴展;如果一臺物理機器上的物理資源不能滿足應用需求，我們就需要通過增加機器，也就是物理分區(qū)來實現(xiàn)擴展能力。

DB2數(shù)據(jù)庫分區(qū)還提供了強大的并行處理能力。首先，它提供了 inter-partition parallelism 分區(qū)間的并行機制，通過hash算法將數(shù)據(jù)庫請求分成多個任務在不同的分區(qū)上并行執(zhí)行，同時，提供了 intra-partition parallelism 分區(qū)內(nèi)的并行機制，將任務分解成不同的子任務，在不同的 CPU 上并行執(zhí)行。

另外，我們還可以同時利用 inter-partition parallelism、intra-partition parallelism 來實現(xiàn)完全的并行處理能力。DB2數(shù)據(jù)庫的查詢操作、backup/restore/load 等實用程序及 I/O 操作都可以通過上述的并行處理能力來顯著提高其性能。

為什么采用數(shù)據(jù)庫分區(qū)

采用數(shù)據(jù)庫分區(qū)，可以為您帶來如下好處：

查詢擴展性

這是采用數(shù)據(jù)庫分區(qū)最主要的原因之一。將一個大的數(shù)據(jù)庫分成多個小的數(shù)據(jù)庫可以提高查詢的性能，因為每個數(shù)據(jù)庫分區(qū)擁有自己的一小部分數(shù)據(jù)。假設您想掃描1億條記錄，對一個單一分區(qū)的數(shù)據(jù)庫來講，該掃描操作需要數(shù)據(jù)庫管理器獨立掃描一億條記錄，如果您將數(shù)據(jù)庫系統(tǒng)做成50個分區(qū)，并將這1億條記錄平均分配到這50個分區(qū)上，那么每個數(shù)據(jù)庫分區(qū)的數(shù)據(jù)庫管理器將只掃描200萬記錄。

架構限制

在DB2V8和以前版本，非分區(qū)數(shù)據(jù)庫的***的表取決于頁面大小，4K頁***支持64 GB，32K頁***支持512 GB數(shù)據(jù)量。表和表空間大小限制是每個分區(qū)上的限制，因此將數(shù)據(jù)庫分成N個分區(qū)可以將表的***尺寸增加為單個分區(qū)表***尺寸的N倍。內(nèi)存也可能是個限制，特別是在32為操作系統(tǒng)環(huán)境，因為每個DB2 9.5數(shù)據(jù)庫分區(qū)管理并擁有自己的資源，因此通過數(shù)據(jù)庫分區(qū)可以克服這個限制。

數(shù)據(jù)庫裝載性能

數(shù)據(jù)庫分區(qū)可以并行裝載數(shù)據(jù)到所有數(shù)據(jù)庫分區(qū)，極大減少單表的裝載時間，這對于像實時商業(yè)智能系統(tǒng)那樣對數(shù)據(jù)裝載的時間要求特別高的系統(tǒng)特別重要。

數(shù)據(jù)庫維護性能

將數(shù)據(jù)庫分散到多個數(shù)據(jù)庫分區(qū)服務器可以加快系統(tǒng)維護，因為每個操作都運行在分區(qū)所管理的一個數(shù)據(jù)子集上面，這樣可以通過數(shù)據(jù)庫分區(qū)進一步減少創(chuàng)建索引的時間，減少搜集統(tǒng)計信息的時間，因為runstats僅運行在一個數(shù)據(jù)庫分區(qū)上面，減少表重整(reorg)的時間。

備份/恢復性能

將數(shù)據(jù)庫分區(qū)到不同的數(shù)據(jù)庫服務器上可以大大減少數(shù)據(jù)庫備份的時間，這往往是決定是否使用數(shù)據(jù)庫分區(qū)很重要的一點。DB2通過為每個表空間分配獨立的進程或線程來實現(xiàn)備份和恢復操作的并行處理的。在分區(qū)數(shù)據(jù)庫環(huán)境的備份中，每個分區(qū)的備份是獨立的，通過并行備份數(shù)據(jù)庫分區(qū)可以大大減少備份整個數(shù)據(jù)庫的時間。

日志

在高度活動的系統(tǒng)中，數(shù)據(jù)庫日志的性能可能會限制系統(tǒng)的整體吞吐量。在分區(qū)數(shù)據(jù)庫環(huán)境中，每個分區(qū)有自己一套日志。當大量插入、更新、刪除操作時，多個數(shù)據(jù)庫分區(qū)可以提高性能，因為日志是在每個數(shù)據(jù)庫分區(qū)上是并行寫的，且每個單一的分區(qū)需要記錄的日志更少。

DB2隨數(shù)據(jù)量或處理器和分區(qū)的增加，提供近線性的擴展能力，可是，數(shù)據(jù)庫分區(qū)是否提供最多的益處依賴于處理的工作負荷、***表的大小及其他因素。

什么時候采用數(shù)據(jù)庫分區(qū)

設計數(shù)據(jù)庫分區(qū)的基本原則是，盡量將大表分布在所有的分區(qū)上，提高并行處理能力;將小表放置在盡量少的分區(qū)上，一般是建議放在單一分區(qū)上;盡量減少分區(qū)間的通信。對于是否采用數(shù)據(jù)庫分區(qū)，除了考慮上一節(jié)提到的分區(qū)的優(yōu)勢之外，我們也要根據(jù)分區(qū)設計原則來考慮：

選擇數(shù)據(jù)庫分區(qū)的一個比較理想的場景是執(zhí)行一條像 ” select count(*) from big_table”這樣的語句。如果將這個表放在所有分區(qū)上，則每個分區(qū)都可以計算該表在其上的行數(shù)，并將這個局部總數(shù)(subtotal)發(fā)送到協(xié)調(diào)分區(qū)，以便計算總和，而這里的通信成本比起每個分區(qū)上所做的工作來可以忽略不計。

另一個非常合適的場景是， 一個大表與幾個非常小的很少更新的表相連接。大表是分區(qū)的，小表則被復制到每個分區(qū)上，這樣就可以并置連接。

不適合使用分區(qū)的是那些在連接時涉及很多大表和各種各樣的表和列的 ad hoc 查詢環(huán)境。在那些情況下， 很難或者不可能選擇表的分區(qū)鍵，使得所有大的查詢執(zhí)行起來沒有很多的分區(qū)間通信。

同樣不適合使用分區(qū)的是那些有多條不能在單個分區(qū)內(nèi)處理的非常小的語句。在這種情況下，分區(qū)間通信的開銷比起這些語句的本地執(zhí)行來就相當高，而如果使用分區(qū)的話(尤其是跨多個物理系統(tǒng))，響應時間就會大大惡化。

大多數(shù)工作負載和一些特定的任務都處于剛才討論的這兩種極端之間，這些地方都需要通過原型來研究使用分區(qū)所帶來的影響。以上的相關內(nèi)容就是對DB2 9.5數(shù)據(jù)庫分區(qū)管理及應用實踐的介紹，望你能有所收獲。

【編輯推薦】

1. DB2 CMO安裝7.1.2.6補丁之后會出現(xiàn)什么？
2. DB2數(shù)據(jù)庫在創(chuàng)建存儲過程中有哪些錯誤出現(xiàn)？
3. DB2 9.5分區(qū)管理以及其應用實踐的詳細描述
4. DB2數(shù)據(jù)庫物化視圖之MQT物化查詢表如何操作？
5. 用DB2dart恢復數(shù)據(jù)的正確操作步驟詳解