|
引言
本文是探讨使用 IBM® DB2® Information Integrator™ 来实现 J2EE 组件（这些组件从多个不同的数据源检索和合并数据）的系列文章中的第三篇，也是最后一篇。我们的第一篇文章是将 DB2 Information Integrator 用于 J2EE 开发：成本／收益分析，描述了我们的一个项目，用来比较当使用和不使用 DB2 Information Integrator 来实现这类应用程序时的开发成本。第二篇是跨多个数据源的 J2EE 开发：细节探讨，涵盖了实现我们开发的 J2EE servlet 的详细信息：
一组 servlet 通过直接访问分布到 DB2 Universal Database™、Oracle 和 Microsoft® Excel 数据源的数据来评估联邦查询。
另一组 servlet 使用 DB2 Information Integrator 来处理同一组的业务问题，这使得全部三个数据源中的数据作为单个数据库出现。
我们发现，使用 DB2 Information Integrator 开发 servlet 远比不使用它时容易，因为我们不必担心拆分联邦查询以及管理对每个数据源的访问甚烦人的细节。但性能如何呢？使用 DB2 Information Integrator 开发的简便性是否会导致高成本呢？难道对那些多数据源查询进行手工编码不会使它们运行得更快吗？本篇文章会在我们的实验中解决那些问题，并且我们希望通过这篇文章，您将对您的环境有更深的了解。
概要：性能结果的总结
那么哪个更快呢？从 servlet 直接访问多个数据源？还是 DB2 Information Integrator？在性能问题上，答复照例是（也当然是）“视情况而定”。更准确地说，它取决于查询。我们分别用两种方法实现五个查询。在前一篇文章中详细地讨论过它们的实现，而且您也将在本篇文章中再次看到这些查询，但目前，我们将只注意到所有的查询会访问两个或更多的数据源中的数据，并且大部分查询连接两个或更多的表或视图。表 1 包含以秒计的所用时间的比较。
表 1. 查询的所用时间
查询
直接访问多个数据源
使用 DB2 Information Integrator
1
3.4 秒
3.5 秒
2
0.18 秒
0.25 秒
3
170.1 秒
44.5 秒
4
79.9 秒
4.5 秒
5
9.9 秒
15.1 秒
如您所见，使用 DB2 Information Integrator 的联邦查询的性能与从 J2EE 组件直接访问数据的性能是相当具有可比性的。查询 1 在两种情况下耗费的时间相差无几，而在两种情况下查询 3 和 4 中 DB2 Information Integrator 比直接应用程序访问数据快了 4 到 17 倍，但在其它两个查询（查询 2 和 5）中慢了 40% - 50%。
让我们来观察这个结果。例如在查询 5 中，直接访问 servlet 能够实现对于 DB2 Information Integrator 不可用的执行策略，并从而获得性能上的优势。然而，必须将这种优势与在定制直接访问 servlet 中实现联邦查询时固有的可观的额外开发成本、潜在的错误以及缺乏扩展性进行权衡。请记住直接访问 servlet 是手工编码的应用程序，用以实现特定的查询；而 DB2 Information Integrator 是一个通用的基础结构，可以处理任何 SQL 查询而无需特殊的编程。
尽管我们只能测试五个查询，但这些查询都非常具有代表性，可以代表可能在 Web 商务或决策支持环境中执行的、具有不同的性能特性的查询。查询组的结果说明从性能的观点来看，DB2 Information Integrator 可以为 J2EE 组件（这些组件实现跨多个数据源的分布式查询）提供直接应用程序访问的合理的替代方法。
概述
我们将从快速回顾影响联邦查询性能的因素开始。接下来，我们会描述如何安装和配置远程数据源及 DB2 Information Integrator，重点着眼于性能关键性方面（例如索引和统计信息）。最后，我们将详细地描述五个查询中的每一个，并比较它们的执行（分别使用直接应用程序访问数据和 DB2 Information Integrator）。在此过程中，我们将提供一些技巧以从 DB2 Information Integrator 获得最佳性能，同时也能理解为何它在有些情况下表现得很出色，而其它情况下不那么出色。
联邦查询的性能
不论您是使用 DB2 Information Integrator 联邦服务器，还是直接访问数据的定制集成应用程序，跨越多个远程数据源的查询的性能都取决于一些相当明显的因素，包括：
远程数据源和联邦服务器（或定制集成组件）所在机器的速度，以及那些机器之间网络的容量。
在远程数据源选择的查询执行方案（用以执行 DB2 Information Integrator 或者定制集成组件提交给它们的查询）。
除了那些因素之外，决定联邦查询的性能最至关重要的因素是在联邦服务器端的查询执行方案，或者是定制集成组件用以从多个数据源检索和合并数据的处理策略。如果在远程数据源上完成同样多的远程数据处理，它通常会是最佳的，很少有例外，因为从远程数据源检索数据以便在联邦服务器上完成本地处理的代价是很高昂的。例如，对一个谓词（它从远程数据源的远程表中过滤出许多行以将返回 DB2 Information Integrator 或定制集成组件的行数减到最少）求值就是一个不错的主意。
类似地，若要连接同一远程数据源的两张表，通常最佳的做法是在远程数据源上“叠加（push down）”连接并执行。这在连接产生的行比参与该连接的两张表的总行数少时是成立的。然而，如果连接产生的行数比涉及的两张表中符合条件的总行数多，那么可能在本地执行连接会更好。注意，我们所说的“在本地”指的是相对于远程数据源的在 DB2 Information Integrator 上进行的处理。在远程或在本地执行连接的决策（不论通过定制集成组件或是 DB2 Information Integrator）主要取决于使得从涉及的全部远程数据源返回的总行数最少的需要。DB2 Information Integrator 会根据在查询编译过程中昵称的统计信息自动作出选择；而定制集成组件的开发者必须在实现的过程中作出决策。
在此描述的对比实验中，我们尽量确保将尽可能多的处理叠加至每个查询的远程 DB2 UDB、Oracle 和 Excel 数据源。直接访问远程数据的 J2EE servlet 有机会也有责任完全控制联邦查询的分解、叠加和本地合并处理。使用 DB2 Information Integrator 的 J2EE servlet 依赖 DB2 Information Integrator 来拆分联邦查询，并向每个数据源发送相应的子查询。如果正确地配置 DB2 Information Integrator，并且如果远程对象的昵称具有精确的索引和统计信息，则 DB2 Information Integrator 可以完成具有高度叠加的查询执行方案。
DB2 Information Integrator 中有一种提高性能的功能，它能通过创建所谓的具体查询表（materialized query table，MQT）来创建远程数据的本地高速缓存副本。MQT（以前称为“自动摘要表”）不仅可以在本地表上定义，而且可以定义为包括一个或多个昵称的子查询的结果。MQT 因而可以作为远程数据的本地“时间点”的快照来使用。它的存在和使用对于向 DB2 Information Integrator 发出包括多个昵称的查询的用户来说是透明的。也就是说，优化器可以透明地决定使用正确定义的 MQT 中的本地数据，而不真正地通过昵称访问该数据。使用本地而非远程数据在性能上会有非常明显的优势，特别是如果用户在执行与其它用 DB2 Information Integrator 在本地存储的数据的连接时。本篇文章中呈现的结果并不能反映 MQT 的使用，我们将指出其中两个样本查询中使用 MQT 可能会有优势的情况。
远程数据源和联邦数据库的配置
本节描述了硬件和软件的设置，包括网络连接、跨数据源的数据的布局、表的索引以及昵称的统计信息。
[VB.NET程序]SYSTEM_BASIC_INFORMATION结构 [网页制作][J2EE] 实战开发EJB
[网页制作]实战 J2EE 开发购物网站 经验篇 [JAVA开发]周末闲侃：论J2EE程序员的武功修为
[JAVA开发]基于J2EE的电子商务网站实例解析 [JAVA开发]用AJAX+J2EE实现一个网上会议室系统
[JAVA开发]利用Spring框架改进J2EE编程 [JAVA开发]J2EE MVC模式JSF与Struts的异同
[JAVA开发]J2EE Web服务客户端质量报告(五) [JAVA开发]J2EE Web服务客户端质量报告(四)
| 
注：本站部分文章源于互联网，版权归原作者所有！如有侵权，请原作者与本站联系，本站将立即删除！ 本站文章除特别注明外均可转载，但需注明出处！ [MinTao学以致用网] 
