[Spring] Querydsl Bulk Update 성능 개선

일괄 업데이트 최적화에 대해 방식에 대해서 글을 정리해보고자 한다.

JPA 사용하다 보면 더티 체킹(Dirty Checking)을 많이 사용하게 된다. 더티 체킹에 대해서 궁금하면 이 전 포스팅 글을 한번 읽어보는 것을 추천한다. 간단하게 설명하자면 조회된 엔티티의 변경 사항을 자동으로 데이터베이스에 반영해주는 기능이다.

1000건 ~ 10000 건등의 대량의 엔티티의 변경을 해야 한다면 해당 엔티티들을 조회해서 엔티티의 값을 변경하는 방식으로 개발이 될 것이다. 이러한 방식은 성능을 저하시키는 악영향을 끼치게 된다.

테스트 코드와 성능을 비교해보자.

license 1000건의 엔티티를 조회해서 name을 업데이트하는 방식으로 테스트 진행해보자.

1. Dirty Checking 방식

@Transactional
public void bulkUpdateWithDirtyChecking(String name) {
    List<License> shopList = jpaQueryFactory
        .selectFrom(license)
        .where(license.id.loe(1000))
        .fetch();

    for(License license : shopList) {
        license.setName(name);
    }
}

2. Querydsl bulk update

@Transactional
public void bulkUpdate(String name) {
    jpaQueryFactory
        .update(license)
        .where(license.id.loe(1000))
        .set(license.name, name)
        .execute();
}

1번 더티 체킹 방식은 1000건 엔티티의 name 업데이트가 2 sec 838ms의 시간이 소요되었고

2번 Querydsl Update 방식은 동일하게 1000건 엔티티의 name을 업데이트했더니 467ms의 시간이 소요되었다.

테스트 기준을 1000건으로 잡은 케이스고 만 건, 십만 건, 백만 건 등 대량 데이터의 업데이트면 차이는 엄청나게 커질 것이다.

개인적인 의견

더티 체킹 방식은 단건 처리나 실시간 비즈니스 엔티티 데이터 처리할 때 사용하는 것이 효율적인 것 같고

Querydsl update 방식은 대량의 데이터를 일괄 업데이트 처리가 필요할 때 사용하는 것이 효율적인 것 같다.

사실 객체지향을 핑계로 성능을 등한시하게 되는데 (나 편하자고...) 무분별한 더티 체킹이 발생하고 있는지 없는지 확인하는 버릇을 들이자.