扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条
既然 DB2 9 发布了,现在是时候对它的最新特性之一 —— pureXML® 进行测试驱动了。为此,建立了一个模拟的经纪业务环境。这个环境具有以下特征:
请记住,XML 应用程序大致分成以下两类:
另外,涉及 XML 的数据库应用程序也是各种各样的,包括以下情况:
本文在一个基于 XML 的事务处理场景中进行性能度量,这个场景模拟一个面向数据的金融应用程序。测试设备包括最新的 POWER5 服务器(p5 560Q)以及 AIX 5.3 和 TotalStorage DS8100 磁盘系统。
DB2 9 中新的 XML 支持包括纯 XML 存储、XML 索引、XQuery、SQL/XML 和高级的 XML 模式处理。“纯” 意味着以标注上类型的树的形式存储和处理 XML 文档,这与商业关系数据库中以前的任何技术都不同。尤其是,pureXML 与将 XML 存储为大对象(BLOB 或 CLOB)或者将 XML 分解到关系表中的技术有显著差异。更多的信息请参考以前的文章 “What's new in DB2 Viper” (developerWorks,2006 年 2 月)和 “Native XML Support in DB2 Universal Database”。
这个测试场景对在线经纪业务进行建模。我们曾经帮助金融公司采用 XML。这些经历帮助我们理解了他们的数据和处理特征。这个场景有意地进行了简化,但是在文档、事务和 XML 模式方面仍然具有代表性。
这个场景中主要的逻辑数据实体如下(见图 1):
文档处理和大小因文档类型而异:
使用 Toxgene 数据生成器为这三个模式生成实例文档。关于 Toxgene 数据生成器的更多信息,请参考 ToXgene - the ToX XML Data Generator。
测试在以下设备上运行:
在安装 DB2 期间,会自动执行所有必需的操作系统参数调整。设置了以下的虚拟内存管理参数,从而更好地控制文件系统缓存使用的内存量:
vmo -o minperm%=5 vmo -o maxclient%=15 vmo -o maxperm%=15 |
另外,为了防止在数据装载期间试图缓存输入文件,在挂装命令中使用 -o cio
选项,用 JFS2 文件系统的并发 I/O 特性挂装包含原始 XML 输入文件的文件系统。
使用 TotalStorage DS8100 的标准默认配置。DS8100 在内部基本上是一个 POWER5 eServer p5 570。与之前的 ESS 使用 SSA 循环不同,DS8100 磁盘互连是一个 Switched Fiber Channel Arbitrated Loop(FC-AL),可以提供更快的数据访问和高可用性。DS8100 配置了 128 个磁盘,在这些磁盘上创建了 16 个卷。在其中,8 个卷(64 个磁盘)分配给这个 LPAR。4 个卷使用 6+Parity+Spare 设置为 388GB。另外 4 个卷使用 7+Parity 设置为 452GB。创建了一个跨越所有 8 个卷的卷组(VG)。在这个卷组上定义了 DB2 数据库的所有存储组件,包括表空间、日志和备份。表 1 总结了配置。
方面 | 配置 |
---|---|
处理器 | 两个处理器,每个附带 pSeries POWER5 1.9 GHz 两路 CEC |
内存(缓存) | 32GB |
磁盘互连 | Switched FC-AL |
磁盘数量 | 128 个(只有 64 个由主机 LPAR 使用) |
磁盘大小/速度 | 73 GB,15000 RPM |
DB2 9 包含许多新特性,包括新的自治自调整功能。在这个测试中,利用了其中几种自治功能,包括:
因为启动了 DB2 的自调整内存管理器(STMM),它会连续调整一系列 DB2 配置参数的设置。在测试运行期间 STMM 管理和调整的一些关键的 DB2 配置参数见表 2。要意识到的重要情况是,STMM 会根据正在运行的工作负载类型(比如纯插入、纯查询或混合型工作负载)自主地修改这些值。
DB 配置参数名 | 初始设置 |
---|---|
SELF_TUNING_MEM | ON(默认值) |
DATABASE_MEMORY | AUTOMATIC(默认值) |
SORTHEAP | 156 |
SHEAPTHRES_SHR | 10000 |
LOCKLIST | 53000 |
MAXLOCKS | 80 |
PCKCACHESZ | 27000 |
缓冲池名 | 初始设置 |
IBMDEFAULTBP | 1100000 |
CATBP | 4000 |
TEMPBP | 1000 |
DBA 只需要执行很少的数据库配置任务,见表 3。
方面 | 配置/设置 |
---|---|
数据库 | Unicode。所有表空间采用自动存储。DB2 日志在单独的条带上 |
内存 | 为所有测试启用 STMM |
页面大小 | 16K(表空间和缓冲池) |
表和索引 | 3 个表:CustAcc、order、security。24 个 XML 索引:10 个在 CustAcc 上,5 个在 order 上,9 个在 security 上 |
表空间 | 一共 6 个表空间:3 个表各有一个表空间,每个表的索引各有一个表空间。对所有表空间禁用文件系统缓存 |
缓冲池 | 一共 3 个缓冲池:默认缓冲池、用于编目表空间的缓冲池和用于临时表空间的缓冲池 |
设计、执行并度量了三种 XML 工作负载:
这些工作负载都具有很高的并发性。工作负载由一个 Java 驱动程序执行,这个程序产生一个到 n 个并发线程。每个线程模拟一个用户,该用户连接到数据库并提交一个事务流,而不考虑次数。每个事务流是以加权方式从一系列事务模板中随机选择的一系列事务。每个事务被分配一个权重,这个权重决定这个事务在工作负载中的百分比。在运行时,事务中的参数标志替换为具体的值,这些值是从可配置的随机值分布和输入列表中提取的。
插入工作负载用大约 100GB 的原始 XML 数据填充数据库:
首先,83 个并发用户插入所有证券。然后,分阶段插入 CustAcc 和订单文档,从而检验插入性能是可伸缩的。在每个阶段使用 100 个并发用户,见表 4。
阶段 | 数据库中的 CustAcc 文档数量 | 数据库中的订单文档数量 |
---|---|---|
1 | 100,000 | 500,000 |
2.1 | 200,000 | 1,000,000 |
2.2 | 300,000 | 1,500,000 |
2.3 | 400,000 | 2,000,000 |
2.4 | 500,000 | 2,500,000 |
2.5 | 600,000 | 3,000,000 |
3.1 | 1,000,000 | 5,000,000 |
3.2 | 1,500,000 | 7,500,000 |
3.3 | 2,000,000 | 10,000,000 |
4.1 | 2,500,000 | 12,500,000 |
4.2 | 3,000,000 | 15,000,000 |
4.3 | 3,500,000 | 17,500,000 |
4.4 | 4,000,000 | 20,000,000 |
5.1 | 4,500,000 | 22,500,000 |
5.2 | 5,000,000 | 25,000,000 |
5.3 | 5,500,000 | 27,500,000 |
5.4 | 6,000,000 | 30,000,000 |
在插入负载填充数据库之后,对数据库执行一个只读的工作负载。这个工作负载由 7 个 XML 查询组成,使用 25、50、75、100、125 和 150 个并发用户以不同的并发度执行。测试的时间长度是这 6 个测试各运行一个小时。
7 个查询都具有以下特征:
表 5 显示这 7 个查询的特征差异和它们涉及的表。
Q | 查询名 | CustAcc | Security | Order | 特征 |
---|---|---|---|---|---|
1 | get_order | - | - | X | 返回完整的订单文档,但是没有 FIXML 根元素。 |
2 | get_security | - | X | - | 返回完整的证券文档。 |
3 | customer_profile | X | - | - | 提取 7 个客户元素来构造概况文档。 |
4 | search_securities | - | X | - | 根据 4 个谓词从一些证券中提取元素。 |
5 | account_summary | X | - | - | 构造一个帐号说明。 |
6 | get_security_price | - | X | - | 提取一种证券的价格。 |
7 | customer_max_order | X | - | X | 联结 CustAcc 和订单,寻找一位客户的最大订单。 |
与只读工作负载相似,混合工作负载针对填充的 600 万个 CustAcc 文档和 3000 万个订单执行,并使用 25、50、75、100、125 和 150 个并发用户产生不同的并发度。测试的时间长度是每个测试各运行一个小时。
混合工作负载由以下操作组成:
查询与上面的只读工作负载中的查询完全一样,下面是定义更新/删除/插入事务时考虑的情况:
通过考虑这些目标,产生了表 6 所示的事务组合。
# | 名称 | 类型 | 占总量的百分比 |
---|---|---|---|
1 | get_order | 查询 | 10 |
2 | get_security | 查询 | 10 |
3 | customer_profile | 查询 | 10 |
4 | search_securities | 查询 | 10 |
5 | account_summary | 查询 | 10 |
6 | get_security_price | 查询 | 10 |
7 | customer_max_order | 查询 | 10 |
8 | upd_custacc | 更新 | 3 |
9 | upd_security | 更新 | 3 |
10 | del_custacc | 删除 | 2 |
11 | del_order | 删除 | 10 |
12 | insert_custacc | 插入 | 2 |
13 | Insert_order | 插入 | 10 |
更新事务首先根据一个 XQuery 谓词读取一个特定文档,然后使用它更新数据库中这个文档的原副本。在实际情况下,在读取和更新步骤之间会更新文档,但是这与本文的目的没什么关系,因此为了简化省略了这个步骤。
在执行插入时不进行 XML 模式检验。
更新和删除操作所针对的文档是在数据库中随机选择的。每个新插入的订单和 CustAcc 文档马上可以被后续的事务更新或删除。
数据库设置和所有工作负载不间断地连续执行。23 小时的不间断系统测试的结果见表 7。
任务 | 花费的时间(分钟) | 解释/说明 |
---|---|---|
创建数据库和更新数据库配置 | 1 | - |
插入工作负载 | 160 | 所有阶段的总时间 |
在表和索引上运行 stats | 340 | 时间的分布如下: 22 分 - 证券 2 小时 45 分 - CustAcc 2 小时 54 分 - 订单 |
数据库备份 | 23 | - |
查询和混合工作负载 | 825 | 这两个工作负载都使用 25、50、75、100、125 和 150 个用户运行 |
数据库恢复 | 17.5 | - |
其他 | ~15 | 其他各种任务 |
总时间 | ~1380 | 总运行时间为 23 小时 |
插入 36,020,833 个文档花费的总时间大约是 160 分钟,产生的平均吞吐量是每秒 3770 个插入。吞吐量随文档的大小而变化:
插入这两种文档的数据量速度都是大约每小时 30GB。图 2 显示随着订单数量增长到 300 万个文档,订单插入的速度几乎保持不变。
查询工作负载的性能随着用户数量的增加和更好地利用 CPU 而增加。正如预期的,随着 CPU 利用率接近 100%,吞吐量曲线逐渐变平。最好的吞吐量出现在有 150 个用户的情况下,在 CPU 利用率为 96% 时达到每秒 5480 个查询,见图 3。
将用户数量增加到 175 并不会使吞吐量显著提高,因为机器已经达到满负荷了。
混合工作负载最好的性能也出现在有 150 个并发用户时,见图 4。吞吐量是每秒 1980 个事务。正如预期的,混合工作负载的吞吐量比纯查询和纯插入工作负载低。
这次性能研究的目的是,在使用最新的 IBM 服务器硬件、存储、AIX 操作系统和 DB2 9 软件的情况下,演示 XML 工作负载的操作性能特征。所有测试都使用 DB2 新的 STMM 和自动存储特性。
我们觉得,对于包含基于消息的事务处理的 XML 应用程序以及处理大量小 XML 文档的 Web 服务应用程序,这个工作负载场景是有代表性的。选择金融业是因为我们在这方面有经验,而且它采用了一种成熟的标准化的 XML 模式 —— FIXML。
下面对测试的情况做一下总结:
如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。
现场直击|2021世界人工智能大会
直击5G创新地带,就在2021MWC上海
5G已至 转型当时——服务提供商如何把握转型的绝佳时机
寻找自己的Flag
华为开发者大会2020(Cloud)- 科技行者