DB2 9 XML 性能特征
了解一个使用 ® 9 XML、IBM POWER5+、AIX 5.3 和 TotalStorage DS8100 的模拟证券经纪事务处理环境的性能和可伸缩性。这个场景使用了 FIXML 模式，这是一个金融业标准。
简介
既然 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 磁盘。
9 和 XML
9 中新的 XML 支持包括纯 XML 存储、XML 索引、XQuery、SQL/XML 和高级的 XML 模式处理。“纯” 意味着以标注上类型的树的形式存储和处理 XML 文档，这与商业关系数据库中以前的任何技术都不同。尤其是，pureXML 与将 XML 存储为大对象（BLOB 或 CLOB）或者将 XML 分解到关系表中的技术有显著差异。更多的信息请参考以前的文章 “What's new in Viper” （developerWorks，2006 年 2 月）和 “Native XML Support in Universal Database”。
  |
|
测试场景：在线经纪业务
这个测试场景对在线经纪业务进行建模。我们曾经帮助金融公司采用 XML。这些经历帮助我们理解了他们的数据和处理特征。这个场景有意地进行了简化，但是在文档、事务和 XML 模式方面仍然具有代表性。
这个场景中主要的逻辑数据实体如下（见图 1）：
- Customer： 一个客户可以有一个或多个帐号（account）。
- Account： 每个帐号包含一个或多个持有物（holding）。
- Holding： 某一证券 的数量。
- Security： 某一持有物的标识符（例如，股票名称）。
- Order： 为一个帐号 买卖一种证券 的订单。
图 1. 数据实体和 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 配置
在安装 期间，会自动执行所有必需的操作参数调整。设置了以下的虚拟内存管理参数，从而更好地控制文件缓存使用的内存量：
|
另外，为了防止在数据装载期间试图缓存输入文件，在挂装命令中使用 -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）。在这个卷组上定义了 数据库的所有存储组件，包括表空间、日志和备份。表 1 总结了配置。
表 1. 存储配置
| 方面 | 配置 |
|---|---|
| 处理器 | 两个处理器，每个附带 pSeries POWER5 1.9 GHz 两路 CEC |
| 内存（缓存） | 32GB |
| 磁盘互连 | Switched FC-AL |
| 磁盘数量 | 128 个（只有 64 个由主机 LPAR 使用） |
| 磁盘大小/速度 | 73 GB，15000 RPM |
配置
9 包含许多新特性，包括新的自治自调整功能。在这个测试中，利用了其中几种自治功能，包括：
- 自动存储管理
- 自调整内存管理
因为启动了 的自调整内存管理器（STMM），它会连续调整一系列 配置参数的设置。在测试运行期间 STMM 管理和调整的一些关键的 配置参数见表 2。要意识到的重要情况是，STMM 会根据正在运行的工作负载类型（比如纯插入、纯查询或混合型工作负载）自主地修改这些值。
表 2. 数据库配置，自调整
| 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。
表 3. 数据库配置，手工
| 方面 | 配置/设置 |
|---|---|
| 数据库 | Unicode。所有表空间采用自动存储。 日志在单独的条带上 |
| 内存 | 为所有测试启用 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 文档数量 | 数据库中的订单文档数量 |
|---|---|---|
| 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 个查询都具有以下特征：
- 它们都是用符合标准的 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 | 查询名 | 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 个并发用户产生不同的并发度。测试的时间长度是每个测试各运行一个小时。
混合工作负载由以下操作组成：
- 70% 的读操作：查询
- 30% 的写操作：6% 的更新操作，12% 的文档删除操作，12% 的插入操作。
查询与上面的只读工作负载中的查询完全一样，下面是定义更新/删除/插入事务时考虑的情况：
- 更新客户帐号以反映交易（订单的执行），但是不需要在每个订单之后立即执行（3% 的 CustAcc 更新）
- 在我们的场景中不更新订单文档（因此没有订单更新事务）
- 在交易时间定期更新证券的价格（3% 的证券更新）
- 客户的插入和删除少（2% 的 CustAcc 插入，2% 的 CustAcc 删除）
- 新订单不断到达，旧订单从中删除，两者的速率是相同的（10% 的订单插入，10% 的订单删除）
- 证券种类的数量是固定的（没有删除和插入事务）
通过考虑这些目标，产生了表 6 所示的事务组合。
表 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。
表 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 个插入。吞吐量随文档的大小而变化：
- 订单文档（1K 到 2K）以平均每秒 5320 个插入的吞吐量插入。
- 帐号文档（3K 到 10K）以平均每秒 1550 个插入的吞吐量插入。
插入这两种文档的数据量速度都是大约每小时 30GB。图 2 显示随着订单数量增长到 300 万个文档，订单插入的速度几乎保持不变。
图 2. 订单文档的插入速度
查询工作负载的结果
查询工作负载的性能随着用户数量的增加和更好地利用 CPU 而增加。正如预期的，随着 CPU 利用率接近 100%，吞吐量曲线逐渐变平。最好的吞吐量出现在有 150 个用户的情况下，在 CPU 利用率为 96% 时达到每秒 5480 个查询，见图 3。
将用户数量增加到 175 并不会使吞吐量显著提高，因为机器已经达到满负荷了。
图 3. 只读查询吞吐量、CPU 利用率和 I/O 等待时间
混合工作负载的结果
混合工作负载最好的性能也出现在有 150 个并发用户时，见图 4。吞吐量是每秒 1980 个事务。正如预期的，混合工作负载的吞吐量比纯查询和纯插入工作负载低。
图 4. 混合工作负载吞吐量、CPU 利用率和 I/O 等待时间
|
|
结束语
这次性能研究的目的是，在使用最新的 IBM 服务器硬件、存储、AIX 操作和 9 软件的情况下，演示 XML 工作负载的操作性能特征。所有测试都使用 新的 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 等待时间）。
