JPA에서 엔티티에 관계를 맵핑할때 지연 로딩과 즉시 로딩을 설정할 수 있다.
그리고 지연 로딩을 했을 때의 단점을 보완하기 위한 Fetch Join에 대한 정리 글이다.
1. 즉시 로딩과 지연 로딩의 차이점?
앞서 말했듯, JPA에는 엔티티에 관계를 맵핑할 때 지연 로딩과 즉시 로딩을 설정할 수 있다.
즉시 로딩 : 어떠한 엔티티가 조회되었을 때 연관된 엔티티도 모두 함께 조회
지연 로딩 : 어떠한 엔티티가 조회되었을 때 연관된 엔티티는 Proxy로 들어가게 되고, 실제로 사용될 때 DB에서 조회해서 사용
연관된 엔티티를 추가 SQL로 조회할 필요 없이 모두 가져올 수 있기 때문에, 즉시로딩이 좋아보이지만, 즉시 로딩은 다음과 같은 문제를 야기한다.
- 엔티티를 조회하지만, 연관된 엔티티는 필요하지 않음에도 조회를 하기 때문에 성능 상 이슈가 있다.
- 사용하지 않는 연관된 엔티티를 찾아오기 위해서 개발자가 의도하지 않은 Query가 발생하여 N+1 문제가 발생할 수 있다.
이러한 문제점들로 지연로딩을 사용하는 편이다. 그런데, 지연 로딩 또한 연관된 엔티티를 사용할 때 어차피 한번의 Query가 더 발생하지 않냐?라고 생각할 수 있다.
맞다. Fetch Join을 알기 전까진 ...
엔티티를 조회할 때 Fetch Join을 사용한다면, 개발자의 의도 하에 한 번의 Query로 연관된 엔티티를 같이 조회할 수 있다. 따라서 연관된 엔티티가 필요하지 않을 땐 Proxy가 들어오며, 필요할 때는 실제 객체를 조회할 수 있게 되어 즉시 로딩의 문제점을 보완하게 된다. (단 N:1 관계에서 1쪽에서 Fetch Join을 사용한다면 페이징이 되지 않으므로 주의해야 한다.)**
결론
로딩과 Fetch Join
- 즉시 로딩은 성능 문제와 N+1 문제를 야기하고, 따라서 지연 로딩이 주로 사용된다.
- 지연 로딩을 사용한다면 Fetch Join은 선택이 아닌 필수 사항이다.
- N+1문제와 성능 최적화를 노릴 수 있다.
- **Fetch Join은 @EntityGraph 또는 @Query Fetch Join이 있는데
@EntityGraph = left outer join
@Query Fetch Join = inner join
이다. - 따라서 목적에 맞게 구분하여 사용하여야 한다.
