spring batch数据迁移时chunk size设置的问题

背景信息

从一个数据库向另一个数据库迁移数据

migrate的实现使用了spring batch，通过分页的reader读数据，分页大小为500，每一个step的chunk size设置为了500，定义大致如下:

.listener(new BPStepListener(tenant))
                .transactionManager(new DataSourceTransactionManager(detinationDataSource))
                .<Map<String, Object>, Map<String, Object>>chunk(500)
                .reader(buildItemReader(dataSource, table, tenant))
                .processor(new CustomItemProcessor())
                .writer(buildItemWriter(detinationDataSource, table, targetNameSpace))
                .faultTolerant().skip(DuplicateKeyException.class).skipLimit(10)
                .build();

在这个step定义当中chunk size设置为了500,也就意味着每读取，处理500条数据会向目标数据库写一次数据，即进行一次数据库提交。

上面是spring batch的使用背景信息.

遇到的问题

遇到的问题是数据量特别大时的效率问题。

当源数据库的数据量不大的时候，具体来说，每一个step处理的数据不超过200万之前，效率都很不错，对于一张超过200万数据的表，花的时间大概在8分钟左右就全部迁移完成。

但是当数据量达到300多万之后，发现效率急剧下降，一次数据迁移耗时多达4个小时以上。

分析及解决方案

按理说300万的数据是200万的1.5倍左右，那么花的时间为什么会相差这么多，这一点让我非常困惑。经过自己分析觉得可能的原因应该如下:

• 数据库有主键的约束，当数据量非常大的时候，每次插入一条记录都需要校验大量的数据
• 每次提交500条数据，当数据量非常大的时候，提交的次数会非常多，开销很高。

第二点原因看上去有点不靠谱，因为当有200万数据的时候，一样的配置只跑了8分钟。但是博主还是尝试了一下，将chunk size改为了1000，即1000条数据向数据库提交一次。结果发现执行果然变快了，而且快了非常多，从四个半小时变为了两个半小时左右。

{
    "table": "xxx",
    "jobStatus": "COMPLETED",
    "jobStartTime": "2019-06-11T10:36:26.538+0000",
    "jobEndTime": "2019-06-11T12:59:15.559+0000"
}

因此执行的速度和我们提交数是由关系的。spring batch通过设置chunk size来指定commit Interval.

如果chunk size设置成了1，则每个item都进行提交。 在大多数情况下这样设置是不好的，因为开始和提交transaction的成本非常高。 理想情况下，最好在每个transaction中处理尽可能多的数据。 因此，spring batch当中可以配置每次commit的数据。下面是一个例子：

@Bean
public Step step1() {
        return this.stepBuilderFactory.get("step1")
                                .<String, String>chunk(10)
                                .reader(itemReader())
                                .writer(itemWriter())
                                .build();
}

上面的例子当中每个事务中处理10条数据。 在处理开始时，开始transaction。 每次在ItemReader上调用read时，计数器都会递增， 当它达到10的时候，这10条数据的list就传递给ItemWriter，并提交事务。

因此，在内存不受太大影响的情况下，处理大量数据时，提高commit interval是提高执行效率的一个有效的方法。但是值得一提的是，若没有大量的数据迁移需求，则增大chunk size并不会提高效率。