分区的威力

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不再是将被装载的那个表所在的表空间所有表锁定在