[JPA] N+1 문제

설기똥꼬 2023. 5. 4. 00:59

2023. 5. 4. 00:59

프로젝트 제작하면서 발생했던 MultipleBagFetchException 에러를 맞닥뜨리게 되면서,

원인부터 파악하기 위해 우선 N+1 문제에 대해 알아보려고 한다.

하단의 블로거 분 글을 보고 공부하고 많이 참고하였다!

N+1 문제 - Incheol's TECH BLOG

Query를 실행하도록 지원해주는 다양한 플러그인이 있다. 대표적으로 Mybatis, QueryDSL, JOOQ, JDBC Template 등이 있을 것이다. 이를 사용하면 로직에 최적화된 쿼리를 구현할 수 있다.

incheol-jung.gitbook.io

N+1 문제란!

JPA를 사용하면 자주 만나게 되는 것들 중 하나가 N+1 문제다.

N+1 문제란, 연관 관계에서 발생하는 이슈로 연관 관계가 설정된 엔티티를 조회할 경우 조회된 데이터 갯수 (N) 만큼 연관 관계의 조회 쿼리가 추가로 발생하여 데이터를 읽어온다. 이를 N+1 문제라고 한다.

N+1 문제를 마주치게 한 코드들을 먼저 살펴보자.

Entity 설정

위 사진은 현재 진행하고 있는 졸프 서버 ERD 설계도이다

ERD 설계대로 제작한 Entity 코드는 아래와 같다.

관리자 (Admin)은 회원을 여러명 추가할 수 있다.
회원은 한 명(팀)의 관리자에 종속되어 있다.
Cctv도 이하 동문!

AdminEntity (테스트 위해 수정)

package com.example.ahpuh.admin.entity;

import com.example.ahpuh.cctv.entity.CctvEntity;
import com.example.ahpuh.user.entity.UserEntity;
import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Getter;
import lombok.NoArgsConstructor;

import javax.persistence.*;
import java.util.ArrayList;
import java.util.HashSet;
import java.util.List;
import java.util.Set;

@Entity
@Getter
@NoArgsConstructor
@AllArgsConstructor
@Table(name = "admin")
public class AdminEntity {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long adminIdx;

    @Column(nullable = false, length = 100)
    private String email;

    @Column(nullable = false, length = 100)
    private String pwd;

    @Column(nullable = false, length = 100)
    private String poolName;

    @Column(nullable = false, length = 100)
    private String poolNum;

    @Column(nullable = false, length = 100)
    private String poolAddress;

    @Column(nullable = false, columnDefinition = "varchar(10) default 'active'")
    private String status;

    @OneToMany(fetch = FetchType.LAZY, mappedBy = "userIdx")
    private Set<UserEntity> userEntities = new HashSet<>();

    @OneToMany(fetch = FetchType.LAZY, mappedBy = "cctvIdx")
    private List<CctvEntity> cctvEntities = new ArrayList<>();

    @Builder
    public AdminEntity(String email, String pwd, String poolName, String poolNum, String poolAddress, String status){
        this.email = email;
        this.pwd = pwd;
        this.poolName = poolName;
        this.poolNum = poolNum;
        this.poolAddress = poolAddress;
        this.status = status;
    }

    public AdminEntity(String s) {
        this.poolName = s;
    }

    public void setUsers(Set<UserEntity> user) {
        this.userEntities = user;
    }
}

UserEntity

package com.example.ahpuh.user.entity;

import com.example.ahpuh.admin.entity.AdminEntity;
import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Getter;
import lombok.NoArgsConstructor;

import javax.persistence.*;

@Entity
@Getter
@NoArgsConstructor
@AllArgsConstructor
@Builder
@Table(name = "user")
public class UserEntity {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long userIdx;

    @ManyToOne
    @JoinColumn(name = "adminIdx")
    private AdminEntity adminIdx;

    @Column(nullable = false, length = 100)
    private String name;

    @Column(nullable = false, length = 100)
    private String phoneNum;

    @Column(nullable = true)
    private String gender;

    @Column(nullable = true)
    private String age;

    @Column(nullable = true)
    private String address;

    @Column(nullable = false, columnDefinition = "varchar(10) default 'ACTIVE'")
    private String lectureStatus;

    @Column(nullable = false, columnDefinition = "varchar(10) default 'active'")
    private String status;

    @Builder
    public UserEntity(String name, String phoneNum, String gender, String age, String address, String lectureStatus, String status){
        this.name = name;
        this.phoneNum = phoneNum;
        this.gender = gender;
        this.age = age;
        this.address = address;
        this.lectureStatus = lectureStatus;
        this.status = status;
    }
}

CctvEntity

package com.example.ahpuh.admin.entity;

import com.example.ahpuh.cctv.entity.CctvEntity;
import com.example.ahpuh.user.entity.UserEntity;
import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Getter;
import lombok.NoArgsConstructor;

import javax.persistence.*;
import java.util.ArrayList;
import java.util.HashSet;
import java.util.List;
import java.util.Set;

@Entity
@Getter
@NoArgsConstructor
@AllArgsConstructor
@Table(name = "admin")
public class AdminEntity {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long adminIdx;

    @Column(nullable = false, length = 100)
    private String email;

    @Column(nullable = false, length = 100)
    private String pwd;

    @Column(nullable = false, length = 100)
    private String poolName;

    @Column(nullable = false, length = 100)
    private String poolNum;

    @Column(nullable = false, length = 100)
    private String poolAddress;

    @Column(nullable = false, columnDefinition = "varchar(10) default 'active'")
    private String status;

    @OneToMany(fetch = FetchType.LAZY, mappedBy = "userIdx")
    private Set<UserEntity> userEntities = new HashSet<>();

    @OneToMany(fetch = FetchType.LAZY, mappedBy = "cctvIdx")
    private List<CctvEntity> cctvEntities = new ArrayList<>();

    @Builder
    public AdminEntity(String email, String pwd, String poolName, String poolNum, String poolAddress, String status){
        this.email = email;
        this.pwd = pwd;
        this.poolName = poolName;
        this.poolNum = poolNum;
        this.poolAddress = poolAddress;
        this.status = status;
    }

    public void setUsers(Set<UserEntity> user) {
        this.userEntities = user;
    }
}

관리자 (Admin)을 조회해보면?

테스트 케이스를 작성하여 조회를 해보자.

테스트 시나리오는 다음과 같다.

회원 10명을 추가했다.
관리자 10팀을 생성했다.
관리자는 10명씩 회원을 담당하고 있다.
관리자를 조회해보자.

테스트 코드는 다음과 같다.

@Test
	void contextLoads() {
		Set<UserEntity> user = new LinkedHashSet<>();
		for(int i = 0; i < 10; i++){
			user.add(new UserEntity("user" + i));
		}
		userRepository.saveAll(user);

		List<AdminEntity> admins = new ArrayList<>();
		for(int i = 0; i < 10; i++){
			AdminEntity admin = new AdminEntity("admin" + i);
			admin.setUsers(user);
			admins.add(admin);
		}
		adminRepository.saveAll(admins);

		entityManager.clear();

		System.out.println("-------------------------------------------------------------------------------");
		List<AdminEntity> everyAdmins = adminRepository.findAll();
		assertFalse(everyAdmins.isEmpty());
	}

결과는?

Hibernate SQL Log를 활성화하여 실제로 호출된 결과를 확인했는데, (로그 추가 예정)

관리자를 조회하는 쿼리를 호출하였다.
회원을 조회하는 쿼리가 관리자를 조회한 row 만큼 쿼리가 호출하였다.

FetchType.EAGER라서 발생하는 것일까?

이와 같은 경우 쿼리가 하나밖에 호출되지 않았지만, 이는 연관관계 데이터를 프록시 객체로 바인딩한다는 것이다.

하지만 실제로 우리는 연관관계 엔티티를 프록시만으로는 사용하지 않기에 실제 연관관계의 엔티티를 사용하는 로직을 추가한다면 마찬가지로 N+1 문제가 발생한다.

FetchType을 변경하는 것은 단지 N+1 발생 시점을 연관관계 데이터를 사용하는 시점으로 미룰지, 초기 데이터 로드 시점에 가져올지 차이만 있는 것이다.

N+1은 왜 발생하는 것일까?

N+1은 쿼리를 1개 날렸는데, 이로 인하여 추가 쿼리가 N개 나간다는 의미이다.

JPARepository에 정의한 인터페이스 메서드를 실행하면 JPA는 메서드 이름을 분석해서 JPQL을 생성하여 실행하게 된다. JPQL은 SQL을 추상화한 객체지향 쿼리 언어로서 특정 SQL에 종속되지 않고 엔티티 객체와 필드 이름을 가지고 쿼리를 한다.

그렇기에 JPQL은 연관관계 데이터를 무시하고 해당 엔티티 기준으로 쿼리를 호출하기에, findAll()이란 메소드를 수행하였을 때 해당 엔티티를 조회하는 select * from Admin 쿼리만 실행하게 되는것이다. 그렇기 때문에 연관된 엔티티 데이터가 필요한 경우, FetchType으로 지정한 시점에 조회를 별도로 호출하게 된다.

해결 방법

1. Fetch join

최적화된 쿼리를 직접 사용하는 것이다.

이는 JPARepository에서 제공하는 것은 아니고 JPQL로 작성해야 한다.

@Query("select a from Admin a join fetch a.users")
List<AdminEntity> findAllJoinFetch();

실제로 INNER JOIN으로 호출되며, 이는 연관관계가 있을 경우 하나의 쿼리문으로 표현할 수 있기에 매우 유리하다.

그러나 Fetch Join을 사용하는 경우 FetchType을 사용할 수 없다.

Fetch Join을 사용시 데이터 호출 시점에 모든 연관 관계의 데이터를 가져오기에 FetchType을 Lazy로 해놓는 것이 무의미하다.

또한 페이징 쿼리를 사용할 수 없다.

하나의 쿼문으로 가져오다 보니 페이징 단위로 데이터를 가져오는 것이 불가능하다.

2. EntityGraph

@EntityGraph의 attributePaths에 쿼리 수행시 바로 가져올 필드명을 지정하면 Lazy가 아닌 Eager 조회로 가져오게 된다.

Fetch join과 동일하게 JPQL을 사용하여 query문을 작성하고 필요한 연관관계를 EntityGraph에 설정하면 된다.

그리고 Fetch join과는 다르게 join문이 OUTER JOIN으로 실행되는 것을 확인할 수 있다.

@EntityGraph(attributePaths = "users")
@Query("select a from Admin a")
List<AdminEntity> findAllEntityGraph();

FetchJoin & EntityGraph 주의사항

Fetch Join과 EntityGraph는 JPQL을 사용하여 JOIN문을 호출한다는 공통점이 있다. 또한, 공통적으로 카테시안 곱(Cartesian Product)이 발생하여 Admin의 수만큼 user의 중복 데이터가 존재할 수 있다.

그러므로 중복된 데이터가 컬렉션에 존재하지 않도록 주의해야 한다.

컬렉션 Set을 사용하게 되면 중복을 허용하지 않는 자료구조이기에 중복된 데이터를 제거할 수 있다.
JPQL을 사용하기 때문에 distinct를 사용하여 중복된 데이터를 조회하지 않을 수 있다.

해결방법

1. FetchMode.SUBSELECT

한번의 쿼리가 아닌 두번의 쿼리로 해결하는 방법이다.

해당 엔티티를 조회하는 쿼리는 그대로, 연관관계 데이터를 조회할 때는 서브 쿼리로 함께 조회하는 방법이다.

즉시로딩으로 설정하면 조회시점에, 지연로딩으로 설정하면 지연로딩된 엔티티를 사용하는 시점에 위의 쿼리가 실행된다. 모두 지연로딩으로 설정하고 성능 최적화가 필요한 곳에는 JPQL fetch join을 사용하는 것이 추천되는 전략이다.

2. BatchSize

하이버네이트가 제공하는 org.hibernate.annotations.BatchSize 어노테이션을 이용하면, 연관된 엔티티를 조회할 때 지정된 size만큼 SQL의 IN절을 사용하여 조회한다.

즉시로딩시 @BatchSize가 있을때 User의 row 갯수만큼 추가 SQL을 날리지 않고, 조회한 Admin의 Id들을 모아서 SQL IN 절을 날린다. size는 IN절에 올수있는 최대 인자 개수를 말한다.

만약 User의 개수가 10개이고 size = 5라면, IN절이 2번 실행될것이다.

지연 로딩이라면 지연 로딩된 엔티티 최초 사용시점에 5건을 미리 로딩해두고, 6번째 엔티티 사용 시점에 다음 SQL을 추가로 실행한다.

그러나 연관 관계 데이터의 최적화 데이터 사이즈를 알기는 쉽지 않다.

추가로, hibernate.default_batch_fetch_size 속성을 사용하면 애플리케이션 전체에 기본으로 @BatchSize를 적용할 수 있다.

3. QueryBuilder

Query를 실행하도록 지원해주는 다양한 플러그인 중 대표적으로 Mybatis, QueryDSL, JOOQ, JDBC Template 등이 있다.

이를 사용하면 로직에 최적화된 쿼리를 구현할 수 있다.

// QueryDSL로 구현한 예제
return from(admin).leftJoin(admin.users, user)
                   .fetchJoin()

# References