DB2 9 XML 性能特征
新客网 XKER.COM 2006-08-27 来源： 收藏本文
插入工作负载：只写
插入工作负载用大约 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 所示的事务组合。
上一篇：使用SQL查询DB2 9中的XML数据 下一篇：DB2 9数据库免费版下载地址
最新相关文章- ·DB2 9打开打开通往 XML 之门
- ·详细讲解有关“DB2“数据库的一些小技巧
- ·DB2数据库在AIX上如何卸载并重新安装
- ·轻松掌握IBM DB2数据库的31个使用技巧
- ·教你快速掌握Oracle SQL到DB2 SQL的移植
- ·深入剖析DB2数据库应用系统的性能优化
- ·如何解决DB2数据库代码页不兼容的问题
- ·维护IBM DB2数据库所应了解的基本知识
- ·实例讲解如何在DB2 UDB中正确的监控死锁
- ·轻松解决DB2创建存储过程时遇到的错误
- ·经验总结:使用IBM DB2数据库的注意事项
- ·如何解决DB2中出现的SQL1032N错误现象
- ·快速掌握IBM DB2数据库的常用操作指令
- ·三种级别的DB2数据库字符集的设置与修改
- ·教你快速掌握DB2数据库中的相关命令
- ·详细讲解DB2数据库性能监控的具体步骤
发表评论
评论内容：不能超过250字，需审核后才会公布，请自觉遵守互联网相关政策法规。
阅读排行
随机推荐
实用信息推荐