内容提要
现在的数据库应用程序通常需要伸缩性、快速转入及转出数据——在尽量不影响应用程序访问数据的情况下。转入转出数据涉及添加新数据和移除(通常归档)历史数据。今天的很多应用程序是 24X7 访问的,因此消除了以前提供的批处理窗口的数据更新。同样,很多应用程序需要在并行访问数据的情况下才能连续进行数据更新。
DB2数据库系统提供了多种工具来实现伸缩性和在最低限度影响数据访问的情况下,方便连续填充或转入转出数据。本文建议的最佳实践可用来设计并实施这些 DB2 工具,以达到这些目的。
介绍
本文描述了最佳 DB2 设计实践,简化 DB2 数据生命周期管理。生命周期管理是有效增加(即转入)新数据,并将主数据库中不再需要的数据进行归档(即转出)。 DB2 系统提供了下列功能,这些功能你可以组合使用,可以简化生命周期管理:
数据库分区
表分区
多维集群
UNION ALL 视图
除了这些 DB2 功能,IBM Optim Data Growth 解决方案还简化了数据归档生命周期的管理。
DB2数据库系统分区工具的一个最重要的好处是,可以部署和更改这些工具而不影响现有应用程序的代码。
本文是最佳实践文章家族的一员,你也能通过阅读其它最佳实践从中受益。
本文的目标读者是负责为 DB2 应用程序设计数据库的人员(如果要达到伸缩性和有效的数据生命周期管理,数据库人员同样会发现本文的价值)。本文认为你需要有一定的 DB2 数据库设计的经验。
这篇文章的内容是基于 DB2 版本 9.5 提供的工具。 DB2 数据库系统的后续版本可能会有所提高,这将对本文的最佳实践建议带来变化。
分区技术
什么是数据库分区?
数据库分区(之前称为 DPF)是通过使用哈希键值算法把数据分布在数据库中的各个逻辑节点上。数据库分区的目标是通过在计算机集群之间均匀的分布数据来最大化可扩展性。数据库分区通过减少 DB2 实用工具操作粒度来增强扩展性。它并行的在数据库上进行查询和更新操作。
下面的例子演示了如何指定数据库分区:
CREATE TABLE Test
(Account_Number INTEGER,
Trade_date DATE )
DISTRIBUTE BY(Account Number)USING HASHING
注意:在 DB2 版本 9 中,PARTITION KEY 子句被重命名为 DISTRIBUTE BY 。
数据库分区是完全透明的,因此并不影响现有应用程序代码。同样,你可以使用 redistribution 实用工具来在线更改,而不会影响应用程序代码。
在设计你的数据库分区策略时,使用一个有较高基数性的分区键列,来确保数据在各个逻辑节点间均匀分布。一个有较高基数的列有大量唯一值(而非大部分值相同)。同样,唯一索引必须是分区键的超集。
对那些要进行连接的表,尝试使用相同的分区键。这增加了连接并置。
什么是表分区?
表分区(通常叫做范围分区)是在一个逻辑数据库分区中的一个或多个物理对象上,通过制定键值范围来分割数据。表分区的目的是组织数据以便于优化数据访问和数据转出。对于特定的应用程序,表分区也有助于转入数据,然而,多维集群(在下面“ Multi-Dimensional Clustering ”章节讨论)往往是增强转入的更好选择。数据库分区是减少实用工具操作粒度以及超大型数据库的可扩展性的最佳实践。
表分区的好处是:
通过消除不恰当分区来提高查询性能。优化器可以把 SQL 查询,限制到仅在和 WHERE 子句相关的分区里。
优化表分区的转入和转出处理。表分区可以很容易的添加或删除表的分区,而不发生数据移动。应用程序可以在添加分区时,对原来的数据执行读写操作 ( 查询被安排在一段很短的时间内 ) 。
以前提供的维护方法压缩率会随着时间推移发生变化。由于每个表分区都有它自己的压缩字典。因此,以前分区上的压缩数据并不会随新数据的插入而发生改变。
优化对超大型表的管理。表分区可以拥有几乎无限的大小,因为限制只存在于各个分区中(而不是整个表)。你可以把范围数据存放到多个表空间中,以便于备份和恢复数据。
使 SMS 表空间的索引有更大的灵活性。你可以将索引存储到不同的 SMS 大型表空间中(仅支持分区表)。所有表都可以把索单独存放到 DMS 表空间中。
下面例子演示了指定表分区:
CREATE TABLE Test
(Account_Number INTEGER,
Trade_date DATE)
IN ts1, ts2, ts3PARTITIONED BY RANGE(Trade_date)
(STARTING'1/1/2000'
ENDING'3/31/2000',STARTING'4/1/2000'
ENDING'6/30/2000',STARTING'7/1/2000'
ENDING'9/30/2000)
在你的 DB2 文档中有很多其他技术可以用来指定表如何进行分区。
多维集群
多维集群(MDC)是一个 DB2 数据库系统具有的独特能力。 MDC 在表中通过多维键值(单元)来组织数据。 MDC 的目的就是通过多个维度方便的存取数据,以保持数据访问只选择那些相关的单元。 MDC 通过维度确保数据随时处于集群状态,从而避免了重组数据的需求(数据永远不会变得无序)。
MDC也利用在每个维度上的块索引(并结合维度)对比行 ID(RID)索引。这样做的结果就是极大的减少了索引大小和索引级别。例如,如果在一个 DB2 单元中能装入 100 行,块索引将只指向单元而不是这 100 行数据的每一条。这样减少了读取和更新数据的 I/O( 索引值在块满了的时候进行更新 ) 。
MDC使转入和转出数据变得很方便,而且是对应用程序完全透明的。
下面的例子演示了如何指定多维集群:
CREATE TABLE order
(Account_Number INTEGER,
Trade_Date DATE,
Region CHAR(10,
order_month INTEGER generated always as month(order_dt))
IN ts1
ORGANIZED BY DIMENSIONS (region, order_month)
在设计你的 MDC 策略时,指定有较低基数的列,以避免稀疏填充单元。稀疏填充的单元会显著的增加磁盘空间的使用量。一个有较低基数的列,会有很多相同的值(而不是很多唯一值)。你也可以使用一个生成列来产生一个高度集群的维度。例如,一个生成列或内部函数可以把日期转换成月份。这样就显著的减少了基数(对于一年的数据,基数从 365 减少到了 12)。
MDC 功能有助于转入和转出数据
MDC 保证了在所有维度上的集群维护避免了重组数据的需求。这在转入过程中极大的减少了 I/O(而使用连续的大块 I/O)。同样,由于 MDC 维度上的索引是块索引,这也使得 MDC 在转入过程中避免了过多的索引 I/O 。块索引比普通基于 RID 的索引要更小也更浅,这是因为索引条目指向的是一个数据块而非一行。
同样,在转入过程中,MDC 减少了索引维护,因为块索引只在块满了的时候更新一次(不是像其他索引那样每插入一行就更新一次)。这也有助于减少 I/O 。
INSERT语句在你使用 MDC 时运行的更快,因为 MDC 从用现有空的数据块不需要进行分页。插入锁定同样得到了减少,因为锁发生在块级别而不是行级别。
MDC提高了转出数据的效率,因为删除的是整个页面而不是每一条记录。在 MDC 删除过程中日志同样会减少(每个页面只会有几个字节)。
使用只有一列的 MDC 设计,以便于转入和转出数据,而不会增加磁盘使用量。
见“连续更新情况下转入和转出数据的最佳实践”章节中,一个假设从使用 MDC 转入数据中获益的应用程序。
在一个数据库设计中同时使用数据库分区、表分区和多维集群
开发大型应用程序方法的最佳实践是在一个数据库设计中同时实现数据库分区、表分区和 MDC 。数据库分区提供了可扩展性并且确保了在逻辑分区上均匀分布数据;表分区方便了查询分区删除和转出数据; MDC 提高了查询性能并使数据转入更加方便。
例如:
CREATE TABLE Test
(A INT, B INT, C INT, D INT … )
IN Tablespace A, Tablespace B, Tablespace C …
INDEX IN Tablespace B
DISTRIBUTE BY HASH (A)
PARTITION BY RANGE (B) (STARTING FROM (100) ENDING (300) EVERY (100))
ORGANIZE BY DIMENSIONS (C,D)
表分区不能完全解决在 DB2 版本 9.5 中的扩展问题。需要继续使用数据库分区来解决大型数据仓库的扩展问题。 DB2 数据库分区不共享架构是对你的应用程序提供线性扩展而没有软件瓶颈的最好方法。
支持生命周期管理的其他技术
大型表空间
使用大型表空间(在 DB2 版本 9 中默认使用)能更好的调节大型的表或索引。在 DB2 服务器上这也使每页能存更多的行。
对深度压缩的表(一页中有很多行)和表分区全局索引(预计会超过 4K 页 64G 容量)使用大型表空间。如果你不受这些问题的影响,就不要使用大型表空间。同样你可以通过把每个表分区的全局索引拆分到不同的表空间(强烈建议)来避免大型表空间的需求。
下面的图比较了可用空间在不同页面大小的情况下能存储的记录数目,包括普通表空间和大型表空间。
Page Size | REG TBSP Max Size RID – 4 Bytes | REG TBSP Max Records/Min Record Length | LARGE TBSP Max Size RID – 6 Bytes | LARGE TBSP Max Records/Min Record Length |
4 KB | 64 GB | 251 / 14 | 2 TB | 287 / 12 |
8 KB | 128 GB | 253 / 30 | 4 TB | 580 / 12 |
16 KB | 256 GB | 254 / 62 | 8 TB
您可能想查找下面的文章: |