[JPA] deleteAll(), deleteAllInBatch(), deleteInBatch() 정리

개요

Hibernate(JPA)에서는 레코드를 삭제할 수 있는 아래의 다양한 메서드들을 지원한다.

• delete(),deleteById()
• deleteAll(), deleteAllById()
• deleteInBatch()
• deleteAllInBatch(), deleteAllByIdInBatch()

다양한 메서드를 제공하는 것은 좋지만, 네이밍만 보고 혼란스러운 것들이 몇몇 있다. 대표적으로 deleteInBatch()와 deleteAllInBatch(), 그리고 deleteAll()과 deleteAllInBatch()와 같은 메서드들이다.

이번 게시글에서는 위 메서드들이 실제로 어떻게 삭제를 처리하는지를 살펴볼 것이고, 연관관계가 없는 경우와 연관관계가 있는 경우로 나누어 삭제 동작을 분석해 볼 것이다.

 

 

사전 세팅

DB는 MySQL을 사용했으며, MySQL에서 배치 삭제를 효율적으로 처리하기 위해서는 다음과 같은 JDBC URL이 필요하다.

jdbc:mysql:localhost:3306/db
?cachePreStmts=true
&useServerPrepStmts=true
&rewriteBatchedStatements=true

각 설정에 대한 간단한 설명은 다음과 같다.

• cachePrepStmts: PreparedStatement의 캐싱을 활성화한다. cachePrepStmts=true로 설정하면, 동일한 쿼리를 반복적으로 실행할 때 성능이 향상된다. 이 캐시는 prepStmtCacheSize 및 prepStmtCacheSqlLimit과 함께 작동하여, 캐시 할 PreparedStatement의 수와 SQL 문장의 최대 길이를 설정할 수 있다.
• useServerPrepStmts: 서버 측에서 PreparedStatement를 사용하도록 설정한다. MySQL은 기본적으로 클라이언트 측에서 PreparedStatement를 처리하지만, useServerPrepStmts=true로 설정하면 서버에서 PreparedStatement를 관리하게 되어, 서버의 리소스를 활용한 효율적인 쿼리 처리가 가능해진다.
• rewriteBatchedStatements: 이 속성이 활성화되면, 여러 개의 SQL 문을 하나의 문자열 버퍼로 재작성하여 하나의 요청으로 데이터베이스에 전한다. 이를 통해 배치 작업의 성능이 크게 향상될 수 있다.

여기서 특히 rewriteBatchedStatements 속성을 활성화하면, 여러 SQL 문이 하나의 문자열 버퍼로 재작성되어 데이터베이스에 대한 하나의 요청으로 전송되는데, 이 설정의 활성화 여부에 따라 쿼리문은 다음과 같이 달라지게 된다.

-- rewriteBatchedStatements = false
insert into author (name, id) values ('Jane Austen', 1);
insert into author (name, id) values ('Nathaniel Hawthorne', 2);
...
 
-- rewriteBatchedStatements = true
insert into author (name, id) values ('Jane Austen', 1), ('Nathaniel Hawthorne', 2), ...;

추가로 배치 크기를 설정하려면 spring.jpa.properties.hibernate.jdbc.batch_size 속성을 사용하고, 버전을 가진 엔티티의 경우 spring.jpa.properties.hibernate.jdbc.batch_versioned_data=true로 지정하여 처리할 수 있다.

 

 

연관관계가 없는 경우

다음과 같이 연관관계가 없는 간단한 엔티티를 사용하여 1,000개의 데이터를 가지고 테스트를 진행했다.

@Entity
@NoArgsConstructor(access = lombok.AccessLevel.PROTECTED)
public class Author {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    private String name;
}
...

SET @i = 1;
WHILE @i <= 1000 DO
    INSERT INTO author (name) VALUES (CONCAT('Author ', @i));
    SET @i = @i + 1;
END WHILE;

 

1. deleteAllInBatch() 삭제

• 엔티티를 받는 경우: SimpleJpaRepository.java#L274
• 엔티티를 받지 않는 경우: SimpleJpaRepository.java#L298

@Transactional
public void deleteAuthorsDeleteAllInBatch() {
    authorRepository.deleteAllInBatch();
}

delete a1_0 from author a1_0

간단하게 하나의 DELETE 쿼리를 통해 데이터를 한 번에 삭제하며, 벌크 작업으로 처리되었다.

• 벌크(Bulk): 한 번의 쿼리로 다수의 데이터를 처리하는 방식
• 배치(Batch): 데이터를 여러 번에 나누어 처리하는 방식

일반적으로 벌크 작업은 배치 처리보다 빠르고 인덱스를 활용할 수 있는 장점이 있지만, 전이 메커니즘(cascadeType.ALL)이나 자동 애플리케이션 수준 낙관적 잠금 메커니즘(@Version)의 장점을 얻지 못하며, 엔티티에 대한 수정 사항이 영속성 컨텍스트에 자동으로 반영되지 않는다는 점도 존재한다. 예를 들어, @Version 필드를 가지는 엔티티에 대해 삭제를 진행할 경우 해당 엔티티의 버전 정보는 업데이트되지 않으며, 다른 트랜잭션에서 이 엔티티를 참조하고 있는 경우 낙관적 잠금 충돌을 감지하지 못할 수도 있다.

 

2. deleteInBatch(Iterable<T> entities) 삭제

SimpleJpaRepository.java#L298

@Transactional
public void deleteAuthorsDeleteInBatch() {
    List<Author> authors = authorRepository.findAll();
    
    authorRepository.deleteInBatch(authors);
}

delete a1_0 from author a1_0 where a1_0.id=? or a1_0.id=? or a1_0.id=? ...

일단 이 deleteInBatch() 메서드는 심각한 문제가 하나 있는데, IN 절이 아닌 OR 연산자를 사용하여 WHERE 절에 해당하는 ID들을 단순히 연결한다. MySQL 8 버전 기준으로 IN절은 500,000개의 row를 문제없이 삭제할 수 있는 반면, OR 연산자는 10,000개 이상의 행을 삭제하려고 할 때 StackOverflowError가 발생할 수 있다.

실제로 10,000개 이상의 row 삭제를 시도하자 다음과 같은 오류가 발생했다.

java.lang.StackOverflowError: null
    at org.antlr.v4.runtime.ParserRuleContext.getRuleContext(ParserRuleContext.java:277) ~[antlr4-runtime-4.13.0.jar:4.13.0]
    at org.hibernate.grammars.hql.HqlParser$OrPredicateContext.predicate(HqlParser.java:6509) ~[hibernate-core-6.5.2.Final.jar:6.5.2.Final]
    at org.hibernate.query.hql.internal.SemanticQueryBuilder.visitOrPredicate(SemanticQueryBuilder.java:2382) ~[hibernate-core-6.5.2.Final.jar:6.5.2.Final]
    at org.hibernate.query.hql.internal.SemanticQueryBuilder.visitOrPredicate(SemanticQueryBuilder.java:275) ~[hibernate-core-6.5.2.Final.jar:6.5.2.Final]
    at org.hibernate.grammars.hql.HqlParser$OrPredicateContext.accept(HqlParser.java:6523) ~[hibernate-core-6.5.2.Final.jar:6.5.2.Final]
    at org.hibernate.query.hql.internal.SemanticQueryBuilder.visitOrPredicate(SemanticQueryBuilder.java:2382) ~[hibernate-core-6.5.2.Final.jar:6.5.2.Final]
    ...

deleteAllInBatch()와 마찬가지로 deleteInBatch()도 executeUpdate()를 통해 벌크 작업을 수행한다. 따라서 모든 레코드를 삭제해야 할 때는 deleteInBatch() 대신 deleteAllInBatch()를 사용하는 것이 좋다. 다만 특정 필터링 기준에 따라 데이터를 삭제할 때는 이 방법도 자동 애플리케이션 수준 낙관적 잠금 메커니즘의 이점을 얻지 못할 수 있다는 것에 주의해야 한다.

만약 생성된 쿼리의 길이와 관련된 문제가 있는 경우, 대안으로 아래처럼 직접 IN 연산자를 사용한 쿼리를 작성하는 것도 좋은 선택이 될 수 있다.

@Modifying(flushAutomatically = true, clearAutomatically = true)
@Query("delete from Author a WHERE a IN ?1")
int deleteInBulk(List<Author> authors);

 

3. deleteAll() 삭제

• 엔티티를 받는 경우: SimpleJpaRepository.java#L263
• 엔티티를 받지 않는 경우: SimpleJpaRepository.java#L289

@Transactional
public void deleteAuthorsDeleteAll() {   
    authorRepository.deleteAll();
}

delete from author where id=?
delete from author where id=?
delete from author where id=?
...

여러 개의 반복적인 delete()가 수행되었다. 그 이유는 위에 링크된 실제 구현코드를 보면 알 수 있는데, deleteAll(Iterable <? extends T> extends) 메서드가 내부적으로 delete(T entity) 메서드를 사용하기 때문이다. 인수를 받지 않는 deleteAll() 메서드도 내부적으로 findAll()을 호출하여, 반환된 엔티티 집합을 반복하면서 각 엔티티에 대해 delete(T entity) 메서드를 호출한다. 개발자가 deleteAll()나 deleteAll(Iterable entities) 메서드 또는 delete(T entity)를 사용하는 경우 배치 처리가 사용된다.

결론적으로 모든 레코드를 삭제해야 할 경우에는 deleteAllInBatch()를 사용하는 것이 가장 좋은 방법이다. 그 외의 deleteInBatch()나 deleteAll() 사이의 결정은 각각의 메서드가 트리거하는 삭제 방식(전이 메커니즘), 성능 차이, 그리고 낙관적 잠금 메커니즘의 적용 여부들에 대해 고려해서 선택해야 한다.

 

 

연관관계가 있는 경우

다음과 같이 지연 양방향 @OneToMany 연관관계를 갖고 있다고 가정한다. 그리고 테이블은 물리적으로 FK가 걸려있다고 가정하지만, 각 내용에서 걸려있지 않은 경우에 수행되는 동작도 살펴볼 것이다.

@Entity
@NoArgsConstructor(access = lombok.AccessLevel.PROTECTED)
public class Book {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
 
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "author_id")
    private Author author;
 
    private String title;
    private String isbn;
}

@Entity
@NoArgsConstructor(access = lombok.AccessLevel.PROTECTED)
public class Author {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
 
    private String name;
    private int age;
 
    @OneToMany(cascade = CascadeType.ALL, mappedBy = "author", orphanRemoval = true)
    private List<Book> books = new ArrayList<>();
  }

SET @i = 1;
WHILE @i <= 1000 DO
    INSERT INTO author (name) VALUES (CONCAT('Author ', @i));
    SET @i = @i + 1;
END WHILE;
 
SET @author_id = 1;
WHILE @author_id <= 1000 DO
    INSERT INTO book (author_id, title, isbn) VALUES (@author_id, CONCAT('Book Title ', @author_id, '-1'), CONCAT('ISBN', @author_id, '-1'));
    INSERT INTO book (author_id, title, isbn) VALUES (@author_id, CONCAT('Book Title ', @author_id, '-2'), CONCAT('ISBN', @author_id, '-2'));
    INSERT INTO book (author_id, title, isbn) VALUES (@author_id, CONCAT('Book Title ', @author_id, '-3'), CONCAT('ISBN', @author_id, '-3'));
    INSERT INTO book (author_id, title, isbn) VALUES (@author_id, CONCAT('Book Title ', @author_id, '-4'), CONCAT('ISBN', @author_id, '-4'));
    INSERT INTO book (author_id, title, isbn) VALUES (@author_id, CONCAT('Book Title ', @author_id, '-5'), CONCAT('ISBN', @author_id, '-5'));
    
    SET @author_id = @author_id + 1;
END WHILE;

테이블 관계

저자를 삭제하면 연관된 모든 도서도 함께 삭제되어야 한다. 데이터는 저자 1,000명에 저자마다 5개의 책 데이터를 등록했다.

 

1. deleteAllInBatch() 삭제

@Transactional
public void deleteAuthorsAndBooksDeleteAllInBatch() {
    authorRepository.deleteAllInBatch();
}

delete a1_0 from author a1_0
 
java.sql.SQLIntegrityConstraintViolationException: (conn=109) Cannot delete or update a parent row: a foreign key constraint fails (`test`.`book`, CONSTRAINT `FKklnrv3weler2ftkweewlky958` FOREIGN KEY (`author_id`) REFERENCES `author` (`id`))
...

이 경우 author 테이블의 데이터를 삭제하는 DELETE 쿼리는 생성되지만, book에서 author_id를 참조하고 있기 때문에 외래 키 제약 조건으로 인해 에러가 발생했다. 이는 deleteAllInBatch()가 orphanRemoval 또는 전이(cascade)를 사용하지 않기 때문에 발생하는데, deleteAllInBatch()는 executeUpdate()를 통해 벌크 삭제를 트리거 하지만, JPA의 영속성 컨텍스트와 데이터베이스 간의 동기화는 이루어지지 않기 때문이다.

쉽게 말해 deleteAllInBatch()와 같은 벌크 연산은 JPA의 영속성 컨텍스트를 건너뛰고 직접적으로 데이터베이스에 접근해 삭제 작업을 수행하기 때문에, orphanRemoval 및 cascade 옵션이 무시된다. 이로 인해 삭제하려는 엔티티가 다른 엔티티에 의해 참조되고 있을 경우 제약 조건 오류가 발생할 수 있다.

물리적으로 테이블에 외래키가 설정되어 있지 않은 경우에는 외래 키 제약 조건 문제는 발생하지 않지만, Author 테이블의 레코드만 삭제되고 Book 테이블의 레코드는 삭제되지 않는다.

따라서 이 경우 모든 도서를 삭제하는 데 사용하는 방법은 아래와 같이 명시적으로 book도 제거하는 방법뿐이다.

// 물리적으로 FK 걸려있을 시 book 삭제가 우선
@Transactional
public void deleteAuthorsAndBooksDeleteAllInBatch() {
    bookRepository.deleteAllInBatch();
    authorRepository.deleteAllInBatch();
}
 
// 물리적으로 FK 걸려있지 않을 시 순서 상관 없음
@Transactional
public void deleteAuthorsAndBooksDeleteAllInBatch() {
    authorRepository.deleteAllInBatch();
    bookRepository.deleteAllInBatch();
}

 

2. deleteInBatch() 삭제

@Transactional
public void deleteAuthorsAndBooksDeleteInBatch() {
    List<Author> authors = authorRepository.findAll();
    
    authorRepository.deleteInBatch(authors);
}

delete a1_0 from author a1_0 where a1_0.id=? or a1_0.id=? or a1_0.id=? or a1_0.id=? or a1_0.id=? or a1_0.id=? ...
 
java.sql.SQLIntegrityConstraintViolationException: (conn=109) Cannot delete or update a parent row: a foreign key constraint fails (`test`.`book`, CONSTRAINT `FKklnrv3weler2ftkweewlky958` FOREIGN KEY (`author_id`) REFERENCES `author` (`id`))
...

마찬가지로 IN 절이 아닌 OR 연산자를 사용하여 WHERE 절에 해당하는 ID들을 단순히 연결하고 있으며, deleteInBatch()도 deleteAllInBatch()와 마찬가지로 orphanRemoval 또는 전이(cascade)를 사용하지 않기 때문에 외래 키 제약 조건으로 인해 에러가 발생했다.

이 경우에도 물리적으로 테이블에 외래키가 설정되어 있지 않을 시 외래 키 제약 조건 문제는 발생하지 않지만, Author 테이블의 레코드만 삭제되고 Book 테이블의 레코드는 삭제되지 않는다.

 

3. deleteAll() 삭제

@Transactional
public void deleteAuthorsAndBooksDeleteAll() {
    List<Author> authors = authorRepository.findAll();
    
    authorRepository.deleteAll(authors);
}

delete from book where id=?
delete from book where id=?
delete from book where id=?
delete from book where id=?
delete from book where id=?
delete from author where id=?
 
delete from book where id=?
delete from book where id=?
delete from book where id=?
delete from book where id=?
delete from book where id=?
delete from author where id=?
...

deleteAll() 메서드를 사용하면, 각 Author 엔티티를 삭제할 때마다 관련된 Book 엔티티가 모두 제거된 후 해당 Author 엔티티가 삭제된다. 위의 경우 하나의 Author가 5개의 Book을 가지고 있기 때문에 각 Book을 삭제하는 쿼리가 5번 실행된 후 Author 삭제 쿼리가 실행되는 식으로 반복된다.

다만 이 방식은 배치 처리가 사용되지만 최적화되어있지는 않다. DELETE문은 정렬되지 않기 때문에, 이 작업에 필요한 것보다 더 많은 배치가 발생한다. 배치는 하나의 테이블만 대상으로 할 수 있기 때문에 Book과 Author 테이블을 번갈아 처리하면 5권의 도서를 가진 10명의 저자를 삭제할 경우 10 * 2 = 20개의 배치가 필요하게 된다. 각 저자가 각자의 배치에서 삭제되고 그에 따른 도서가 다른 배치에서 삭제되기 때문에 비효율적이다.

따라서 조금 더 배치 수를 최적화하기 위해서는 다음과 같이 작업할 수 있다.

@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Author {
    ...
 
    public void removeBooks() {
        Iterator<Book> iterator = this.books.iterator();
        while (iterator.hasNext()) {
            Book book = iterator.next();
            book.setAuthor(null);
 
            iterator.remove();
        }
    }
}

@Transactional
public void deleteAuthorsAndBooksDeleteAll() {
    List<Author> authors = authorRepository.findAll();
 
    authors.forEach(Author::removeBooks);
    authorRepository.flush();
 
    authorRepository.deleteAll(authors);
}

delete from book where id=?
delete from book where id=?
delete from book where id=?
delete from book where id=?
delete from book where id=?
...
 
delete from author where id=?
delete from author where id=?
delete from author where id=?
delete from author where id=?
...

잘 보면 이전과 달리 테이블의 모든 Book 레코드가 먼저 제거된 후 Author가 삭제된다. 연관된 모든 도서를 삭제하는 작업이 먼저 수행되므로, orphanRemoval이 true로 설정되어 있는 경우 연관 관계가 해제된 모든 도서가 자동으로 삭제되며, 생성된 DELETE문은 배치로 처리된다(orphanRemoval이 false로 설정된 경우, 삭제 대신 여러 UPDATE 문이 실행됨).

즉 연관관계를 갖는 모든 도서를 삭제하는 작업이 먼저 수행된다. 따라서 이 방법을 통해 배치 처리의 효율성을 높여 Author와 Book 모두에 적용할 수 있다.

 

4. SQL, ON DELETE CASCADE 사용

사실 연관 관계가 있을 때 deleteAllInBatch()나 deleteInBatch()를 사용하여 Author만 삭제하더라도 자동으로 Book까지 삭제되도록 할 수 있는 방법이 존재하는데, SQL의 전이 삭제 지시자인 ON DELETE CASCADE를 사용하는 것이다.

ON DELETE CASCADE는 부모 행이 삭제될 때 데이터베이스에서 자동으로 자식 행을 삭제하는 방식으로 하이버네이트 @OnDelete 어노테이션을 통해 설정할 수 있다.

@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Author {
    ...
    
    @OneToMany(cascade = CascadeType.ALL, mappedBy = "author", orphanRemoval = true)
    @OnDelete(action = OnDeleteAction.CASCADE) // 추가
    private List<Book> books = new ArrayList<>();
}

테이블은 다음과 같이 변경된다.

ALTER TABLE book
ADD CONSTRAINT fk_author_book
FOREIGN KEY (author_id) REFERENCES author (id)
ON DELETE CASCADE;

이 설정을 통해 Author가 삭제될 때 연관된 Book도 자동으로 삭제되므로, 이전에 deleteAllInBatch()나 deleteInBatch()를 사용할 때 애플리케이션 코드 레벨에서 명시적으로 Book 엔티티를 삭제할 필요가 없게된다.