[JPA] JPA의 N + 1 문제 정리

N + 1 문제

• 연관 관계에서 발생하는 이슈
• 연관 관계가 설정된 엔티티를 조회할 경우에 조회된 데이터 갯수(n)만큼 연관관계의 조회 쿼리가 추가로 발생하여 데이터를 읽어오는 현상.

현상 재현

FetchType 정리

예시로, 선생님과 학생의 관계를 표현해보려한다.

• 하나의 선생님은 여러 명의 학생을 담당한다.
• 한 명의 학생은 한 명의 선생님에게 소속된다.

@Entity
@Data
@NoArgsConstructor
public class Teacher {
        @Id
        @GeneratedValue(strategy = GenerationType.IDENTITY)
        private int id;
        private String name;

        @OneToMany(mappedBy = "teacher", fetch = FetchType.EAGER) // fetchType에 따른 N+1문제 발생시점 파악 위함.
        private List<Student> students = new ArrayList<>();
}

@Entity
@Data
@NoArgsConstructor
public class Student {
        @Id
        @GeneratedValue(strategy = GenerationType.IDENTITY)
        private int id;
        private String name;

        @ManyToOne
        private Teacher teacher;

        public Student(String name) {
                this.name = name;
        }
}

학생의 선생님을 조회해보자

• FetchType.EAGER인 경우

  • 학생의 선생님을 조회하는 쿼리를 호출.
  • 학생을 조회하는 쿼리가 선생님을 조회한 row만큼 쿼리가 호출됨.

• FetchType.LAZY인 경우

  • 쿼리가 하나밖에 호출되지 않았지만, 그렇지 않다.

우선, FetchType을 LAZY로 설정했다는 것은 연관관계 데이터를 프록시 객체로 바인딩한다는 것이다. 하지만 실제로 연관관계 엔티티를 프록시만으로는 사용하지 않는다. 실제로는 연관관계 엔티티 멤버 변수를 사용하거나 가공하는 일은 코드를 구현하는 경우가 훨씬 흔하다.

로그를 확인해보면 지연로딩, 즉시로딩 상관없이 동일하게 N+1문제가 발생하게 된다. FetchType을 변경하는 것은 단지 N+1 발생 시점을 연관관계 데이터를 사용하는 시점으로 미룰지, 아니면 초기 데이터 로드 시점에 가져오느냐에 차이만 있는 것이다.

발생 이유

• jpaRepository에 정의한 인터페이스 메서드를 실행하면 JPA는 메서드 이름을 분석해서 JPQL을 생성하여 실행하게 됨.
• JPQL은 SQL을 추상화한 객체지향 쿼리 언어로서 특정 SQL에 종속되지 않고 엔티티 객체와 필드 이름을 가지고 쿼리를 한다.
• 그렇기에 JPQL은 findAll()이란 메서드를 수행하였을 때 해당 엔티티를 조회하는 select * from Teacher쿼리만 실행하게 되는 것이다.
• JPQL 입장에서는 연관관계 데이터를 무시하고 해당 엔티티 기준으로 쿼리를 조회하기 때문이다.
• 이렇기에 연관된 엔티티 데이터가 필요한 경우, FetchType으로 지정한 시점에 조회를 별도로 호출하게 됨.

해결 방법

1. Fetch Join

• select * from teacher left join student on student.teacher_id = teacher.id

• 최적화된 쿼리를 직접 사용할 수 있는데, Fetch join을 사용하면 된다.

• 이는 jpaRepository에서 제공해주는 것이 아닌 JPQL로 작성하면 된다.

• 실제로는 inner join으로 호출됨을 알 수 있다.

• 이는 연관관계의 연관관계가 있을 경우에도 하나의 쿼리 문으로 표현할 수 있으므로 매우 유리하다.

단점

• 연관관계 설정해놓은 FetchType을 사용할 수 없다.
• Fetch Join을 사용하게 되면 데이터 호출 시점에 모든 연관 관계의 데이터를 가져오기 때문에 FetchType을 Lazy로 해놓는 것이 무의미해진다.
• 페이징 쿼리를 사용할 수 없다. 하나의 쿼리문으로 가져오다 보니 페이징 단위로 데이터를 가져오는 것이 불가능하다.

2. @EntityGraph

• @EntityGraph의 attributePaths에 쿼리 수행시 바로 가져올 필드명을 지정하면 Lazy가 아닌 Eager 조회로 가져오게 된다.
• Fetch join과 동일하게 JPQL을 사용하여 query문을 작성하고 필요한 연관관계를 EntityGraph에 설정하면 된다.
• Fetch join과 다르게 join문이 outer join으로 실행된다.

주의할 점

• Fetch Join과 EntityGraph는 JPQL을 사용하여 JOIN문을 호출한다는 공통점이 있음.
• 공통적으로 카테시안 곱이 발생하여 Teacher의 수만큼 Student의 중복 데이터가 존재할 수 있다. 그렇기에 중복된 데이터가 컬렉션에 존재하지 않도록 주의해야한다.
  • 컬렉션을 Set을 사용하게 되면 중복된 데이터를 제거할 수 있다.
  • JPQL을 사용하기 때문에 distinct를 사용해 중복 데이터를 조회를 방지할 수 있다.

3. BatchSize

@Entity
@Data
@NoArgsConstructor
public class Teacher {
        @Id
        @GeneratedValue(strategy = GenerationType.IDENTITY)
        private int id;
        private String name;

        @BatchSize(size = 5)
        @OneToMany(mappedby = "teacher", fetch = FetchType.EAGER)
        private Set<Student> students = new LinkedHashSet<>();
}

• 연관된 엔티티를 조회할 때 지정된 size만큼 SQL의 IN절을 사용해서 조회한다.

• 즉시로딩이므로 Teacher를 조회하는 시점에 Student를 같이 조회한다.

• @BatchSize가 있으므로 Student의 row 갯수만큼 추가 SQL을 날리지 않고, 조회한 Teacher의 id들을 모아서 SQL IN절을 날린다.

• 여기서 size는 IN절에 올 수 있는 최대 인자 개수를 의미함. 만약 Student의 개수가 10개라면 IN절은 2번 실행될 것임.

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