WebSphere Information Integrator

随着 IBM? WebSphere? Information Integrator 8.2 的发布，IBM 提供了一项称作队列复制或 Q 复制的功能，使数据库复制有了很大的进步。新的复制架构是随着对高性能（高事务量，低延时）的需求而出现的。本文将介绍新的 Q 复制架构，预期它有什么样的性能，以及哪些因素对性能有影响。此外，我们还将研究实验室测试时在 AIX? 和 z/OS? 平台上所使用的例子。 注意：在阅读本文之前，请先阅读免责声明。 简介 随着 WebSphere Information Integrator 8.2 的发布，IBM 提供了一个称作队列复制 或 Q 复制 的功能，使数据库复制有了很大的进步。这种新的复制架构是随着对高性能的需求而出现的，高性能是指高事务量和低延时，这里的延时是从在源数据库上提交对源数据库的更改到这些更改在目标数据库上完成提交这中间所经历的时间。 本文描述新的 Q 复制架构，讨论预期的性能水平，以及影响性能的一些因素，并给出在实验室测试时在 AIX 和 z/OS 平台上所使用的例子。文中的信息对于那些有兴趣使用 Q 复制，以及想知道 Q 复制对性能的影响的客户来说会有所帮助。 为什么是新的架构？ 数据复制技术对于 IBM 或 DB2? 来说并不是什么新技术，早在十年前，该技术就第一次被引入到一个称作 DataPropagator? Relational（DPropR）的产品当中。从那以后，它的名称和包有所变化，产品的广度和功能有所扩展，形成的一组产品也获得了实实在在的商业上的成功。 现有的复制架构是 SQL 复制，它依然与 Q 复制并驾齐驱，并且在多种客户场景中很可能仍将是最佳解决方案。 对于 SQL 复制，数据库的更改可以被捕捉，并临时地存储在称作关系中间表（staging table）的关系表中。然后，从目标系统上的一个客户接口可以读取这些关系中间表，并将它们应用于目标表。SQL Replication 与 DB2 for Linux?、DB2 for UNIX? 和 DB2 for Windows? 一起打包。在 z/OS 上，SQL Replication 以 DB2 Data Propagator 的形式提供给用户，此外，它还包含在所有具有复制功能的 WebSphere Information Integrator 产品当中。对于某些场景，例如那些以非 DB2 数据库作为源或目标的场景，SQL Replication 可能仍是目前的最佳选择。 虽然 SQL Replication 有这些成功之处，但它也面临一些技术上的挑战，特别是当客户系统有所增长，性能需要日益提高的时候，挑战尤为突出。而 Q Replication 就是为满足这些性能需求而设计的，此外，它还增加了一些功能，提高了可管理性。 系统在规模上不断增长，打破了吞吐率的限制。与此同时，客户需要更多地实时访问被复制的更改。这些实时更改操作常常需要朝多个方向流动，因此造成对同步两个或更多系统的需要，以及当这些系统并发地更改相同数据时解决冲突问题的需要。 客户对于数据库复制有很多方面的需要，数据库复制这个过程常常需要谨慎地计划和调度。下面是数据库复制的一些传统用法和未来的趋势： 维护数据仓库。这是目前复制功能最常见的用法之一。数据仓库与操作性数据是分离的，这使得它们适合特定查询，这不会影响生产应用的性能。 业务连续性和灾难恢复。对于数据库复制在这方面的需求可能是增长最快的需求。当前，业界提供了各种各样的带有同步和异步复制技术的硬件和软件实现，以解决业务连续性的问题。Q 复制是异步操作的，这意味着更改是在源数据库操作提交之后才传播出去的。如果因为距离较远，而使得主数据库和备份数据库不在一起，那么客户常常会选择异步方法。距离会增加传输延时，这使得同步方法对于高性能应用程序来说不切实际。然而，同步复制意味着当出现故障时，应用程序可以容忍在过渡阶段某些事务出现失败。更小的延时意味着失败的事务更少。与其他常用的硬件和软件解决方案相比，Q 复制惟一的优势是备份数据库可以连续处于活动状态，这缩短了恢复时间。 用于负载均衡的数据分发。只要增加的复制成本相对于处理总量来说比较小，这种用法就有意义，例如，在某些应用程序中，被修改的数据所占比例相对于检索操作或应用程序处理来说较小，这就属于上述情况。 数据在地理上分布或数据的合并。使适当的应用程序“接近”终端用户，或与其他相关数据驻扎在一起，可以提高性能。 支持使用多个数据库的应用程序。很多基于 Web 的应用程序都是由多个数据库构成的。进行在线交易的客户可能在做一笔交易的时候使用其中某个数据库，而通过另一个数据库来验证交易的完成情况。交易数据库可能是为一个遗留应用程序而设计的，并且在考虑在线事务处理（online transaction processing,OLTP）的性能的情况下进行组织，而交易历史数据库则考虑查询性能，并驻留在不同的平台上。因此，关键是使某些应用程序的无缝操作能够以近乎即时的速度，将更改过的数据从一个数据库转移到另一个数据库。 回页首 Q 复制的工作原理 从下面的图 1 可以看到 Q 复制使用消息队列在源数据库和目标数据库之间传递事务数据更改的情况。这里所使用的队列系统是 IBM 的一个旗舰消息传递产品，即 WebSphere MQ。WebSphere MQ 随用于 Linux、UNIX 和 Windows 平台的 WebSphere Information Integrator 一起打包，是 z/OS 环境的必备产品。 图 1. Q 复制 Q 复制有两大基本组件，Q Capture 和 Q Apply。Q Capture 从数据库恢复日志读取数据，并用从提交的事务中选择的数据更改构造消息。然后，这些消息被写入到一个或多个 MQ 队列。这意味着这个过程对于源数据库来说是异步的，只有在数据库更改已经提交到源数据库时，那些消息才会发送到 MQ。每条逻辑消息代表一个完整的、已提交的数据库事务。Q Apply 从消息队列接收事务消息，并将每条消息作为一个事务单元应用到目标系统。 WebSphere MQ 的消息传递功能负责处理跨异构系统和网络协议传递消息的问题。在内部，MQ 使用日志文件和数据文件，以类似于数据库管理系统可能使用的方式，来管理消息的完整性和持久性。这些文件实质上替代了 SQL 复制中由 DB2 处理的关系中间表和相关数据库日志记录功能。 如前所述，Q 复制允许有多个数据副本，该数据可能在多个站点发生改变，并且数据库更改可以朝多个方向流动。这也意味着可能出现冲突，例如，当多个站点更新相同的数据行时就会发生冲突。Q 复制为解决那些冲突提供了一种机制。 Q 订阅定义源表与目标表之间的关系，而且可以用单向、双向或点对点这三种映射类型来定义。两个服务器之间任意方向的复制的数据更改可以定义为双向和点对点。双向映射计算源数据库和目标数据库上的数据值，从而提供了一种简单的、低成本的冲突检测和冲突解决方法。 点对点映射依靠添加到源应用程序数据上的版本信息，提供了更健壮的冲突检测和冲突解决。版本信息是在 Q 复制内部在底层数据库引擎中通过触发器实现的。虽然从性能的角度来看，这种方法成本更高，但它允许两个或更多可以并行地更新的数据库的聚合（convergence）。本文的第 5 节比较了这几种方法的性能。 回页首 Q 复制与 SQL replication 相比的性能 下面的 图 2 和 3 说明了在 AIX 和 z/OS 环境下 Q 复制与 SQL 相比的优势。这两组使用同等工作负载和配置的测试都表明：Q 复制的吞吐率几乎是 SQL 复制的三倍，而且在吞吐率的峰值处仍然维持着低得多的延迟。在这两种配置中，Q 复制每秒可以复制 12,000 多行，而端到端的延迟低于 2 秒，在吞吐率较低的情况下，这种延迟常常低于 1 秒。在这两次测试中使用的工作负载只包含 INSERT，以模拟适度复杂的事务，每个事务有 10 个 INSERT 操作，行大小为 212 字节。这种非常简单的工作负载有它的用处，因为它关注复制过程执行的任务，而减少了测试中使用的硬件资源。例如，我们不需要像真正的应用程序那样为 SELECT 或应用程序处理分配硬件资源。关于本文中使用的工作负载和配置的更多信息，请参阅“工作负载和配置”一节。 还应注意，与 SQL 复制相比，Q 复制真正降低的延迟甚至要好于上面图中显示的那样。Q 复制提供了非常好的性能监控功能，包括对端对端延迟的真实度量，这个延迟是指从源上提交事务开始到事务在目标上完成提交这之间的时间。对于 SQL 复制，这些监控功能不存在，因此基准应用程序采用一种技术来度量平均行延迟。由于每个事务涉及多个行，SQL 复制的事务延迟实际上要高于图中显示的延迟。 对于 z/OS 和 AIX 这两个测试，Q 复制测试表明复制吞吐率限制大约是每秒 12,000 行，当吞吐率达到这个高度时，各种资源变得饱和，从而导致延迟增加。最为显著的是，在达到饱和点之前，延迟一直很稳定，我们的经验是，大多数客户的需求都低于这些限制。但为了保险起见，建议从每秒复制的行数这一角度估计客户的吞吐率需求，并确保在峰值情况下仍然低于限制。此外，这些限制并不是绝对的，要受工作负载和配置变化的影响，这在后面会讨论到。 在图 2 中可以看到，Q 复制在 z/OS 中有更高的吞吐率和更低的延迟.... 图 2. Q 复制与 SQL replication 的性能比较 - z/OS ...在 AIX 上也同样如此。 图 3. Q 复制与 SQL replication 的性能比较 - AIX Q 复制如何提高性能？ 有很多因素可以帮助提高 Q 复制的性能，其中包括： 减少与关系中间表相关的日志记录活动 减少对处理器的使用 增加 Q Apply 处理中的并行度 减少 DB2 日志记录活动 对于 SQL 复制，数据库更改是在源数据库上的 DB2 关系中间表中捕捉的。这要求将附加的日志记录写入到 DB2 日志中。（如果捕捉所有数据库更改，那么就会导致在中间关系表中写入附加的用于插入和删除的日志，从而潜在地使 DB2 日志的写活动增加到原来的三倍。而对于 Q 复制，关系中间表是用 MQ 队列捕捉的。数据文件和日志文件提供 MQ 队列的底层存储，只要这些文件放在与 DB2 日志不同的磁盘上，就可以减少日志文件的内容。 减少对处理器的使用 由于多种原因，Q 复制在源服务器上比 SQL 复制要消耗更少的处理器周期，而在目标服务器上消耗得要更多些，但总体上仍然是少一些。这是至关重要的，因为源服务器最可能运行“生产”应用程序，在那上面的处理器周期是比较珍贵的。 下面的图 4 展示了在 z/OS 上 SQL 复制和 Q 复制对处理器的使用情况的比较。这个图给出了源系统和目标系统上处理器成本的两个度量：每个被复制的行占用的微秒数，以及每一千个被复制的行每秒所需的 MIPS(1) (2)。您可以使用这两个度量来理解不同复制方法在处理器成本方面的不同之处，以及复制的粗略的“能力规划（capacity planning）”估计。 这些测试试图用大致相等但不相同的吞吐量来比较这两个度量点。在所有情况下，复制都可以满足工作负载的需求，并且延迟要小于 5 秒。 图 4 说明了 Q 复制所减少的 CPU 消耗： Q capture 对 CPU 的使用减少 2-3 倍。 Q capture 对 CPU 的使用大约每行 70-80 微秒。 在目标上对 CPU 的使用要稍微多一些（队列管理）。   图 4. Q 复制- 减少的处理器消耗 下面是从这些测试中观察到的一些方面： 将 Q 复制与 SQL 复制相比较，在源服务器上每个被复制的行所需的处理器成本减少了大约三分之二。Q Capture 成本大约是每行 70-80 微秒，每一千个被复制的行每秒只需不超过 20 的 MIPS。 将 Q 复制与 SQL 复制相比较，在目标系统上处理器成本有所增加，其原因是，某些内务功能，例如“修剪（pruning）”消息队列，现在在目标系统上大量地执行。然而，在使用 Q 复制时，在源系统和目标系统上的总体成本通常仍然会有所减少。 增加 Q Apply 处理中的并行度 Q Apply 采用高度的并行性，这是支撑复制目标上源应用程序的吞吐率需求的关键。如果一个源应用程序采用高度的并行性来取得高吞吐率，那么 Q Apply 组件可以使用并行来跟上步伐。 如下面的图 5 所示，对于每个传入的接收队列，Q Apply 启动一个浏览器（可以将这个过程看作是“浏览队列”）。Q Apply 从该队列读取事务，检查事务之间的依赖关系，并基于这种依赖分析通过并行的 Q Apply 代理应用数据更改。一个Q Apply 程序可以处理多个消息队列（每个队列一个浏览器），每个浏览器可以启动多个代理。Q Apply 代理可以并行地应用事务，以跟上发起事务的源应用程序的并行度，从而大大增加复制吞吐率。 图 5. Q Apply 过程 理论上，SQL 复制可以通过启动 SQL Apply 程序的多个实例取得一定程度的并行性，但这需要管理员将表划分到适当的组中，并平衡这些组之间的工作负载。此外，它不能像 Q 复制那样允许在一个很活跃的表内使用并行。 记住，即使只用一个消息队列和一个浏览器，Q 也可以使用多个代理（默认情况下每个浏览器 16 个代理），而不需要管理员做额外的工作。Q Apply 可以自动判断事务之间的依赖关系，因此可以按适当的顺序应用数据更改。管理员可以定义附加的队列，但这需要格外小心，因为没有事务可以跨消息队列修改表。而对于完全独立的应用程序来说，这样做也许是合适的。 下面的图 6 说明了增加 Q Apply 代理和浏览器数量的影响。在这个测试中，我们使用“预先装载”的消息队列测试 Q Apply，以排除 Q Capture 方面的任何约束。此外，在 z/OS LPAR(3) 上使用了 6 个处理器。您可以看到，增加代理的数量可以大大提高吞吐率，增加浏览器也可以得到一定的好处。使用一个消息队列和默认的 16 个代理对于大多数应用程序来说通常已经足够了，在这里，最大工作负载是每秒 15,000 个事务（这确实是一个相当大的工作负载）。 图 6. Q Apply 在 z/OS 中的吞吐率 回页首 双向和点对点映射对性能的影响 下面的图 7 比较了不同复制方案的吞吐率：没有复制的 INSERT 工作负载、单向映射、双向映射和点对点映射。在这些测试中使用的工作负载由 8 个并发的执行 INSERT 操作的任务组成，事务之间有短暂的应用程序延迟(4)。然而，在双向映射和点对点映射的测试中，相同的工作负载要在两个系统上运行，这使得总工作负载翻了一倍。这些工作负载还要在不同的数据上执行，以避免为解决冲突问题而导致的成本。在实际情况中，我们期望客户设计自己的应用程序来尽可能避免冲突，减少对性能的影响。 图 7. 双向映射和点对点映射对性能的影响 图 8 采用与图 4 相同的格式，它展示了每行所需的微秒数以及每一千个被复制的行每秒所需的 MIPS 这两方面的处理器成本。 图 8. 双向映射和点对点映射对 CPU 和资源消耗的影响 下面是从这两个图中观察到的一些方面： 如果将双向测试与单向测试相比较，应该注意到，当我们在第二个系统上运行一个克隆的应用程序时，总吞吐率几乎增加了一倍。记住，每个系统都在运行它自己的基本工作负载，捕捉那些更改，并将更改应用到其他系统。虽然这几乎使每个系统上对处理器的使用量翻了一倍，但每行的成本(5)只是增加了一点点（大约 12%）。对于双向处理，需要一些附加工作来避免递归，确保 Q 复制不会重复捕捉 Q Apply 正在作出的更改。每个系统上的吞吐率稍微有些下降，这是因为增加了对处理器的使用。 如果将点对点测试与双向测试相比较，每个系统上的吞吐率同样稍微有些下降（大约 17%），但每一行的 CPU 成本却大大增多（70%）。这主要是通过数据库触发器维护版本信息时带来的内部成本所致。在我们的测试中，触发器不仅造成额外的处理成本，而且还会造成一定的附加延迟，因为它们与应用程序是同步的。还应注意，这里显示的测试是在 z/OS 环境下的 DB2 中进行的。与触发器相关的成本要少于在 DB2/UDB 上的成本，这一点可以通过测量得知。还需记住的是，这种工作负载非常夸张（只有 INSERT），因此对于大多数常见的同时也会读取数据和处理数据的客户工作负载来说，延迟被夸大了很多。此外，允许不同系统上的应用程序并发地操作数据复制品可以为用户全面提高生产率、数据可用性和吞吐率。 回页首 这些结果是否适合其他工作负载和配置？ 在以往进行的所有性能测试当中，随着工作负载和配置的不同，得到的结果会有很大的变化。您可能想知道，那些因素对于您对 Q 复制的中意程度会有怎样的影响。下面是关于这些因素的影响力的考虑： 吞吐率 在本文中，我们一直选择以每秒复制的行数来度量复制。当然还有其他一些度量指标，例如每秒的事务数，但是由于事务的复杂性变化多端，我们避免使用那个度量指标作为通用的吞吐率度量。然而，事务的复杂性的确会影响每秒复制的行数。如前所述，大多数这方面的测试都使用在某些方面走极端（只有 INSERT），但在其他方面较为合理的工作负载：每个事务涉及 10 行，每个行 212 字节，并且共有 14 列。 图 9 表明，改变这些参数将影响吞吐率（每秒的行数）。这个图展示了当每个事务的行数变化时（从 2 行/每个事务到至多 20 行/每个事务）取得的吞吐率，以及当行的规模变化时（从 192 字节到 2K 字节）取得的吞吐率。从这个图中可以看出，当每个事务的行数增加时，每秒复制的行数也随之增加。其原因是，复制需要开销来处理每个行，另外还要开销来处理每个事务。每秒有更多的事务意味着提交点更少了，因此开销也就更小了。同样，复制更多的数据（更大的行规模）会造成更大的工作量，并会减少每秒复制的行数。 图 9. Q Capture 的吞吐率与行和事务的规模 延迟 在本文中，我们展示了一些很好的性能结果，在某些情况下，延迟甚至低于 1 秒。虽然在通过精心优化的环境中，可以获得这样的结果，但还有一些因素很可能会使复制的真正延迟大于前面得到的值。这些因素包括： 更复杂的事务（例如每个事务有成千个行）。我们将延迟（和 Q 复制的度量）定义为事务延迟，即从在源系统上提交一个数据库事务到该事务在目标系统上完成提交这之间的时间。这个过程只有在源事务被提交之后才可以开始。非常大的事务会有更多的工作量，需要更长的时间来处理。 更大的行规模。 UPDATE 事务。与 INSERT 相比，数据库管理系统必须对 UPDATE 做更多的工作，例如检索相关的行。 更远的网络距离（广域网）(6)。 数据共享。Q replicaiton 必须检索和处理多个日志文件。 有关这些监控功能的更多信息，以及其他性能调优方面的信息，请参阅在后面参考资料一节中列出的资料。 图 10. 带有 4 路数据共享的一个例子 当然，有很多因素可能影响性能预期。结果在很大程度上取决于工作负载和配置的变化。虽然次秒级（sub-second）的延迟是可能达到的，但也无法保证。根据现今技术的标准，低于 5 秒的复制延迟仍然可以看作是突出情况，并且在大多数常见的 Q 复制场景中都是可以达到的。 回页首 工作负载和配置 本文中给出的测试是由硅谷实验室 WebSphere Information Integration 的性能分析小组在 Q 复制的产品开发期间进行的。有些测试是在采用尚未普遍可用的产品代码级的情况下进行的。 测试人员有意地使工作负载对 Q 复制施加尽可能大的压力，同时减少硬件资源。因此，大多数测试只包含数据库 INSERT。（由于现实情况下工作负载同时还会包含应用程序处理和 SELECT，因此，用于这种 INSERT 工作负载的复制部分所消耗的资源可能远远多于客户预计在类似系统上需要消耗的资源。） 对于 z/OS 测试，配置由下面各部分组成： 系统：一个 2064-216 z900 大型主机的两个 LPAR。除非特别标明，每个 LPAR 由 4 个处理器组成，并有 8 GB 的内存。每个处理器大约相当于一个 200MIP 的机器（总共 800 MIP）。 软件： DB2 for z/OS V7 MQ 5.3.1 这些测试是在使用一个分成两个 LPAR 的 2064-216 大型主机的情况下进行的，其中每个 LPAR 使用 4 个处理器。 网络：LPAR 之间采用 1 Gb OSA 的网卡（以太网）。 磁盘：Enterprise Storage Server Model 800。   对于 AIX 测试，配置由以下部分组成： 系统：一个 IBM pSeries model p690 的两个 LPAR。每个 LPAR 由 8 个处理器、8GB 的内存组成。 网卡：10/100 Mbit Ethernet。 软件：AIX 5.2，MQ 5.3，DB2 V8.2。 磁盘：带有快速写缓存的 SSA 磁盘。 回页首 性能监控和性能调优 虽然对于一个产品来说，取得良好的性能十分重要，但对于一个分析师而言，能够对性能进行监控同样具有重要意义。Q 复制提供了一些有用的功能，这些功能目前在 SQL 复制中是没有的。也许最关键的是，现在可以测量 Q 复制取得的端到端事务的延迟。Replication Center 提供了对 Q Capture 和 Q Apply 的报告，其中包括以下度量指标： 复制吞吐率。 复制延迟。这包括对端到端总延迟的度量，以及各个部分的延迟的度量。 内存使用情况。 其他异常情况。   此外，性能统计信息是在监控表（CAPMON、CAPQMON 和 APPLYMON）中维护的，其他监控软件可以查询这些表。 在参考资料一节中可以找到有关这些监控功能的更多信息，以及大量其他性能调优方面的信息。 回页首 结束语 我们相信，Q 复制使数据库复制技术有了显著的进步，某些方面要强于 SQL 复制。在一个测试环境中，我们发现： 与 SQL 复制相比，复制吞吐率提高到了三倍，并且复制延迟也更好。 Q 复制达到了每秒复制超过 12,000 行这样的吞吐率，同时还能保证延迟持续低于 5 秒，并且在很多情况下低于 1 秒。 Q 复制所需的总处理器周期变得更少，并且在源服务器上大大节省了处理器周期。   这些性能上的提高，以及其他功能上的增强，使您可以更好地利用数据库复制来满足您的业务需要。 回页首 致谢 Q 复制开发和性能小组的很多成员都为本文中的材料作出了贡献，他们是 John Aschoff、Nhut Bui、Ying Chang、Nguyen Dao 和 Beth Hamel。如果您对于本文有什么疑问和评论，可以发送邮件给 John Aschoff（[e-mail]）。 回页首 脚注 (1) MIPS = Million Instructions per Second（每秒的百万指令数），这是用于评价大型主机处理器的相对速度的粗略方法。在这些实验中用到的 4 个处理器中，每个处理器的速度大约是 200 MIPS。MIPS 是对相对速度的非常粗略的度量方法。 (2) 这里用于计算每行所需微秒数的技术，以观察到的每行所需的总处理器时间在组成该系统的 4 个处理器上分摊得到的时间为依据。该技术的优点在于，它可以捕捉所有花费的时间，但缺点是当对处理器的使用量比较少时，由于“低使用量的影响”，它可能会有些夸张。在 Q 捕获方面，每行被扣除掉了 100 微秒，因为这是在没有复制的纯 INSERT 工作负载的情况下观察到的成本。所需的 MIPS 数严格地以观察这种 200 MIPS 处理器得到的一组结果为依据。 (3) 本文中大多数其他的 z/OS 测试都使用 4-处理器的 LPAR。 (4) 这种工作负载配置不是为发现最大吞吐率而设计的，而是为了可以通过相同的工作负载需求来比较各种不同的方案。结果，我们有意地在事务之间引入了一个较短的延迟（9 微秒）。 (5) 在计算每行的成本时，我们将 CPU 成本除以每个系统上捕捉到的并被应用的总行数。 (6) 光和电也只能那么快！ 回页首 免责声明 本文包含的信息是在“现状”的基础上提供的，没有经过任何形式的 IBM 测试。该信息的使用或这些技术的实现是用户的责任，可以依靠用户的能力进行评估，并将其集成到客户特有的操作环境中。虽然 IBM 已经在特定情况下检查了每一项的准确性，但不保证在其他地方将获得相同或相似的结果。尝试调整这些技术以适应自己环境的用户必须自担风险。 本文显示的性能信息数据基于一个测试环境中所获得的结果。受各种因素的影响，各项结果和性能可能有所变化。有关本文中使用的工作负载和配置的更多信息，可以在“工作负载和配置”一节中找到。 参考资料 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。 DB2 Information Integrator Tuning for Replication and Event Publishing Performance (SC18-9289-00) DB2 Information Integrator Replication and Event Publishing Guide and Reference (SC18-7568-00) DB2 Information Integrator Introduction to Replication and Event Publishing (GC18-7567-00) 要了解关于 WebSphere Information Integrator 的更多信息，请访问 developerWorks 上的 Websphere Information Integrator 页面。您可以从中发现技术性文章、各种文档和下载的链接以及更多内容。 关于作者 John Aschoff 目前是 WebSphere Information Integration Performance 部门的经理。他在 IBM 工作了 34 年，在存储和数据管理领域的性能方面有 20 多年的经验。他发表了大量性能方面的文章，包括为 Computer Measurement Group 发表的一些文章。他和妻子 Marcy 居住在 Monterey Bay 地区，家里还有一条唤作 Dante 的德国牧羊狗