DB2 9.5 数据库分区管理及应用实践

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

　　数据通过 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 操作都可以通过上述的并行处理能力来显著提高其性能。如下图所示：
　　图 2. DB2 数据库分区并行处理示例图

　　为什么采用数据库分区
　　采用数据库分区，可以为您带来如下好处：
　　查询扩展性
　　这是采用数据库分区最主要的原因之一。将一个大的数据库分成多个小的数据库可以提高查询的性能，因为每个数据库分区拥有自己的一小部分数据。假设您想扫描1亿条记录，对一个单一分区的数据库来讲，该扫描操作需要数据库管理器独立扫描一亿条记录，如果您将数据库系统做成50个分区，并将这1亿条记录平均分配到这50个分区上，那么每个数据库分区的数据库管理器将只扫描200万记录。
　　架构限制
　　在DB2 V8和以前版本，非分区数据库的最大的表取决于页面大小，4K页最大支持64 GB，32K页最大支持512 GB数据量。表和表空间大小限制是每个分区上的限制，因此将数据库分成N个分区可以将表的最大尺寸增加为单个分区表最大尺寸的N倍。内存也可能是个限制，特别是在32为操作系统环境，因为每个数据库分区管理并拥有自己的资源，因此通过数据库分区可以克服这个限制。
　　数据库装载性能
　　数据库分区可以并行装载数据到所有数据库分区，极大减少单表的装载时间，这对于像实时商业智能系统那样对数据装载的时间要求特别高的系统特别重要。
　　数据库维护性能
　　将数据库分散到多个数据库分区服务器可以加快系统维护，因为每个操作都运行在分区所管理的一个数据子集上面，这样可以通过数据库分区进一步减少创建索引的时间，减少搜集统计信息的时间，因为runstats仅运行在一个数据库分区上面，减少表重整(reorg)的时间。
　　备份/恢复性能
　　将数据库分区到不同的数据库服务器上可以大大减少数据库备份的时间，这往往是决定是否使用数据库分区很重要的一点。DB2 通过为每个表空间分配独立的进程或线程来实现备份和恢复操作的并行处理的。在分区数据库环境的备份中，每个分区的备份是独立的，通过并行备份数据库分区可以大大减少备份整个数据库的时间。
　　日志
　　在高度活动的系统中，数据库日志的性能可能会限制系统的整体吞吐量。在分区数据库环境中，每个分区有自己一套日志。当大量插入、更新、删除操作时，多个数据库分区可以提高性能，因为日志是在每个数据库分区上是并行写的，且每个单一的分区需要记录的日志更少。
　　DB2 随数据量或处理器和分区的增加，提供近线性的扩展能力，可是，数据库分区是否提供最多的益处依赖于处理的工作负荷、最大表的大小及其他因素。
　　什么时候采用数据库分区
　　设计数据库分区的基本原则是，尽量将大表分布在所有的分区上，提高并行处理能力;将小表放置在尽量少的分区上，一般是建议放在单一分区上;尽量减少分区间的通信。对于是否采用数据库分区，除了考虑上一节提到的分区的优势之外，我们也要根据分区设计原则来考虑：
　　选择数据库分区的一个比较理想的场景是执行一条像 ” select count(*) from big_table”这样的语句。如果将这个表放在所有分区上，则每个分区都可以计算该表在其上的行数，并将这个局部总数(subtotal)发送到协调分区，以便计算总和，而这里的通信成本比起每个分区上所做的工作来可以忽略不计。
　　另一个非常合适的场景是， 一个大表与几个非常小的很少更新的表相连接。大表是分区的，小表则被复制到每个分区上，这样就可以并置连接。
　　不适合使用分区的是那些在连接时涉及很多大表和各种各样的表和列的 ad hoc 查询环境。在那些情况下， 很难或者不可能选择表的分区键，使得所有大的查询执行起来没有很多的分区间通信。
　　同样不适合使用分区的是那些有多条不能在单个分区内处理的非常小的语句。在这种情况下，分区间通信的开销比起这些语句的本地执行来就相当高，而如果使用分区的话(尤其是跨多个物理系统)，响应时间就会大大恶化。
　　大多数工作负载和一些特定的任务都处于刚才讨论的这两种极端之间，这些地方都需要通过原型来研究使用分区所带来的影响。
　　数据库分区实现
　　下边，我们以 IBM InfoSphere Balanced Warehouse E7100 为例，介绍一下DB2 分区数据库在AIX下的基本管理方法及应用实践。DB2 分区数据库在 Windows 环境下的管理方法和 AIX 略有不同，具体请参阅相关手册。
　　IBM InfoSphere Balanced Warehouse 是IBM针对客户数据仓库系统提出的一整套完整的解决方案。当用户实施一个数据仓库系统时，对用户来说，一个非常大的挑战就是未来的数据仓库系统应该选择什么样的服务器，服务器的配置是什么，选择多少台服务器;选择什么样的存储设备，存储容量要多大，存储设备配置是什么;选择什么样的网络设备，它的配置是什么才能保证系统性能高效、稳定。同时，随着系统的应用，数据量会急剧增长，如何在保证系统性能的前提下，提供更好的系统扩展能力也是用户非常关心的问题。为了解决上述问题，IBM 结合自己多年实施客户数据仓库系统的经验，并协同IBM软件部门、服务器部门、存储部门及实验室，共同推出了 InfoSphere Balanced Warehouse 解决方案，有时也称为 BCU(Balanced Configuration Unit)。InfoSphere Balanced Warehouse 是一个包含服务器、存储、数据仓库软件在内的完整解决方案，它基于 IBM 最佳实践并得到充分验证，是一个预先配置好的、可立即使用的解决方案，客户无需靠猜测或假象去配置并验证，实现开箱即用。InfoSphere Balanced Warehouse 采用平衡的理念，每个组件(数据库、服务器和存储)提供均衡的性能确保整体方案性能最优。同时，它采用可扩展的模块化设计，数据仓库系统在整个生命周期中，可以以增量的方式进行扩展，达到的性能可预见、可度量。
　　InfoSphere Balanced Warehouse主要由以下几个模块组成：如下图：
　　图 3. InfoSphere Balanced Warehouse 模块组成

　　Foundation Module: 有时也称为 administration BCU。该模块主要包括编目分区、协调分区以及单分区表。系统必须要有 1 个 Foundation Module。
　　Data Module: 有时也称为 data BCU。该模块主要保存分区表数据。根据数据量，可以有 1 个或多个 Data Module。
　　User Module: 如果系统有大量用户访问，我们可以考虑增加 User Module。
　　Failover Module: 用于满足 HA 的需求。
　　Application Module: 用于运行应用程序，比如说 ETL 应用就可以配置在 Application Module 上。
　　本次配置环境包括一个 administration BCU 和 2 个 data BCU，如下图所示：
　　图 4. InfoSphere Balanced Warehouse 配置图

　　创建实例及配置通信连接
　　使用db2icrt命令创建实例
　　/opt/IBM/db2/V9.1/instance/db2icrt -u bcufenc bcuaix
　　配置TCPIP通信服务
　　db2set DB2COMM=tcpip
　　修改DBM CFG 中的 SVCENAME参数
　　db2 update dbm config using svcename xbcuaix
　　在实例级禁用fault monitor
　　db2fm -i instance_name -f no
　　创建诊断文件目录
　　缺省的情况下，db2diag.log 文件创建在 ~/sqllib/db2dump 目录下，这个目录是 NFS-mounted，我们一般建议要将 db2diag.log 文件放在非 NFS-mounted 目录下。在 E7100 实施中，我们建议将该文件放到外部的存储上。
　　Administration BCU:
　　mkdir -p /db2path/bcuaix/NODE0000/SQL00001/db2dump
　　Data BCU 1:
　　mkdir -p /db2path/bcuaix/NODE0001/SQL00001/db2dump
　　Data BCU 2:
　　mkdir -p /db2path/bcuaix/NODE0009/SQL00001/db2dump
　　Administration BCU:
　　ln -s /db2path/bcuaix/NODE0000/SQL00001/db2dump /db2path/bcuaix/db2dump
　　Data BCU 1:
　　ln -s /db2path/bcuaix/NODE0001/SQL00001/db2dump /db2path/bcuaix/db2dump
　　Data BCU 2:
　　ln -s /db2path/bcuaix/NODE0009/SQL00001/db2dump /db2path/bcuaix/db2dump
　　db2 update dbm config using diagpath /db2path/bcuaix/db2dump
　　定义数据库分区
　　在数据库分区环境下，数据库被分为多个分区，分区之间彼此独立工作，实现并行操作。数据库分区可以是物理分区也可以是逻辑分区。在一台物理机器上部署的一个分区，我们称为物理分区，如果是在一台 SMP 机器上部署多个分区，这些分区我们称为逻辑分区。我们可以选择物理分区，也可以选择逻辑分区。通常，如果决定采用大的 SMP 机器，有更多的 CPU、内存及硬盘，我们会采用逻辑分区;如果决定采用多台物理机器，我们会通过非共享的体系结构采用物理分区;如果决定采用多台 SMP 机器，我们则会采用物理分区和逻辑分区结合的方式。
　　在 DB2 数据库分区环境中，执行 CREATE DATABASE 语句所在的分区称为编目分区(catalog partition)。编目分区保存系统编目表。编目分区只能创建在一个分区上。通常，在实际生产环境中，我们建议采用一个专用编目分区，这个分区只包含编目表，不包含用户数据。这对 DB2 的一些实用程序运行效率有较大的提高。比如说 BACKUP 和 RESTORE 命令，需要先在编目分区上运行，之后才能在其他分区上执行。由于编目分区上没有用户数据，因此它的备份和恢复就可以很快完成，并且可以最小程度地延迟对其他分区的(并行)操作的开始。
　　在 DB2 数据库分区环境中，应用程序连接的分区，我们称为协调分区(coordinate partition)。它负责处理用户的请求，并根据 Partition key 将用户的请求分解成多个子任务交由不同分区并行处理，最后将不同分区的执行结果经过汇总返回给用户。任何一个数据库分区都可以是协调分区。在实际生产环境中，我们建议采用一个或几个专用协调分区。因为应用程序要通过一个或多个协调分区为用户连接转移大量的数据的话，那么就会消耗那些分区上的大部分 CPU，并降慢了数据访问速度。如果让分区什么也不做，只是充当协调者(coordinator)，就不会降低数据分区数据访问速度。
　　在 InfoSphere Balanced Warehouse E7100 的设计中，我们在 administration BCU 中，分别为编目分区和协调分区分配了专用的分区，同时，根据数据库分区的基本原则，我们将系统中的小表创建在了一个单一分区上。用户的数据，我们创建在 data BCU 上，同时，根据数据库分区的基本原则，我们将系统中的大表尽量地分布到 data BCU 上的所有分区上。当用户数据增加后，我们可以通过增加更多的 data BCU 来实现增量的方式扩展、提供均衡的性能。如下说明：
　　Database partition 0 (BPU 0) 包含：
　　Catalog function (only one database partition has the database catalog)
　　Coordinator function
　　Single-partition data function
　　Query Patroller server and control tables (if implemented)
　　Located on the administration BCU
　　Database partition 1 - n (BPU1 - BPUn) 包含：
　　Database partitions with partitioned data
　　Located on the data BCUs
　　DB2 节点配置文件(db2nodes.cfg)
　　用来定义数据库分区。在创建分区数据库之前，一定要先定义 db2nodes.cfg 文件。该文件放置在用户实例主目录下。系统中的每一个分区在该文件中都会有一项。
　　db2nodes.cfg 文件的基本格式如下：
　　dbpartitionnum hostname logical-port netnam
　　其中：
　　dbpartitionnum
　　数据库分区号唯一地定义数据库分区，可在 0 到 999 之间。数据库分区号必须以升序顺序排序。该顺序中可以有间隔。一旦指定了数据库分区号，就不能对其进行更改。否则，分布图(它指定数据分发方式)中的信息可能不正确。
　　hostname
　　用作分区间通信的 IP 地址的主机名。
　　logical-port
　　它指定该数据库分区的逻辑端口号。此号码与数据库管理器实例名一起用来标识 etc/services 文件中的 TCP/IP 服务名称条目。 对于每个主机名，一个逻辑端口必须为 0(零) 。
　　netname
　　指定用于 FCM 高速互联的主机名称 。
　　下边是包括一个 administration BCU 和 2 个 data BCU 环境的 db2nodes.cfg 文件内容：
　　0 adminbcu001 0 adminbcu001_fcm
　　1 databcu001 0 databcu001_fcm
　　2 databcu001 1 databcu001_fcm
　　3 databcu001 2 databcu001_fcm
　　4 databcu001 3 databcu001_fcm
　　5 databcu001 4 databcu001_fcm
　　6 databcu001 5 databcu001_fcm
　　7 databcu001 6 databcu001_fcm
　　8 databcu001 7 databcu001_fcm
　　9 databcu002 0 databcu002_fcm
　　10 databcu002 1 databcu002_fcm
　　11 databcu002 2 databcu002_fcm
　　12 databcu002 3 databcu002_fcm
　　13 databcu002 4 databcu002_fcm
　　14 databcu002 5 databcu002_fcm
　　15 databcu002 6 databcu002_fcm
　　16 databcu002 7 databcu002_fcm
　　在分区号的分配上，我们建议，catalog partition 分区号分配为 0，因为一个实例下只能有 1 个 catalog partition，分区号 990-999 分配给另外需要增加的 coordinator partitions，分区号 980-989 分配给另外需要增加的单分区的表。