本文内容包括:
内容提要
介绍
分区技术
多维集群
支持生命周期管理的其他技术
设计并实现你的表分区策略
转入数据:用什么方法?
转入压缩表分区的最佳实践
连续更新情况下转入和转出数据的最佳实践
在转出以后:如何管理数据增长和数据保持?
结论
参考资料
关于作者
对本文的评价
级别: 初级
developerWorks 中国网站编辑团队, 编辑, IBM
2009 年 10 月 21 日
本文描述了最佳 DB2 设计实践,简化 DB2 数据生命周期管理。生命周期管理是有效增加(即转入)新数据,并将主数据库中不再需要的数据进行归档(即转出),DB2 系统提供的功能可以简化生命周期管理。
现在的数据库应用程序通常需要伸缩性、快速转入及转出数据——在尽量不影响应用程序访问数据的情况下。转入转出数据涉及添加新数据和移除(通常归档)历史数据。今天的很多应用程序是 24X7 访问的,因此消除了以前提供的批处理窗口的数据更新。同样,很多应用程序需要在并行访问数据的情况下才能连续进行数据更新。
DB2数据库系统提供了多种工具来实现伸缩性和在最低限度影响数据访问的情况下,方便连续填充或转入转出数据。本文建议的最佳实践可用来设计并实施这些 DB2 工具,以达到这些目的。
|
本文描述了最佳 DB2 设计实践,简化 DB2 数据生命周期管理。生命周期管理是有效增加(即转入)新数据,并将主数据库中不再需要的数据进行归档(即转出)。 DB2 系统提供了下列功能,这些功能你可以组合使用,可以简化生命周期管理:
除了这些 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 ”章节讨论)往往是增强转入的更好选择。数据库分区是减少实用工具操作粒度以及超大型数据库的可扩展性的最佳实践。
表分区的好处是:
下面例子演示了指定表分区:
CREATE TABLE Test (Account_Number INTEGER, Trade_date DATE) IN ts1, ts2, ts3 PARTITIONED 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保证了在所有维度上的集群维护避免了重组数据的需求。这在转入过程中极大的减少了 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 | 1165 / 12 |
32 KB | 512 GB | 253 / 127 | 16 TB | 2335 / 12 |
注意:如果你把一个表空间改成大型表空间,在与所有表相关的索引重组完成之前,它不会立即生效。
当附加了一个新的分区到表中,或者当你分离了一个表分区和物化查询表(MQT)时,就需要运行 SET INTEGRITY(注意,这些数据在新的分区中 SET INTEGRITY 处理完成之前是不可见的)。 SET INTEGRITY 可能是一个要运行很长时间的操作,它验证数据并维护全局索引。这个维护操作需要记录日志并可能产生大量的日志输入。
SET INTEGRITY 的关键好处是,操作期间现有数据可以被读写访问。你可以把对大数据量运行 SET INTEGRITY 的影响通过使用 MDC 来减到最小,而且也可以最小化对全局索引和 MQTs 的使用。另外一个选择是你可以指定用户维护 MQT 来加速 SET INTEGRITY
“设计并实现你的表分区策略”这一章节有使用 SET INTEGRITY 的建议。
异步索引清除(AIC)是 DB2 的一个新功能,它在表分区分离后释放索引空间(清除程序作为较低优先级的后台进程运行)。由于有 AIC 功能,分离表分区几乎是一瞬间的。分离操作不需要等待索引清除完成。 AIC 是一个后台进程,它是 DB2 数据库系统自动调用的。
|
从表分区获益的应用程序使用了下列类型的表:
表分区设计,你需要考虑的内容包括:
表分区提供了一个强大的功能,以限制到分区的数据访问必须满足 SQL WHERE 子句。为了从分区删除中获益,需做好以下工作:
使用下列最佳实践来增强表分区的操作性特征:
|
有很多因素会影响你在安装中如何选择最佳转入的解决方案:
下面是两个把数据以分区形式转入的不同技术:
1.ALTER/ATTACH
你使用 ALTER/ATTACH 方法首先离线填充表,然后附加这个分区。你必须运行 SET INTEGRITY(对于大数据量来说,这个操作可能会运行很长时间)。
优点:
缺点:
2.ALTER/Add
使用 ALTER/Add 方法,你可以附加一个空的表分区,然后使用 LOAD 实用工具或 INSERT 语句来填充它。
你不需要运行 SET INTEGRITY
优点:
缺点:
建议:
对于更大的数据量,利用 ALTER/Add 方法来转入一个表分区或利用 MDC 来转入。
|
这些最佳实践使用 ALTER/Attach 附加一个表分区,这在前面的章节中已经介绍过了。
在版本 9.1 上,快速附加一个有压缩数据的表分区的技术是:
对版本 9.5,自动创建压缩字典简化了这个快速附加一个表分区的技术。
注意,在一个完全装载的分区上进行离线重组,可以得到比只有这个月归档的分区更好的压缩。
|
这个数据库设计包含了多个 DB2 数据库系统功能,以方便在连续更新的请求下的数据转入和转出。
这些应用程序的设计有以下特点:
关于数据库设计的建议:
为了方便转入数据,指定只有一个在 day 上的维度的 MDC(见“ MDC 功能有助于转入和转出数据”部分)
为了方便转出数据,对每周或每个月指定一个表分区范围。对 MDC 提供相同的时间维度不过是更粗的粒度。
有很长运行报告的程序对 DB2 LOAD 实用工具通常不能排除查询。在这种情况下的最佳实践是使用 LOAD 实用工具来快速装载数据到中间过渡表,然后使用一个有子查询的插入来填充主表。
|
为了符合公司政策、管理章程、或审计需求,你可能需要保留你的数据并保持它们在很长时间内可用。例如,Health Insurance Portability and Accountability Act (HIPAA) 法案,要求健康护理组织保留至少 5 年的原始医疗记录。另外,一些企业也发现了对历史数据进行分析的价值,并因此保留更长时期的数据。
因此,为了实施一个恰当的转入转入策略和适当的数据库设计,你需要考虑数据的寿命,包括数据保留和获取政策。出于保留数据的目的,你可以什么都不做并不停的增加硬件能力和资源,来保持这些附加的数据增长,然而本文介绍的是数据保留的最佳实践。
一个实践就是在数据库中保留所有数据,把某些范围转出作为数据保留,并对这些范围创建 UNION ALL 视图以便于访问。
下面的例子演示了如何创建一个 UNION ALL 视图:
CREATE VIEW all_sales AS ( SELECT * FROM sales_0105 WHERE sales_date BETWEEN '01-01-2005' AND '01-31-2005' UNION ALL SELECT * FROM sales_0205 WHERE sales_date BETWEEN '02-01-2005' AND '02-28-2005' UNION ALL ... UNION ALL SELECT * FROM sales_1207 WHERE sales_date BETWEEN '12-01-2007' AND '12-31-2007' ); |
在数据库使用主存储把所有数据保持在线时,使用 UNION ALL 视图定位数据保留和实时访问。这个方法带来的一个问题是你可能不需要再维护和备份镜像相关的数据。同样,历史数据一般不需要高性能,所以不需要进行索引或使用在你主数据上的高成本的因素。
有很多使用 UNION ALL 视图的方法:
对使用 UNION ALL 视图有一些限制。当你有很多范围时,最好使用范围分区表。这是因为某些复杂谓词不能用在 UNION ALL 视图上。
然而,在某些情况下 UNION ALL 视图又很有优势。例如,一个 UNION ALL 视图可以在联邦数据库中使用,相反,范围分区表不能。
根据你的历史数据的服务级别协议(SLA),通常同时讨论数据增长和保存的最佳实践是用 IBM Optim Data Growth 实施数据归档。
IBM Optim Data Growth是在处理增长、遵守和管理上领先的解决方案。它通过归档已完成的业务对象,来保持应用程序的完整性,而非单个表。例如它在归档中保持外键并保留原数据。这些功能使你能够:
完成下列步骤指南来判断如何最好的实施你的归档策略:
第1步:对你的应用程序进行分类
首先,你需要根据它们的归档需求来对你的应用程序进行分类。通过了解需要从你的应用程序数据中保留什么事务,你可以根据相似数据需求来对应用程序进行分组,来提高可访问性和性能。一些应用程序只需要保留当前事务;一些只需要访问历史事务;其他的需要混合访问现在的和历史的事务(以不同的比例)。
你也需要客观的对归档数据考虑服务层协议(SLA)。 SLA 是一个各个组织间著名的协议,它定义了它们之间的期望,包括客观的条目,比如服务、优先级和职责。 SLA 的目的通常被定义为使用响应时间的目标。例如,可能需要在五分钟内运行一个特定的人力资源报告。
第2步:评估你的数据温度
数据温度来自于:
在不同的企业,数据温度也有所不同,不过通常来说,数据温度是根据产业间的区别进行的一般分类。下表提供了数据温度的指南:
数据温度 | 描述 |
Hot | 策略数据 – 对当前数据查询的体积、频繁访问的和需要提升快速反应时间。 |
Warm | 传统决策支持数据 – 查询对这类数据的访问不那么频繁而且数据获取也不需要紧急提升响应时间。 |
Cold | 深度历史数据 – 查询很少访问这类数据不过它们必须可以周期性的访问。 |
Dormant | 监控数据它们需要能够在某些例外情况下访问。 |
有很多方法可以访问数据温度,例如,使用你的转出策略和系统跟踪。你需要访问的温度信息:
例如 THIS_WEEK, LAST_WEEK, THIS_QUARTER, LAST_QUARTER 。
你可以使用 DB2 版本 9.5 负载管理器(WLM)来帮助发现数据的温度。 WLM 历史分析工具提供了关于那些表、索引和列被访问了,那些没有以及有多频繁的信息。
WLM历史分析工具有两个脚本组成:
要发现对象中的那些数据被访问过,你需要分析 SQL 语句。要这么做,使用一个 ACTIVITIES 事件监视器来搜集运行的活动数据(包括 SQL 语句文本)。你可能想搜集关于工作负载管理对象比如工作负载、服务类型和工作类型(通过工作活动)。要启用活动搜集,在这些市哦那个 COLLECT ACTIVITY DATA WITH DETAILS 子句的对象上执行 CREATE 或 ALTER 语句,如下所示
ALTER SERVICE CLASS sysdefaultsubclass UNDER sysdefaultuserclass COLLECT ACTIVITY DATAON ALLWITH DETAILS |
WITH DETAILS选项启用对静态语句和动态 SQL 语句的语句文本搜集。
如果应用程序在语句文本中使用了参数标记,也应该包括 AND VALUES 选项,(指定 COLLECT ACTIVITY DATA WITH DETAILS 和 AND VALUES)。 AND VALUES 选项搜集和参数变量相关的数据值以获得详细语句信息。
第3步:发现并对你的业务对象进行分类
业务对象,比如一个保单、一个发票、或购物清单、代表了一个事务交易。通过指定你的业务对象,你可以开始定义规则和相关业务驱动以在数据生命周期的不同阶段管理这些对象。
从数据库透视图来看,一个业务对象表示了一组相关表中相关的行
业务对象的简单例子
出于保持和归档的目的,你希望表现整个业务对象,比如你有一个事务交易的历史“时间点”快照。创建一个历史快照需要交易细节和相关主要数据,这包含数据库中的多个表。可以完整精确的对整个业务对象进行归档,并提供单独的交易历史存储库。为了响应质询或发现需求,你可以查询这个存储库而不需要访问 HOT 数据。
在这个例子中,为了确保所有对象可用,归档业务对象必须由来自 DEPARTMENT 和 EMPLOYEE 表中的相关数据组成。在归档后,你会只想删除生产 PROJECT 表中的数据以及和 EMPLOYEE、DEPARTEMENT 无关的数据。
就像在这个例子中展示的,你会发现基于模式间的关系的业务对象。 不过,你或许也想包含其它没有任何模式关系的相关表,却通过使用一个应用程序相关联。另外,你或许会选择删除从某个业务对象上某个发现的关系
第4步:生成你的综合数据分类:
在你对你的应用程序和业务对象完以成分类并对他们相关数据温度做出判断后,你可以生成一个数据分类表来总结这些信息。这张表可以明白的说明数据的年龄。
下表提供了一个分类样本:
第5步:判断后归档存储类型
为了判断什么存储类型岁适合你的老数据:
例如,对于在线归档你可以使用 ATA 磁盘或更大容量的较慢驱动。对离线归档,你可以使用磁带或 WORM(IBM DR550,EMC Centera)。
第6步:访问归档数据
Optim Data Growth访问层使用 SQL92 容量和多种协议(如上图所示)以支持对归档数据的访问。这个访问能力和生产系统完全不同,而且不会使用任何生产系统资源
另外,你可以使用一个联邦系统(使用 IBM DB2 联邦服务器)从生产系统上来对归档数据提供透明访问。
这两种方法都允许对归档数据的直接访问,不需要取得或回复归档数据。
下面例子演示了如何使用 UNION ALL 视图来同时访问活动和归档数据。在例子中把数据库中叫做project表重命名为另外一个名字,然后创建一个也叫做project的 UNION ALL 视图。
RENAME TABLE project TO project_active CREATE VIEW project AS SELECT * FROM project_active WHERE prjendate >= (CURRENT_DATE – 5 YEARS) UNION ALL SELECT * FROM project_arch WHERE prjendate < (CURRENT_DATE – 5 YEARS) |
另外,下面例子避免了在数据库中重名表的需求。例子中创建了一个叫project_all的 UNION ALL 视图作为替代,应用程序可以从这里查询到完整的project数据集:
CREATE VIEW project_all AS SELECT * FROM project WHERE prjendate >= (CURRENT_DATE – 5 YEARS) UNION ALL SELECT * FROM project_arch WHERE prjendate < (CURRENT_DATE – 5 YEARS) |
|
通过仔细选择在你的 DB2 数据库中最适合分区方法,以及在你的系统上使用最有效的转入和转出技术,你可以最大化整体系统性能和效率。
投入足够的时间来分析和理解你的数据,这样你可以最好的利用本文中的指南,并获得 DB2 数据库提供功能的好处来使你的系统尽可能有效率。
你可以使用数据库分区来提供扩展性并确保数据在分区间均匀分布。下面指南在“设计并实现你的表分区策略”这一章中设计最有效的表分区策略。使用 MDC 来提高查询性能并使转入数据更容易。
如果你需要从压缩的额表分区中转入大量数据,升级到 DB2 版本 9.5 数据库系统并使用 ALTER/Add 方法来附加一个表分区。
如果你需要提供连续更新,你的最佳策略是使用 MDC 以方便转入处理。
紧接着在“在转出以后:如何管理数据增长和数据保持?”指南中确定了如何处理你的历史数据需求。
在你准备好转出你的数据并归档之前,你需要对数据保留和从归档中取回数据确定一个和你的组织匹配的数据策略。
你可以确定你组织对保留数据的需求,并通过下列因素取回:
你的策略应该包含什么类型的后归档存储是最合适的,以及如何最好的访问归档数据。
学习
获得产品和技术
http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0910datacycle/index.html
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞0
添加新评论0 条评论