table db2inst1.multi_t_cust 的DDL:
CREATE TABLE "DB2INST1"."MULTI_T_CUST" (
"CUSTID" INTEGER NOT NULL ,
"CUSTNAME" VARCHAR(20) NOT NULL ,
"SEX" VARCHAR(4) NOT NULL ,
"BIRTHDAY" DATE NOT NULL ,
"EDUCATION" VARCHAR(20) NOT NULL ,
"ADDRESS" VARCHAR(40) NOT NULL ,
"PHONENO" INTEGER NOT NULL ,
"FUND" DECIMAL(22,2) NOT NULL ,
"COMMISION" DECIMAL(22,2) NOT NULL ,
"REMARK" VARCHAR(200) NOT NULL )
PARTITIONING KEY (CUSTID) USING HASHING // 这里DB2 v9.7的标准推荐写法是 DISTRIBUTE BY(CUSTID) USING HASHING
IN "MULTITBS"
partition by range(CUSTID)
(PARTITION lower STARTING FROM (1) ENDING AT (500000),
PARTITION upper STARTING FROM (500001) ENDING AT (1100000) //lower, upper 会在后面的操作中使用到
);
ALTER TABLE "DB2INST1"."MULTI_T_CUST"
ADD PRIMARY KEY
("CUSTID");
db2 "import from t_cust.del of del insert into db2inst1.multi_t_cust"
这里会插入100万行数据，
db2 "select dbpartitionnum(CUSTID),count(*) from db2inst1.multi_t_cust group by dbpartitionnum(CUSTID) order by dbpartitionnum(CUSTID)"
0 250088
1 250450
2 249858
3 249604
4 record(s) selected.
数据分布较均匀，这里测试环境的DPF是4个数据节点
下面的特性是table partition (即TP) 提供，roll-in 和 roll-out 中文说滚入，滚出
db2 "alter table multi_t_cust detach partition lower into multi_t_cust_old" //multi_t_cust_old这个表无需手动创建，执行这个命令后会生成这个表
这个操作很快就成功结束，再来看multi_t_cust表的数量：
db2 "select count(*) from multi_t_cust"
1
-----------
500000
1 record(s) selected.
multi_t_cust_old表的数据量为是500000
db2 "select count(*) from multi_t_cust_old"
1
-----------
500000
1 record(s) selected.
将滚出的50万数据再次滚入到multi_t_cust表：
db2 "alter table multi_t_cust attach partition lower starting (1) ending (500000) from table multi_t_cust_old"
上面的命令也会很快执行完毕，但是要想看到表里面的数据真正发生变化，还需要执行下面的命令：
db2 SET INTEGRITY for multi_t_cust immediate checked
现在的大小就是100万行：
db2 "select count(*) from multi_t_cust"
1
-----------
1000000
1 record(s) selected.
简单总结：
DPF 将行均匀地分布在多个数据库分区上 可伸缩性 —— 随着数据库的增长增加计算资源（也就是数据库分区）
MDC 将在多个维上具有近似值的行放在表中相同的物理位置，即所谓的块 查询性能 —— 组织数据的方式有利于获得更快的检索速度，对于由多个谓词指定范围的查询尤其有效
TP 将所有行放在同一个数据分区的一个指定范围的维中 数据移动 —— 通过添加和删除整个数据分区，可以增加和删除大量数据
互补特性
本节详细阐述前面提出的观点，这 “三个朋友” 既是独立的，又是互补的。
当设计一个表时，对每个特性的使用可以认为是独立的。
是否使用 MDC 和 TP 对于决定 DPF 的分布键没有影响。
一个列是否被用作 MDC 维对于是否应该将它作为表分区键没有影响，反之亦然。每个决定都可以单独做出。
每个特性的工作方式，例如索引方面，不会随着新的分区特性的引入而改变。例如，当引入 MDC 时，它的索引方面不会改变 DPF 在索引方面的工作方式。同样，当引入 TP 时，也不会改变 DPF 或 MDC 在索引方面的行为。在学习这些特性的时候，记住这一点有助于避免陷入困惑。
表设计
数据仓库中的事实表（或历史表）非常适合使用上述每种特性；
对于 DPF，在选择一个分布键时，应首选那种能使数据行均匀地分布在多个数据库分区上的列。当不具备这样的条件时，就会造成数据倾斜。这意味着一个或一些数据 库分区承担了更重比例的表行，从而造成了性能瓶颈。具有很多不同值的列是较好的选择。还有一种考虑是选择能最大化联结性能的列。
另一个 DPF 设计决定是数据库分区的数量。数据库分区的数量不算是表设计方面的考虑。实际上，它是整个系统设计上的考虑，需要根据整个数据库预期的原始数据大小和服务 器硬件的能力来决定。很多系统需要的数据库分区不超过 20 个。但是，最大的系统可能需要更多的数据库分区。由于数据仓库有越来越大的趋势，数据库分区的数量有望增加。
对于 TP，设计决定包括选择用作表分区键的列和分区的数量。通常表分区键是基于时间的列。每个分区与每次转入的数据量相符。例如，每月转出数据的表，对于每个 月的数据都有一个分区。对于 TP，在设计时需要特别考虑的一点是，需要处理不在 CREATE table 语句中定义的值范围内的行。
对于需要每月根据 sale_date 转出数据的数据库，一种典型的设计是使用 sale_date 作为表分区键，并为每个月创建一个单独的分区。
分区特性设计决定 经验法则
DPF —— 用作分布键的列 首选是具有很多不同值的列
MDC —— 用作 MDC 维的列 一种典型的设计是选择一个表示日期的列，再加上 0 到 3 个其他列，例如 region 和 product_type
TP —— 用作表分区键的列和分区的数量 选择一个基于时间的列。定义与每次转出的数据量相符的分区
详细信息也可参考下面文章：
http://hi.baidu.com/mcj0127/blog/item/07fa7ddbeeb7916bd0164eed.html
阅读(2572) | 评论(0) | 转发(0) |
