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

数据库之间数据同步的工具有不少，这里以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的变化率如下：