DB2 9.5分区管理以及其应用实践的详细描述-db2分区查询

此文章主要向大家讲述的是DB2 9.5分区管理以及其应用实践，以及对为什么采用数据库分区，并且以 Balanced Warehouse E7100 为例对数据库分区管理的基本方法及应用实践进行介绍。

DB2数据库分区是 DB2企业版 DPF(Data Partitioning Feature)选件提供的，它主要用来为大规模数据处理、高并发数据访问提供支持。DB2数据库分区采用 Share-nothing 体系结构，数据库在一个非共享的环境中被分解为独立的分区，每个分区都具有自己的资源，例如内存，CPU 和磁盘以及自己的数据、索引、配置文件和事务日志。数据库分区有时称为节点或数据库节点。

数据通过 Hash 算法均允地散列到不同的分区内，每个分区只负责处理自己的数据。当用户发出 SQL 操作后，被连接的分区被称为 Coordinate Node，它负责处理用户的请求，并根据 Partition key 将用户的请求分解成多个子任务交由不同分区并行处理，***将不同分区的执行结果经过汇总返回给用户，分区对应用来说是透明的。

在 DB2中，数据库分区可以部署在集群或 MPP 环境下，也就是说数据库分区分布在不同的机器上;数据库分区也可以部署在同一台 SMP 机器上，在同一台机器上的分区我们称为逻辑分区。同时，我们还可以在集群或 MPP 环境下部署多个分区，在集群或 MPP 每一个节点上部署多个逻辑分区。

DB2数据库分区提供了强大的可扩展能力。由于采用 Share-nothing 体系结构，每个分区(节点)只处理它那一部分数据，分区之间尽可能独立，这就减少了节点间共享资源的争用，允许数据库有效地伸缩以支持更大的数据规模及更多的用户访问。DB2数据库分区提供 scale up (垂直扩展)及 scale out (水平扩展)能力。

垂直扩展是通过增加机器的物理资源如 cpu、磁盘、内存来实现的;水平扩展是通过增加物理机器来实现的，DB2中，最多可以支持 1000 个分区。在规划 DB2数据库分区时，我们需要考虑是通过增加逻辑分区还是物理分区来实现扩展能力。

如果一台物理机器上有多个 CPU，其物理资源可以允许多个分区共享该资源，我们可以通过增加逻辑分区来实现扩展;如果一台物理机器上的物理资源不能满足应用需求，我们就需要通过增加机器，也就是物理分区来实现扩展能力。

DB2数据库分区还提供了强大的并行处理能力。首先，它提供了 inter-partition parallelism 分区间的并行机制，通过hash算法将数据库请求分成多个任务在不同的分区上并行执行，同时，提供了 intra-partition parallelism 分区内的并行机制，将任务分解成不同的子任务，在不同的 CPU 上并行执行，另外，我们还可以同时利用 inter-partition parallelism、intra-partition parallelism 来实现完全的并行处理能力。DB2数据库的查询操作、backup/restore/load 等实用程序及 I/O 操作都可以通过上述的并行处理能力来显著提高其性能。

为什么采用数据库分区

采用数据库分区，可以为您带来如下好处：

查询扩展性

这是采用数据库分区最主要的原因之一。将一个大的数据库分成多个小的数据库可以提高查询的性能，因为每个数据库分区拥有自己的一小部分数据。假设您想扫描1亿条记录，对一个单一分区的数据库来讲，该扫描操作需要数据库管理器独立扫描一亿条记录，如果您将数据库系统做成50个分区，并将这1亿条记录平均分配到这50个分区上，那么每个数据库分区的数据库管理器将只扫描200万记录。

架构限制

在DB2V8和以前版本，非分区数据库的***的表取决于页面大小，4K页***支持64 GB，32K页***支持512 GB数据量。表和表空间大小限制是每个分区上的限制，因此将数据库分成N个分区可以将表的***尺寸增加为单个分区表***尺寸的N倍。内存也可能是个限制，特别是在32为操作系统环境，因为每个数据库DB2 9.5分区管理并拥有自己的资源，因此通过数据库分区可以克服这个限制。

数据库装载性能

数据库分区可以并行装载数据到所有数据库分区，极大减少单表的装载时间，这对于像实时商业智能系统那样对数据装载的时间要求特别高的系统特别重要。

数据库维护性能

将数据库分散到多个数据库分区服务器可以加快系统维护，因为每个操作都运行在分区所管理的一个数据子集上面，这样可以通过数据库分区进一步减少创建索引的时间，减少搜集统计信息的时间，因为runstats仅运行在一个数据库分区上面，减少表重整(reorg)的时间。

备份/恢复性能

将数据库分区到不同的数据库服务器上可以大大减少数据库备份的时间，这往往是决定是否使用数据库分区很重要的一点。DB2通过为每个表空间分配独立的进程或线程来实现备份和恢复操作的并行处理的。在分区数据库环境的备份中，每个分区的备份是独立的，通过并行备份数据库分区可以大大减少备份整个数据库的时间。

日志

在高度活动的系统中，数据库日志的性能可能会限制系统的整体吞吐量。在分区数据库环境中，每个分区有自己一套日志。当大量插入、更新、删除操作时，多个数据库分区可以提高性能，因为日志是在每个数据库分区上是并行写的，且每个单一的分区需要记录的日志更少。

DB2随数据量或处理器和分区的增加，提供近线性的扩展能力，可是，数据库分区是否提供最多的益处依赖于处理的工作负荷、***表的大小及其他因素。

什么时候采用数据库分区

设计数据库分区的基本原则是，尽量将大表分布在所有的分区上，提高并行处理能力;将小表放置在尽量少的分区上，一般是建议放在单一分区上;尽量减少分区间的通信。对于是否采用数据库分区，除了考虑上一节提到的分区的优势之外，我们也要根据分区设计原则来考虑：

选择数据库分区的一个比较理想的场景是执行一条像 ” select count(*) from big_table”这样的语句。如果将这个表放在所有分区上，则每个分区都可以计算该表在其上的行数，并将这个局部总数(subtotal)发送到协调分区，以便计算总和，而这里的通信成本比起每个分区上所做的工作来可以忽略不计。

另一个非常合适的场景是，一个大表与几个非常小的很少更新的表相连接。大表是分区的，小表则被复制到每个分区上，这样就可以并置连接。

不适合使用分区的是那些在连接时涉及很多大表和各种各样的表和列的 ad hoc 查询环境。在那些情况下，很难或者不可能选择表的分区键，使得所有大的查询执行起来没有很多的分区间通信。

同样不适合使用分区的是那些有多条不能在单个分区内处理的非常小的语句。在这种情况下，分区间通信的开销比起这些语句的本地执行来就相当高，而如果使用分区的话(尤其是跨多个物理系统)，响应时间就会大大恶化。

大多数工作负载和一些特定的任务都处于刚才讨论的这两种极端之间，这些地方都需要通过原型来研究使用分区所带来的影响，以上的相关内容就是对DB2 9.5分区管理以及其应用实践的介绍，望你能有所收获。

【编辑推荐】