DB2 9 XML 性能特征

使用模拟的经纪场景测试金融事务处理的吞吐量

了解一个使用 DB2® 9 XML、IBM POWER5+、AIX 5.3 和 TotalStorage DS8100 的模拟证券经纪事务处理环境的性能和可伸缩性。这个场景使用了 FIXML 模式,这是一个金融业标准。

Irina Kogan, DB2/XML Performance, IBM Toronto Lab

Irina KoganIrina Kogan 是 IBM Toronto Lab 的软件工程师,从事 DB2 中的 XML 性能研究。她感兴趣的领域包括 XML 存储和结构化更新、XQuery、OLTP 和基准开发。Irina 拥有 York University 的计算机科学理学士和理科硕士学位。她的专长主要在语义完整性和良好的数据库设计原则方面。在 2004 年加入 IBM 之前,她在德国西门子从事 XML 和 Java 开发。



Matthias Nicola (mnicola@us.ibm.com), DB2/XML Performance, IBM Silicon Valley Laboratory

Author photo: Matthias NicolaNicola 博士是 IBM Silicon Valley Lab 中 XML 数据库性能方面的技术领导。他的工作重点是 DB2 中 XML 性能的所有方面,包括 XQuery、SQL/XML 和 DB2 中的所有本机 XML 特性。Nicola 博士与 DB2 XML 开发团队和使用 XML 的客户和业务合作伙伴密切联系,帮助他们设计、实现和优化 XML 解决方案。在加入 IBM 之前,Nicola 博士在 Informix Software 从事数据仓库性能。他还在 4 年时间里从事分布式和复制数据库的研究和工业项目。他于 1999 年从德国 Technical University of Aachen 获得了计算机科学博士学位。


developerWorks 投稿作者

Berni Schiefer (schiefer@ca.ibm.com), DB2 Distinguished Engineer, IBM Toronto Lab

Berni SchieferBerni Schiefer 是 DB2 distinguished engineer。他负责 DB2 性能基准和解决方案开发,包括 BCU。他于 1985 年加入 IBM Toronto Lab,在从事 DB2 之前,他在 IBM Almaden Research Lab 从事 SQL/DS 和 Starburst 实验性关系数据库。他当前的工作重点是将先进的技术引入 DB2,特别是在处理器、性能、XML、Linux、虚拟化和自治方面。



2006 年 7 月 27 日

简介

既然 DB2 9 发布了,现在是时候对它的最新特性之一 —— pureXML® 进行测试驱动了。为此,建立了一个模拟的经纪业务环境。这个环境具有以下特征:

  • 高事务量和并发性
  • 小的事务大小
  • 大量小型 XML 文档
  • 可变的 XML 文档结构 —— 测试包含符合 FIXML 的数据,FIXML 是 Financial Information eXchange(FIX)标准的金融业 XML 实现。

请记住,XML 应用程序大致分成以下两类:

  • 面向数据的(高数据量,小文档,这个测试就是针对这种情况)
  • 面向文档的(可变数据量,大文档)

另外,涉及 XML 的数据库应用程序也是各种各样的,包括以下情况:

  • 以 XML 形式发布关系数据
  • 用 XML 全文本搜索进行内容和文档管理
  • 合并不同的数据源
  • 表单处理
  • 对 Web 服务和面向服务体系结构(SOA)的后端支持
  • 基于消息的事务处理和基于 XML 的在线事务处理(OLTP),尤其是在金融业中

本文在一个基于 XML 的事务处理场景中进行性能度量,这个场景模拟一个面向数据的金融应用程序。测试设备包括最新的 POWER5 服务器(p5 560Q)以及 AIX 5.3 和 TotalStorage DS8100 磁盘系统。

DB2 9 和 XML

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):

  • Customer: 一个客户可以有一个或多个帐号(account)
  • Account: 每个帐号包含一个或多个持有物(holding)
  • Holding: 某一证券 的数量。
  • Security: 某一持有物的标识符(例如,股票名称)。
  • Order: 为一个帐号 买卖一种证券 的订单。
图 1. 数据实体和 XML 模式
数据实体和 XML 模式

文档处理和大小因文档类型而异:

  • 对于每个客户,有一个 CustAcc 文档,其中包含这个客户的所有客户信息、帐号信息和持有物信息。CustAcc 文档的大小在 4KB 和 20KB 之间。
  • 使用 FIXML 4.4 表示订单。FIXML 是用于交易相关消息(比如买卖订单)的行业标准 XML 模式(www.fixprotocol.org)。订单文档的大小是 1KB 到 2KB。订单文档有许多属性,而且数据节点的比例很高。
  • 证券文档(20833 个)使用实际的证券符号和名称,表示在美国交易的大多数股票和共同基金。它们的大小在 3KB 和 10KB 之间。

使用 Toxgene 数据生成器为这三个模式生成实例文档。关于 Toxgene 数据生成器的更多信息,请参考 ToXgene - the ToX XML Data Generator


测试设备和配置

测试在以下设备上运行:

  • 处理器: IBM System p5 560Q,使用 8 个处理器的逻辑分区(LPAR),这是一个中等的 IBM System p5 560Q。8 个处理器以 1.5GHz 的频率运行。
  • 内存: 32GB
  • 操作系统: AIX 5L v5.3 TL04(系统类型:9116-561,两个 4 芯片模块)
    • 并发多线程提供 16 个并发执行线程或逻辑处理器。
    • 安装了一个多路径子系统设备驱动程序(SDD)。这个特性可以改进存储服务器访问,比如改进数据可用性和存储服务器上跨光纤通道适配器的动态 I/O 负载平衡。
  • 存储: IBM TotalStorage DS8100,通过 4 个光纤通道适配器连接到 LPAR。

AIX 配置

在安装 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 总结了配置。

表 1. 存储配置
方面配置
处理器两个处理器,每个附带 pSeries POWER5 1.9 GHz 两路 CEC
内存(缓存)32GB
磁盘互连Switched FC-AL
磁盘数量128 个(只有 64 个由主机 LPAR 使用)
磁盘大小/速度73 GB,15000 RPM

DB2 配置

DB2 9 包含许多新特性,包括新的自治自调整功能。在这个测试中,利用了其中几种自治功能,包括:

  • 自动存储管理
  • 自调整内存管理

因为启动了 DB2 的自调整内存管理器(STMM),它会连续调整一系列 DB2 配置参数的设置。在测试运行期间 STMM 管理和调整的一些关键的 DB2 配置参数见表 2。要意识到的重要情况是,STMM 会根据正在运行的工作负载类型(比如纯插入、纯查询或混合型工作负载)自主地修改这些值。

表 2. 数据库配置,自调整
DB 配置参数名初始设置
SELF_TUNING_MEMON(默认值)
DATABASE_MEMORYAUTOMATIC(默认值)
SORTHEAP156
SHEAPTHRES_SHR10000
LOCKLIST53000
MAXLOCKS80
PCKCACHESZ27000
缓冲池名初始设置
IBMDEFAULTBP1100000
CATBP4000
TEMPBP1000

DBA 只需要执行很少的数据库配置任务,见表 3。

表 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 数据填充数据库:

  • 600 万个 CustAcc 文档
  • 3000 万个订单
  • 20833 种证券

首先,83 个并发用户插入所有证券。然后,分阶段插入 CustAcc 和订单文档,从而检验插入性能是可伸缩的。在每个阶段使用 100 个并发用户,见表 4。

表 4. 分阶段的数据库填充
阶段数据库中的 CustAcc 文档数量数据库中的订单文档数量
1100,000500,000
2.1200,0001,000,000
2.2300,0001,500,000
2.3400,0002,000,000
2.4500,0002,500,000
2.5600,0003,000,000
3.11,000,0005,000,000
3.21,500,0007,500,000
3.32,000,00010,000,000
4.12,500,00012,500,000
4.23,000,00015,000,000
4.33,500,00017,500,000
4.44,000,00020,000,000
5.14,500,00022,500,000
5.25,000,00025,000,000
5.35,500,00027,500,000
5.46,000,00030,000,000

查询工作负载:只读

在插入负载填充数据库之后,对数据库执行一个只读的工作负载。这个工作负载由 7 个 XML 查询组成,使用 25、50、75、100、125 和 150 个并发用户以不同的并发度执行。测试的时间长度是这 6 个测试各运行一个小时。

7 个查询都具有以下特征:

  • 它们都是用符合标准的 SQL/XML 表示法编写的,比如带有嵌入式 XQuery 的 SQL,利用了参数标志。更多信息请参考 Advancements in SQL/XML
  • 它们使用 SQL/XML 谓词 XMLEXISTS 根据一个或多个条件选择 XML 文档,条件用 XQuery 表示法表示。
  • 它们使用 SQL/XML 函数 XMLQUERY 检索完整的或部分 XML 文档,或者构造与数据库中存储的文档不同的结果文档。
  • 它们使用与 XML 数据中的名称空间对应的 XML 名称空间。
  • 它们利用一个或多个 XML 索引完全避免表扫描。
  • 这 7 个查询在工作负载中具有同样的权重。

表 5 显示这 7 个查询的特征差异和它们涉及的表。

表 5. XML 查询小结
Q查询名CustAccSecurityOrder特征
1get_order - - X返回完整的订单文档,但是没有 FIXML 根元素。
2get_security - X - 返回完整的证券文档。
3customer_profileX - - 提取 7 个客户元素来构造概况文档。
4search_securities - X - 根据 4 个谓词从一些证券中提取元素。
5account_summaryX - - 构造一个帐号说明。
6get_security_price - X - 提取一种证券的价格。
7customer_max_orderX - X联结 CustAcc 和订单,寻找一位客户的最大订单。

混合工作负载:读/写

与只读工作负载相似,混合工作负载针对填充的 600 万个 CustAcc 文档和 3000 万个订单执行,并使用 25、50、75、100、125 和 150 个并发用户产生不同的并发度。测试的时间长度是每个测试各运行一个小时。

混合工作负载由以下操作组成:

  • 70% 的读操作:查询
  • 30% 的写操作:6% 的更新操作,12% 的文档删除操作,12% 的插入操作。

查询与上面的只读工作负载中的查询完全一样,下面是定义更新/删除/插入事务时考虑的情况:

  • 更新客户帐号以反映交易(订单的执行),但是不需要在每个订单之后立即执行(3% 的 CustAcc 更新)
  • 在我们的场景中不更新订单文档(因此没有订单更新事务)
  • 在交易时间定期更新证券的价格(3% 的证券更新)
  • 客户的插入和删除少(2% 的 CustAcc 插入,2% 的 CustAcc 删除)
  • 新订单不断到达,旧订单从系统中删除,两者的速率是相同的(10% 的订单插入,10% 的订单删除)
  • 证券种类的数量是固定的(没有删除和插入事务)

通过考虑这些目标,产生了表 6 所示的事务组合。

表 6. 混合工作负载的事务
#名称类型占总量的百分比
1get_order查询10
2get_security查询10
3customer_profile查询10
4search_securities查询10
5account_summary查询10
6get_security_price查询10
7customer_max_order查询10
8upd_custacc更新3
9upd_security更新3
10del_custacc删除2
11del_order删除10
12insert_custacc插入2
13Insert_order插入10

更新事务首先根据一个 XQuery 谓词读取一个特定文档,然后使用它更新数据库中这个文档的原副本。在实际情况下,在读取和更新步骤之间会更新文档,但是这与本文的目的没什么关系,因此为了简化省略了这个步骤。

在执行插入时不进行 XML 模式检验。

更新和删除操作所针对的文档是在数据库中随机选择的。每个新插入的订单和 CustAcc 文档马上可以被后续的事务更新或删除。


结果

数据库设置和所有工作负载不间断地连续执行。23 小时的不间断系统测试的结果见表 7。

表 7. 使用所有工作负载的全面测试的计时
任务花费的时间(分钟)解释/说明
创建数据库和更新数据库配置1 -
插入工作负载160所有阶段的总时间
在表和索引上运行 stats340时间的分布如下:
22 分 - 证券
2 小时 45 分 - CustAcc
2 小时 54 分 - 订单
数据库备份23 -
查询和混合工作负载825这两个工作负载都使用 25、50、75、100、125 和 150 个用户运行
数据库恢复17.5 -
其他~15其他各种任务
总时间~1380总运行时间为 23 小时

插入工作负载的结果

插入 36,020,833 个文档花费的总时间大约是 160 分钟,产生的平均吞吐量是每秒 3770 个插入。吞吐量随文档的大小而变化:

  • 订单文档(1K 到 2K)以平均每秒 5320 个插入的吞吐量插入。
  • 帐号文档(3K 到 10K)以平均每秒 1550 个插入的吞吐量插入。

插入这两种文档的数据量速度都是大约每小时 30GB。图 2 显示随着订单数量增长到 300 万个文档,订单插入的速度几乎保持不变。

图 2. 订单文档的插入速度
订单文档的插入速度

查询工作负载的结果

查询工作负载的性能随着用户数量的增加和更好地利用 CPU 而增加。正如预期的,随着 CPU 利用率接近 100%,吞吐量曲线逐渐变平。最好的吞吐量出现在有 150 个用户的情况下,在 CPU 利用率为 96% 时达到每秒 5480 个查询,见图 3。

将用户数量增加到 175 并不会使吞吐量显著提高,因为机器已经达到满负荷了。

图 3. 只读查询吞吐量、CPU 利用率和 I/O 等待时间
只读查询吞吐量、CPU 利用率和 I/O 等待时间

混合工作负载的结果

混合工作负载最好的性能也出现在有 150 个并发用户时,见图 4。吞吐量是每秒 1980 个事务。正如预期的,混合工作负载的吞吐量比纯查询和纯插入工作负载低。

图 4. 混合工作负载吞吐量、CPU 利用率和 I/O 等待时间
混合工作负载吞吐量、CPU 利用率和 I/O 等待时间

结束语

这次性能研究的目的是,在使用最新的 IBM 服务器硬件、存储、AIX 操作系统和 DB2 9 软件的情况下,演示 XML 工作负载的操作性能特征。所有测试都使用 DB2 新的 STMM 和自动存储特性。

我们觉得,对于包含基于消息的事务处理的 XML 应用程序以及处理大量小 XML 文档的 Web 服务应用程序,这个工作负载场景是有代表性的。选择金融业是因为我们在这方面有经验,而且它采用了一种成熟的标准化的 XML 模式 —— FIXML。

下面对测试的情况做一下总结:

  • 总测试时间为 23 小时,包括创建数据库。
  • 测试数据由 600 万个 CustAcc 文档、3000 万个订单文档和 20833 个证券文档组成。
  • 测试分别采用 25、50、75、100、125 和 150 个并发用户。
  • 插入吞吐量(每秒事务数,即 tps)随文档的大小而变化,但是在一个大小内是线性的。吞吐数据量稳定在每小时 30GB,与文档大小无关:
    • 1550 tps(CustAcc 文档,4K 到 20K)
    • 5320 tps(订单文档,1K 到 2K)
  • 查询吞吐量随并发用户数量伸缩:
    • 25 个用户时 2000 tps
    • 150 个用户时 5500 tps(CPU 利用率最大,I/O 等待时间接近零)
  • 混合事务吞吐量也随并发用户数量伸缩,直到大约 2000 tps:
    • 25 个用户时 1000 tps
    • 150 个用户时 2000 tps(~42% 的CPU 利用率,~50% 的 I/O 等待时间)。

致谢

作者感谢 Sunil Kamath 和 Punit Shah 对这个项目和本文的贡献。

参考资料

学习

获得产品和技术

  • 使用 IBM 试用软件 构建您的下一个开发项目,这些软件可以从 developerWorks 直接下载。

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management, XML, AIX and UNIX
ArticleID=150929
ArticleTitle=DB2 9 XML 性能特征
publish-date=07272006