[JPA] Fetch Join

🌱 Fetch Join

SQL 조인 종류가 아닌, JPQL에서 성능 최적화를 위해 제공하는 기능이다.

연관된 엔티티나 컬렉션을 SQL 한번에 함께 조회하는 기능이다.

[LEFT | INNER ] JOIN FETCH

 

[JPQL]

select m from Member m join fetch m.team

 

[SQL]

select m.*, t.*

from member m

inner join team t

on m.team_id = t.id

 

 

🌱 OneToMany + Fetch Join 시 주의!

String jpql = "select t from Team t join fetch t.members where t.name = '팀A'"
List<Team> teams = em.createQuery(jpql, Team.class).getResultList();

for(Team team : teams) {
    System.out.println("teamname = " + team.getName() + ", team = " + team);
    for (Member member : team.getMembers()) {
    	System.out.println(“-> username = " + member.getUsername()+ ", member = " + member);
    }
}

OneToMany + fetch join에 대한 결과가 다음과 같이 뻥튀기가 될 수 있다!

 

teamname = 팀A, team = Team@0x100
- username = 회원1, member = Member@0x200
- username = 회원2, member = Member@0x300
teamname = 팀A, team = Team@0x100
- username = 회원1, member = Member@0x200
- username = 회원2, member = Member@0x300

 

🌱 왜 이런 뻥튀기 현상이 나올까?

팀A에 대해 연관된 member가 두명이라고 하자. join을 통해 나온 결과 테이블은 다음과 같다.

  이 결과가 JPA로 넘어오게 되면, 일단 JPA는 결과 row 수만큼 돌려야한다. PK값이 똑같더라도 일단 row 갯수만큼 만큼 만들어야한다. 중복을 제거할지 말지는 추후에 사용자가 선택하게끔 한다. JPA 입장에서는 일단 똑같은 팀A가 두개다. 이 팀A는 회원1, 회원2를 가지고 있다. 때문에 다음과 같은 그림이 그려진다.

 

🌱 그럼 어떻게 해야하는가?

 같은 식별자를 가지는 완벽히 동일한 TeamA가 두번 만들어지는 것이 문제였다. 그러니 중복된 TeamA를 삭제하면 된다. 

이를 위해 JPQL의 DISTINCT는 두가지 기능을 제공한다.

1. SQL에 DISTINCT를 추가
2. 애플리케이션에서 엔티티 중복 제거

     -> 이때 같은 식별자를 가진 Team 엔티티 제거

String jpql = "select distinct t from Team t join fetch t.members where t.name = '팀A'"
List<Team> teams = em.createQuery(jpql, Team.class).getResultList();

for(Team team : teams) {
    System.out.println("teamname = " + team.getName() + ", team = " + team);
    for (Member member : team.getMembers()) {
    	System.out.println(“-> username = " + member.getUsername()+ ", member = " + member);
    }
}

 

 

🌱 Fetch Join 한계

1. Fetch Join 대상에는 별칭을 주면 안된다.

String jpql = "select distinct t from Team t join fetch t.members as m" // 안됨
String jpql = "select distinct t from Team t join fetch t.members as m where m.age > 10" // 안됨

 fetch join은 기본적으로 나랑 연관된 것들은 전부 들고 오는 일이다. 만약 나와 연관된 애들을 걸러서 가져오고 싶다면 fetch join을 쓰면 안된다. 그런걸 원한다면 team.getMember()로 가져오면 안되고 member에서 따로 조회하는 것이 맞다. 데이터의 정합성, JPA의 객체 그래프 사상에 맞지 않는 행위이다.

 영속성 컨텍스트 입장에서 생각해보자. 똑같은 teamA인데 어떤 애는 member 100개 중에 100개를 다가져오고 다른 애는 member 100개 중 5개를 가지고 왔다고 생각해보자. 영속성 컨텍스트 입장에서는 굉장히 난감한 상황일 것이다. 별칭은 join fetch를 여러단계를 거쳐가는 등의 복잡한 행위에서만 사용하고 가급적 사용하지 않는 것이 좋다.

 

2. 둘 이상의 컬렉션을 패치조인하면 안된다.

: 데이터가 몇배로 늘어날 수 있어 위험하다. 패치조인의 컬렉션은 하나만 지정하도록 하자.

 

3. 컬렉션을 패치조인하면 페이징 API()를 사용할 수 없다.

- OneToOne, ManyToOne은 페치조인해도 페이징이 가능하다.

- 하지만 OneToMany는 데이터 뻥튀기가 되기때문에 fetch join이 불가능하다.

   : DB 조회 결과 값이 아래의 그림과 같으면서 페이징이 1이라면 팀A는 회원1밖에 갖지 못한다. 실제로는 팀A가 회원1, 회원2를 가지고 있음에도 불구하고! 이런 데이터 정합성 오류가 생길 수 있다. 버전마다 다를 수 있지만 이때 하이버네이트는 경고 로그를 날리고 페이징쿼리가 아닌 전체 데이터 조회쿼리를 날리고 메모리에서 페이징 처리를 한다.(매우 위험!)

 

🌱 패치조인 정리

• 연관된 엔티티나 컬렉션을 SQL 한번에 함께 조회하는 기능이다.
• 엔티티에 직접 적용하는 글로벌 로딩 전략보다 우선된다.
  •  FetchType.LAZY인지 EAGER인지 상관없이 무조건 fetch join이 먹힌다.
• 실무에서는 글로벌 로딩 전략은 모두 지연로딩으로 하고 최적화가 필요한 곳에 fetch join을 이용한다.
• Fetch join이 모든 것을 해결해주는 것은 아니고, 객체 그래프를 유지할 때 사용하면 효과적이다!
  
  • 만약 여러 테이블을 조회해서 엔티티가 원래 가진 모양이 아닌 전혀 다른 결과를 내야한다면, 패치조인이 아닌 일반조인+DTO로 반환하는 것이 효과적이다!