** 分区的威力 ** ** **
Dwaine R. Snow and Paul C. Zikopoulos 著
笑熬浆糊 译
** 原文出处：《 DB2 Magazine ** ** 》 Quarter 2, 2003 · Vol. 8, Issue 2 **
** 英文原文（由于文章翻译未经授权，请在转载时保留原文链接） **
人们对分区有很多的误解。多伦多实验室的专家们对这个有用的功能进行了正名。
DB2 数据库分区的往往是存在很多误区。对于 Linux 、 Unix 以及 Windows 平台上的 DB2 UDB 8.1 版本所做的变动有助于简化 DB2 分区。我们将解释这些变动，澄清一些分区的神话，以及说明您应该考虑分区的时机和理由。
DB2 UDB 8.1 For Linux \Unix\Windows 将 DB2 产品家族中以前称之为 DB2 UDB 企业版和企业扩展版的产品整合成为一个单独的产品中。这个 新的 DB2 企业服务器版 (ESE) 包含了数据库分区的功能 ( 从前是作为单独提供的产品 ) ，作为一个计费的项目，现在被称为数据库分区功能 ( 注：直译—— database partitioning feature DPF) 。当 DB2 的用户们发现自己需要开始分区时，那么他们可以马上开始而不需要其他一些额外的代码—— 他们仅仅需要 DPF 的许可协议。
DPF的真相
关于数据库分区的神话在 DB2 中随处可见（参见表 1 ）。对于分区基础的快速概揽将帮助你区别真伪并且做出适当的分区决策。
表 1 : 围绕 DB2 数据分区的神话和事实
无论是否有 DPF ， DB2 都支持并行查询处理。图 1 展示了安装在一个 4 路 SMP （对称多处理）服务器 DB2 ESE 。在这个假设中。一个独立的查询可以自动使用这个服务器上所有的 CPU 和物理磁盘。对于依靠需要数据的子集进行处理的子代理提供分区内部的并行机制。 DB2 使用 I/O 的预存取把从磁盘发送的数据反馈到这些子代理当中。这种并行机制对用户、应用程序以及 DBA 都是透明可见的。
** 图 1 ** ** ： ** 不带有 DPF 的 DB2 ESE 的并行机制
DPF 选项增加了在一组机器中或逻辑上位于某个 SMP 服务器中的数据库进行分区的能力。依靠 DPF ，一幅数据库图像可以跨越多台机器（存储），并且它对于用户和应用程序来说仍然还是一幅完整数据库图像。
考虑四路的 SMP 服务器组的情况。 ( 在这篇文章里，我们将使用术语数据库分区 组 而不是 集群 ，因为集群通常是指高可靠性的故障转移配置或者用于衡量系统的分区组。 ) 使用 DPF ，在图 1 中所讨论到的并行操作可以扩展到横跨多台 SMP 机器 ( 参见图 2) 。这样的好处就是有一个双并行操作。 你可以跨越多台机器或者逻辑数据库分区来平衡这些并行操作。这样的处理被称之为分区之间的并行机制。
** 图 2 ** : 横跨多台机器的使用 DPF 的并行机制
分区之间的并行机制通常在多台服务器执行，但越来越多的用户现在都一些大型的 SMP 箱中进行该操作 ( 参见图 3) 。
** 图 3 ** : 单独的 SMP 服务器中的拥有 DPF 的 DB2 ESE.
什么时候（为什么）需要进行分区
那么，你应该去做分区吗？在以下的情况下你应该考虑分区：
· 你的服务器拥有大量可用内存。即使 DB2 v8 有 64 位支持，多分区已经被证明可以提供比单独的 SMP 并行机制更多的内存的有效使用和更多的线性可扩展性。
· 系统将包括多台服务器，或有超过 6 到 12 个的 CPU 。
· 数据库工具的操作速度是你的业务操作的关键所在。
· 为装载数据或提取，转换，负荷处理操作提供的批处理窗口数量是有限的。
· 数据仓库的滚动窗口数据更新的需求使并行 SQL 处理和其他日志空间成为根本。
分区在这些情况下显得特别有意义。 但是分区所提供的一些其它的好处使得它变得更有魅力。这些好处有：
** 查询的可扩展性 ** 使用 DPF 的一个最明显的理由就是它可以增加查询工作量和 insert , update ，和 delete 操作的性能。把一个单独的大型数据库分区为很多定数量的较小的数据库以加速这些操作因为每一个数据库分区都拥有它们自己的一套数据。
比如说你想要扫描一个包含 100 million 行数据的表。对于一个单独的数据库分区而言，这次扫瞄会要求独立的数据库管理器去搜索所有 100 million 个纪录。如果你把你的数据库系统分区为使用 50 台数据库分区服务器并且将这 100 million 条记录均匀的分配到他们之间的话，那么每一个数据库分区上的数据库管理器仅仅需要扫描 2 million 行。如果每一个扫描都在同一个时间并且以相同的速度执行的话，那么扫瞄完成的时间大约是前者的 2% 。
DPF 提供类似于线性可扩展性和使用工具来完成基础设施构建。这样它可以根据需要增加容量而不需要新技术或者单独安装
DB2 优化器是基于并行机制。换句话说，它保留了如何在系统中对于底层数据进行分区的信息。使用这些信息，优化器考虑不同的查询执行策略和一个低成本的选择。当在比较不同的执行策略时，它会考虑到不同的操作的内在的并行机制和在数据库分区之间传递消息的开销。
在大量数据或者处理器和分区的数量增加的时候， DB2 可提供类似线性的可扩展性。但是，分区可能提供的最大好处的机会取决于它所相关的工作量、最大容量表的大小以及其它一些因素。一般情况下，我们推荐：每个 CPU 上面的原始数据（仅是表的大小）的数量应该基于在被使用服务器上的 CPU 的功率。比如说 pSeries p690-class CPU ，我们会建议每个处理器 150-200GB 。而对于使用 Linux 或者 Windows 的 xSeries-class CPU （或任何 Intel 或 AMD 的机器），我们会推荐每处理器 75-150GB 。记住，这些只是一般情况下的推荐，在实际情况下会有一些不同的。
** 体系架构的限制 ** DPF 已经突破了一些 DB2 的体系架构的限制。例如，在 DB2 中表的最大容量是 64GB 以 4KB 的页面大小（虽然 32KB 的页面大小可以支持到 512GB ）。 DB2 中表和表空间大小限制是建立在每个分区的基础上。因此，在多个分区中对一个数据库进行分区可以让你通过你所在系统环境的分区数量的系数来增加表的最大容量。例如，把一个数据库分区成横跨四个结点系统就可以支持最大（以 32KB 页面大小） 的 2408 GB 的表。
在一个没有分区的环境中内存也会成为一个瓶颈。 32 位版本的 DB2 ESE 限制了每台 DB2 服务器共享内存。（这个限制将随运行 DB2 的操作系统的不同而不同，同时一些供应商也提供一些基本内存模的扩展。）共享内存支持内存密集型的数据库资源譬如缓冲池、高速缓冲区和堆。在一个 DPF 的环境里，每一个数据库分区管理和拥有它自己的资源，因此您可以通过分区你的数据库来克服这些限制。你甚至可以在大型的 SMP 箱中区运行逻辑数据库分区，充分利用在一台单独 SMP 服务器中的大内存资源。
** 数据装载 ** 在 DB2 ESE v8.1 中，如果对目标表分区，那么装载工具会自动并行的分离和装载数据。它使用智能的缺省值去分离和装载数据；它也可以被优化用于一些环境。
在一个分区数据库中，您可以使用装载工具同时向相应的数据库分区装载数据。图 4 显示装载工具是使用专用的媒体阅读器将数据分离和装载到表中（并行状态下）。装载工具对于装载时间提供了类似于线性的可扩展性。
图 4 利用 DPF 加速表的装载
DB2 v8 的装载工具比以前版本的装载工具更快、更加可利用。如果你在 DB2 v8 中执行一个装载的操作， DB2 不再是将被装载的那个表所在的表空间所有表锁定在它之中（与 DB2 v7 的情况一样）。现在甚至还有一种被称之为在线装载，它在装载的时候允许对表进行读操作。考虑对于以前 DB2 版本的，仍然支持 autoloader 脚本。
是否有可能装载时间重要但查询的性能并不重要的？这两个问题其实并不互相排斥；可是，在许多商业流程中装载时间是一个重要因素。实际上，这有时还是决定因素。如果是在那种情况下，那么使用 DPF 是相当有用的。 例如，电信公司（ telco ）的欺诈侦查单元在一个指定的时间间隔中装载大量的数据以求快速准确的监测出呼叫模式下反常现象有可能是潜在欺诈信号。数据库必须迅速发现这些反常现象，因此数据需要迅速和频繁地进入数据仓库。在电信公司，这个过程每小时被重复甚至在更大的公司每十五分钟就要重复。 这些需求要求一个可扩展并且高效率的基础设施来运行类似查询的工作。
** 维护 ** 数据库分区可以明显的加速维护。将数据库分散于多台数据库分区服务器上可以加速数据库的维护，因为每一项操作都是运行在分区管理的数据子集上的。
虽然在 DB2 中索引创建是并行的，你可以通过对数据库进行分区来进一步减少总的时间。在所有分区上利用小数据集并行创建索引是允许并行的。 记住， DB2 抽象了表面现象下的运行；多个表可以表现成一个表的形式。
RUNSTATS 工具也可以从分成中受益。这个工具更新关于表的物理特性和它相关的索引统计数据。在决定数据访问路径时优化器使用这些统计数据。 RUNSTATS 是 CPU 密集的，需要数据的排序和聚合。你可以使用 DPF 的选项来减少该工具所占用的时间。使用 DPF ， RUNSTATS 检查在一个数据库分区上的数据而不是整个表。在 DB2 v8 中， RUNSTATS 取样选项可以进一步减少工具的的执行时间（不管有或没有 DPF ）。
同样，将数据散布于多个分区有助于表重组（ REORG ） ，它是 I/O 密集的并且需要随机抓取（特别是在离线状态下）。每个数据库分区可以重组它拥有的数据同时分配为每一个处理器更多驱动来重组数据。这些操作也可以并行操作以缩短需要的整体时间。在 DB2 v8 ，你可以在各个分区或者在数据库分区的子集上来执行 REORG 。 你也可以停止、暂停、检查状态和恢复。
这些例子仅仅是一些能从 DPF 得到好处的维护操作。
** 并行插入 / ** ** 删除 ** 在数据库分区中只有 SQL 语句是并行操作。如果数据库环境使用 SQL 来进行大容量的插入和删除处理，通过在数据库分区上的并行处理插入和删除语句，多数据库分区可以增加事务处理的吞吐量。这样的好处还可以应用于从一张表中选择数据并且插入另外一张表的技术。
** 滚动窗口需求 ** 当查询窗口必须保持在打开状态的时候，分区通常会被用于满足滚动窗口的需求（每天插入和删除行）。为每一个处理器定义一个数据库分区将增加新数据插入表中的吞吐量。在数据库分区中并发执行插入或删除数据流很有道理（例如使用一个关键范围）。多数据库分区使为存储大量插入和删除操作的数据库的 locklist 分配足够的内存成为可能。
数据库分区同时也允许横跨数据库分区并行进行索引维护操作（在插入和删除时）
** 备份与恢复 ** 多个数据库服务器之间的分区数据库可以才很大程度上减少备份数据库所使用的备份总时间。根据你的环境，在决定是否对数据库进行分区时这也许是一种重要决定因素。
DB2 通过为每一个表空间分配一个独立的进程或者线程来进行并行备份和恢复。 在一个分区的备份中，每一个分区被单独的进行备份。并行执行这些备份操作将会缩短备份整个数据库所耗费的时间。
一个分区数据库环境也可以加速前滚和重新开始（崩溃）恢复。用 DPF ，一些必须前滚的日志具体到了每一个数据库分区；数据库分区服务器间平衡的分离和征服战略（ divide-and-conquer strategy ）加速了这个过程。同时如果一个特定的数据库分区不需要前滚的话，那么它将在崩溃恢复中被忽略。
** 记录一些需要考虑的事情 ** 在一个高度活跃的系统中，数据库日志的性能很可能制约系统的能力。在一个分区的数据库环境，每个分区都有它自己的一组日志。当系统需要执行高强度的插入、更新或者删除活动时，多个数据库分区可能改善性能，因为日志被并行的写入每个分区中，并且在每个分区较少的记录日志。
做出选择
分区还是不分区 ? 从根本上来讲， DB2 就是 DB2 。不管你没有对你的数据库进行分区对于界面、功能、工具和你使用的技能都没有任何的影响。这事实上是依靠你的应用程序和环境。使用我们建议的标准，你可以发现问题的答案。
关于作者
** Dwaine R. Snow ** 是 DB2 UDB 分区数据库的产品经理，做为加拿大 IBM 的 DB2UDB 的资讯顾问工作多年，提供数据库和应用程序策划和设计、项目策划和实施、复杂在线事务处理和决策支持系统设计、性能调整以及系统集成的现场指导。你可以通过 [email protected] 与他联系
** Paul C. Zikopoulos ** 在 IBM 数据管理软件小组有七年的 DB2 工作经验并且写了许多文章。他参与写作了几本书，包括 _ DB2: The Complete Reference _ （ Osborne McGraw-Hill, 2002 ），和 _ DB2 Fundamentals Certification for Dummies _ （ Wiley, 2002 ）。 Paul 是 DB2 认证高级技术专家（ DRDA 和 Cluster/EEE 领域）和 DB2 认证解决方案专家（商业智能和数据库管理领域）。你可以通过 [email protected] 与他联系。