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。

如:

这个文件可以按上面格式手工生成,但是通常情况下是利用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分区数据库中的相关数据分布倾斜现象与重新分布的实际操作方法的介绍，望你能有所收获。

【编辑推荐】