随着 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 就是为满足这些性能需求而设计的,此外,它还增加了一些功能,提高了可管理性。 系统在规模上不断增长,打破了吞吐率的限制。与此同时,客户需要更多地实时访问被复制的更改。这些实时更改操作常常需要朝多个方向流动,因此造成对同步两个或更多系统的需要,以及当这些系统并发地更改相同数据时解决冲突问题的需要。 客户对于数据库复制有很多方面的需要,数据库复制这个过程常常需要谨慎地计划和调度。下面是数据库复制的一些传统用法和未来的趋势:
从下面的图 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 节比较了这几种方法的性能。
下面的 图 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 复制的性能,其中包括: 减少 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 消耗:
图 4. 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 和资源消耗的影响 ![]() 下面是从这两个图中观察到的一些方面:
在以往进行的所有性能测试当中,随着工作负载和配置的不同,得到的结果会有很大的变化。您可能想知道,那些因素对于您对 Q 复制的中意程度会有怎样的影响。下面是关于这些因素的影响力的考虑: 吞吐率 在本文中,我们一直选择以每秒复制的行数来度量复制。当然还有其他一些度量指标,例如每秒的事务数,但是由于事务的复杂性变化多端,我们避免使用那个度量指标作为通用的吞吐率度量。然而,事务的复杂性的确会影响每秒复制的行数。如前所述,大多数这方面的测试都使用在某些方面走极端(只有 INSERT),但在其他方面较为合理的工作负载:每个事务涉及 10 行,每个行 212 字节,并且共有 14 列。 图 9 表明,改变这些参数将影响吞吐率(每秒的行数)。这个图展示了当每个事务的行数变化时(从 2 行/每个事务到至多 20 行/每个事务)取得的吞吐率,以及当行的规模变化时(从 192 字节到 2K 字节)取得的吞吐率。从这个图中可以看出,当每个事务的行数增加时,每秒复制的行数也随之增加。其原因是,复制需要开销来处理每个行,另外还要开销来处理每个事务。每秒有更多的事务意味着提交点更少了,因此开销也就更小了。同样,复制更多的数据(更大的行规模)会造成更大的工作量,并会减少每秒复制的行数。 图 9. Q Capture 的吞吐率与行和事务的规模 ![]() 延迟 在本文中,我们展示了一些很好的性能结果,在某些情况下,延迟甚至低于 1 秒。虽然在通过精心优化的环境中,可以获得这样的结果,但还有一些因素很可能会使复制的真正延迟大于前面得到的值。这些因素包括:
有关这些监控功能的更多信息,以及其他性能调优方面的信息,请参阅在后面参考资料一节中列出的资料。 图 10. 带有 4 路数据共享的一个例子 ![]() 当然,有很多因素可能影响性能预期。结果在很大程度上取决于工作负载和配置的变化。虽然次秒级(sub-second)的延迟是可能达到的,但也无法保证。根据现今技术的标准,低于 5 秒的复制延迟仍然可以看作是突出情况,并且在大多数常见的 Q 复制场景中都是可以达到的。
本文中给出的测试是由硅谷实验室 WebSphere Information Integration 的性能分析小组在 Q 复制的产品开发期间进行的。有些测试是在采用尚未普遍可用的产品代码级的情况下进行的。 测试人员有意地使工作负载对 Q 复制施加尽可能大的压力,同时减少硬件资源。因此,大多数测试只包含数据库 INSERT。(由于现实情况下工作负载同时还会包含应用程序处理和 SELECT,因此,用于这种 INSERT 工作负载的复制部分所消耗的资源可能远远多于客户预计在类似系统上需要消耗的资源。) 对于 z/OS 测试,配置由下面各部分组成:
对于 AIX 测试,配置由以下部分组成:
虽然对于一个产品来说,取得良好的性能十分重要,但对于一个分析师而言,能够对性能进行监控同样具有重要意义。Q 复制提供了一些有用的功能,这些功能目前在 SQL 复制中是没有的。也许最关键的是,现在可以测量 Q 复制取得的端到端事务的延迟。Replication Center 提供了对 Q Capture 和 Q Apply 的报告,其中包括以下度量指标:
此外,性能统计信息是在监控表(CAPMON、CAPQMON 和 APPLYMON)中维护的,其他监控软件可以查询这些表。 在参考资料一节中可以找到有关这些监控功能的更多信息,以及大量其他性能调优方面的信息。
我们相信,Q 复制使数据库复制技术有了显著的进步,某些方面要强于 SQL 复制。在一个测试环境中,我们发现:
这些性能上的提高,以及其他功能上的增强,使您可以更好地利用数据库复制来满足您的业务需要。
Q 复制开发和性能小组的很多成员都为本文中的材料作出了贡献,他们是 John Aschoff、Nhut Bui、Ying Chang、Nguyen Dao 和 Beth Hamel。如果您对于本文有什么疑问和评论,可以发送邮件给 John Aschoff(aschoffj@us.ibm.com)。
(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 已经在特定情况下检查了每一项的准确性,但不保证在其他地方将获得相同或相似的结果。尝试调整这些技术以适应自己环境的用户必须自担风险。 本文显示的性能信息数据基于一个测试环境中所获得的结果。受各种因素的影响,各项结果和性能可能有所变化。有关本文中使用的工作负载和配置的更多信息,可以在“工作负载和配置”一节中找到。
|
联系客服