首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

什么因素影响数据库同步效率

数据库之间数据同步的工具有不少,这里以IBM的CDC为例,介绍影响数据库SQL语句同步性能的一些因素。

数据库的同步是将增删改这样的SQL语句发送到目标端,然后插入目标端的数据库。因此,性能受到源端、传输带宽、传输软件、目标端的共同影响。

本人对数据库同步工具的内部机制并不了解,事实上,也只有同步工具的coder才知道算法是什么,例如,源端的SQL语句如何抽取、组合、打包、在多个进程分派、在目标端如何解包、何时插入等等。这里仅仅是从实际工作中遇到的一些常见的、和用户相关的因素说起。

数据库同步的性能指标是RPS(row per second),即每秒同步多少行SQL语句。另外,从用户角度还有一个指标-同步的延迟时间(源端发生的SQL需要多久才能同步到目标端),但这个指标其实上是RPS的一个附属指标。RPS高了自然不会有什么延迟;RPS低,同时业务对数据库的增删改的量特别大,自然就会延迟很高。

RPS是每秒增删改SQL的数量,那么这些SQL对应的是多少笔业务,是需要提前知晓的。以便测试同步效率、同步速度后,进行业务量的换算。

那么一个业务到底有多少增删改SQL呢?一种方法是问问开发人员,或者看看代码,但这种方式靠谱的概率极低。第二种方法就是实际测试,最好是大批量发送单类型的业务,业务处理了多少是知道的,各类SQL语句数量在数据库的报告里面也可以看到。这样计算的才是比较精确的。

一、 源端

同步工具读取数据库的增删改SQL语句,主要是从redo日志里面读取,这里说“主要”并不是说“全部”。因为有时会发现,CDC对于lob字段的表会从数据库里面通过select语句读取,这样lob字段的表的同步速度就大大降低了。

另外redo日志本身有buffer中的活动日志、磁盘中的活动日志、以及归档空间中的归档日志。所以,同步工具也会按照这个顺序去读日志,如果buffer里面有,自然不会去磁盘里面读。如果去磁盘读,那么磁盘/存储本身的性能、RAID划分方式也会有一定的影响。

同步软件有时还需要源端数据库的参数满足一定要求,比如CDC要求源端的Oracle RAC开启DTP开关(并行处理开关),在实测过程中,DTP开关与否也的确对RPS影响很大。然而,Oracle官方声明中很早就弃用了DTP开关,IBM的CDC工具却仍然去识别这个参数,并且对性能造成影响实在匪夷所思。

源端小结:主要是读redo的buffer,或者redo日志的磁盘(个别情况读取数据库),数据同步对源端的CPU等资源消耗并不大,但源端由于各种因素很有可能拖累整体同步的速度。

二、 带宽

这个就不用多说了

三、 同步软件

版本、各种参数、订阅数量等等各类配置都会影响同步效率。这里我们举一些测试实例。

1. 版本的影响

不同版本实测

2. 参数的影响

举例1:By hash VS by table

咱们分别来解释,先说By Table:把增删改的数据库操作并行地通过多个数据库连接,同步到目标端的方式,并且是按照table来把各种数据库操作分配到这多个连接上。但这种分配并不是在每个数据库连接上做负载均衡。

举例说明,有两个数据库连接,和以下数据库操作

INSERT TABLE1

INSERT TABLE2

UPDATE TABLE1

INSERT TABLE3

INSERT TABLE2

INSERT TABLE3

数据库连接1:

INSERT TABLE1

UPDATE TABLE1

INSERT TABLE3

INSERT TABLE3

数据库连接2:

INSERT TABLE2

INSERT TABLE2

而By Hash呢,是用Hash的方法把增删改操作map到不同的数据库连接上去。

By table和By Hash这两种配置方法在不同的数据库操作模式下,性能会各有优劣。因此需通过实际的测试来决定采用哪种方式,下面是一个实测的例子。

举例2:fast apply

Fast apply也是一个重要的参数。先来说说Fast apply是个什么(虽然我也说不清楚,并且问过所有IBM现场支持CDC的工程师,没有一个人能说清楚)

CDC会将增删改这样的数据库操作打包为一个事务组“unit of work”向目标端发送。每个包有个最大的大小限制(记做M)。之前我们提到的开多个数据库连接,这个数量记做N。

于是就有了一个参数配置N:M,叫做Fast Apply。

例如12:15000是开12个数据库连接(也就是12个线程一起传输),每个包最多塞15000个SQL就发送了(当然也不是一定塞满15000)。当CDC觉得延迟有增大的时候,会增加并行的包的数量,以增大吞吐量;当延迟不大的时候,会减少并行的包的数量,这样会进一步减少延迟(毕竟凑够1个包和凑够10个包的时间是不一样的)。

我们固定了其他的参数,只变动Fast Apply看看效果。

需要说明的是,在不同的数据库操作模式下、不同的环境配置下,通过实际的测试来决定采用的具体参数值。

3. 开关日志的影响

CDC是否写自己的XA日志,对性能有很大的影响,我们的测试中,某个场景下,不写日志可以让RPS从3000提高到5000.

四、目标端

1. 资源:

数据库同步主要消耗目标的资源(CPU、内存),这也不难理解,因为目标端需要做解包、整理、数据库的插入动作。

这里举一个例子:CDC在目标端分配的内存

2. 目标端参数

举一个触发器的例子,其他参数固定,关闭目标端触发器

3. 库表结构设计

同步的SQL语句最终是要落到目标端数据库里面的,那么目标端数据库的索引等库表结果设计、存量数据会对SQL的执行起到很大的性能影响。

下表是某目标库结构变更前后SQL执行时间及RPS的变化率如下:

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180108G0K17E00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券