[Spring Batch] ItemReader cursor vs paging

1. 개요

이전 프로젝트에서 일괄적으로 알림을 보내는 기능을 개발했었는데 기능 구현을 위해 스프링 배치를 학습했었다. 그때도 ItemReader의 종류가 여러가지 있는 건 알았지만 우선 아무거나 선택해 구현했었는데 이번 기회에 제대로 알아보려고 한다. 

 

 

 

2. Spring Batch Chunk?

Spring Batch에서 일괄 처리를 하는 방법은 크게 두가지가 있다. 바로 Tasklet 기반과 Chunk 기반인데 ItemReader은 Chunk 방식에서 사용되는 것이다. ItemReader에 학습하기 앞서 Chunk에 대해 가볍게 알아보자. 

 

Spring Batch에서의 Chunk란 데이터 덩어리로 작업 할 때 각 커밋 사이에 처리되는 row 수를 얘기한다.

 

즉, Chunk 지향 처리란 한 번에 하나씩 데이터를 읽어 Chunk라는 덩어리를 만든 뒤, Chunk 단위로 트랜잭션을 다루는 것을 의미한다.

 

여기서 트랜잭션이라는게 중요한데, Chunk 단위로 트랜잭션을 수행하기 때문에 실패할 경우엔 해당 Chunk 만큼만 롤백이 되고, 이전에 커밋된 트랜잭션 범위까지는 반영이 된다.

 

Chunk 지향 처리가 결국 Chunk 단위로 데이터를 처리한다는 의미이기 때문에 그림으로 표현하면 아래와 같다.

 

 

위 작업에서 read() 작업을 수행하는 게 ItemReader 이다. 

 

Spring Batch의 ItemReader는 꼭 DB의 데이터만이 아닌 File, XML, Json등 다른 데이터 소스를 배치 처리의 입력으로도 사용할 수 있다. 

 

 

 

 

3. Spring Batch의 대표적인 Reader

Spring Batch는 대표적으로 2개의 Reader 타입을 지원한다.

 

 

 

Cursor 형식 

Database와 커넥션을 맺은 후 데이터를 Streaming 해서 보낸다. 그리고 Cursor를 한 칸씩 옮기면서 데이터를 가져온다. 

 

하나의 Connection으로 Batch가 끝날 때까지 사용되기 때문에 Batch가 끝나기 전에 Database와 애플리케이션의 Connection이 먼저 끊어질 수 있어서 위험하다. 모든 데이터를 메모리에 저장하기 때문에 메모리 사용량이 많습니다. 

 

Paging 

반면 Paging은 좀 더 많은 작업이 필요로 한다.

Paging 개념은 페이지라는 Chunk로 Database에서 데이터를 검색한다. 즉, 페이지 단위로 데이터를 한 번에 조회해오는 방식인데, 페이지 단위로 DB Connection을 맺기 때문에 연결 시간이 상대적으로 적은 편이다. 또한 페이징 단위의 결과만 메모리에 저장하기 때문에 상대적으로 메모리 사용량이 적다.

 

주의사항으로 Paging을 사용할 것이라면 데이터가 정렬이 되어있어야 한다.

 

게시판의 페이징을 구현해보면 알겠지만 페이징을 한다는 것은 각 쿼리에 시작 행 번호 (offset) 와 페이지에서 반환 할 행 수 (limit)를 지정해야한다는 것을 의미한다. Spring Batch에서는 offset과 limit을 PageSize에 맞게 자동으로 생성해 준다.

 

다만 각 쿼리는 개별적으로 실행한다는 점을 유의해야한다. 각 페이지마다 새로운 쿼리를 실행하므로 페이징시 결과를 정렬하는 것이 중요하다. 

 

 

Cursor, Paging 기반의 동작 방식

 

 

 

 

4. JdbcPagingItemReader

JdbcPagingItemRedaer는 JdbcCursorItemReader와 같은 JdbcTemplate 인터페이스를 이용한 PagingItemReader이다. 예제 코드는 아래와 같다.

// Cursor 기반 ItemReader 구현체
@Bean
public JdbcCursorItemReader<Schedule> allReadReader() {
    return new JdbcCursorItemReaderBuilder<Schedule>()
            .verifyCursorPosition(false)
            .fetchSize(FETCH_SIZE)
            .dataSource(dataSource)
            .rowMapper(new BeanPropertyRowMapper<>(Schedule.class))
            .sql("select * from schedules order by id")
            .name("jdbcCursorItemReader")
            .build();
}
// Paging 기반 ItemReader 구현체
@Bean
public JdbcPagingItemReader<Schedule> allReadPagingReader(
        PagingQueryProvider queryProvider) {
    return new JdbcPagingItemReaderBuilder<Schedule>()
            .pageSize(CHUNK_SIZE)
            .fetchSize(FETCH_SIZE)
            .dataSource(dataSource)
            .rowMapper(new BeanPropertyRowMapper<>(Schedule.class))
            .queryProvider(queryProvider)
            .name("jdbcCursorItemReader")
            .build();
}

@Bean
public PagingQueryProvider queryProvider() throws Exception {
    SqlPagingQueryProviderFactoryBean queryProvider = new SqlPagingQueryProviderFactoryBean();
    queryProvider.setDataSource(dataSource);
    queryProvider.setSelectClause("*");
    queryProvider.setFromClause("from schedules");

    Map<String, Order> sortKeys = new HashMap<>(1);
    sortKeys.put("id", Order.ASCENDING);

    queryProvider.setSortKeys(sortKeys);
    return queryProvider.getObject();
}

 

JdbcPagingItemReader 과 JdbcCursorItemReader 의 가장 큰 차이점은 쿼리를 날리는 방식이다. Paging 방식에선 queryProvider 를 사용하여 쿼리를 생성한다. 

 

이는 각 DB에서 Paging을 지원하는 자체적인 전략들이 다르기 때문이다. 

 

각 DB의 Paging 전략에 맞춘 Provider는 아래와 같다.

 

Spring batch에선 SqlPagingQueryProviderFactoryBean을 통해 Datasource 설정값을 보고 위 이미지에서 작성된 Provider중 하나를 자동으로 선택한다. 

 

 

 

 

 

5. JpaPagingItemReader

결과적으로 내 선택은 JpapagingItemReader 이다.

AWS EC2에 배포해두고 작은 메모리 스펙을 가진 환경에 서 서버가 돌고 있었기 때문에 대용량 데이터를 처리할 땐 성능이 떨어질 수 있지만, DB커넥션을 짧게 유지하고 안정적인 Paging 방식을 택했고, JPA를 사용중이었기 때문에 JpapagingItemReader 를 선택했다. 

 

JpapagingItemReader 로 Item을 읽어드리는 간단한 예제 코드이다. 

@Bean
public ItemReader<Apply> applyReader() {
    LocalDate tomorrow = LocalDate.now().plusDays(1);
    return new RepositoryItemReaderBuilder<Apply>()
            .name("applyReader")
            .repository(applyRepository)
            .methodName("findNeedToCancel")
            .pageSize(CHUNK_SIZE)
            .arguments(List.of(tomorrow))
            .sorts(Collections.singletonMap("id", Sort.Direction.ASC)) // 필수
            .build();
}

 

위에서도 언급했듯이 정렬은 무조건 포함되어야 한다. 

대량의 데이터를 정렬하려면 full scan이 일어나기 때문에 pk를 기준으로 정렬하여 성능에 지장이 가지 않도록 코드를 작성하였다. 

 

 

 

6. JPAPagingItemReader -  RepositoryItemReaderBuilder 사용 시 주의사항

JPAPagingItemReader를 사용하기 위해선 몇 가지 주의해야 할 부분들이 있다. 

 

1. Hibernate, JPA 등 영속성 컨텍스트가 필요한 Reader 사용시 fetchSize와 ChunkSize는 같은 값을 유지해  야 한다.

 

2. Pagepable을 꼭 넣어주어야 한다. 당연히 Paging을 사용해서 읽어오기 때문에 Paging을 파라미터로 잡아주지 않으면 에러가 뜬다.

 

3. 2번과 비슷하게 반환 타입은 Page여야 한다. List로 설정할 시 에러가 뜬다.

 

4. where 조건 문에 들어가는 필드의 값이 바뀔 경우 데이터 누락 현상이 발생할 수 있다. 이 부분은 내용이 길어져 아래 글에서 다루었다. 

https://dgjinsu.tistory.com/47

[Spring Batch] Paging 기반의 ItemReader 사용 시 발생하는 데이터 건너뛰기 현상