fetch join

SQL 조인 종류는 아니다.
JPQL에서 성능 최적화를 위해 제공하는 전용 기능이다.
연관된 Entity나 컬렉션을 SQL 한 번에 조회할 수 있다.

select m만 썼는데도 회원을 조회하면서 연관된 팀도 SQL에서 한 번에 조회한다.
- SQL을 보면 회원 M.*과 팀 T.*을 함께 select 한다.
즉시 로딩으로 가져오는 방법과 똑같다.
- 단지 join fetch라고 명시적으로 선언해서 원하는 객체 그래프를 한 번에 조회하는 것이다.

단일 값 fetch join

회원 1, 2는 팀 A 소속이다.
회원 3은 팀 B 소속이다.
회원 4는 소속 팀이 없다.

fetch join으로 회원과 팀을 한 번에 조회할 수 있다.
총 5개의 엔티티를 1차 캐시에 저장해놓는다.
- 회원 1, 2, 3, 팀 A, 팀 B

소속 팀이 없는 회원은 제외되는 inner join이다.

일반 join 예시

public class JpaMain {

    public static void main(String[] args) {
        String jpql = "select m from Member m";
        List<Member> members = em.createQuery(jpql, Member.class)
                .getResultList();

        for (Member member : members) {
            System.out.println("member = " + member.getUsername() + ", "
                    + "teamName = " + member.getTeam().name());
        }
    }
}

연관 관계에 있는 team이 프록시로 들어왔다가, getTeam().getName() 을 호출할 때 지연 로딩으로 select 쿼리가 나간다.
- 회원 1이 팀 A를 불러 올 때 최초 SQL을 날린다.
- 회원 2는 같은 팀 A이므로 1차 캐시에서 가져온다.
- 회원 3의 팀 B는 영속성 컨텍스트에 존재하지 않으므로 새로운 쿼리를 날린다.
N + 1 문제
- 소속이 다 다르면 N개만큼 계속 쿼리가 나가야 한다.
- 회원을 가져오기 위해 최초에 날린 1번의 쿼리 + 회원이 소속된 팀 개수 N만큼 날린다.

fetch join 예시

public class JpaMain {

    public static void main(String[] args) {
        // fetch join 사용
        String jpql = "select m from Member m join fetch m.team";
        List<Member> members = em.createQuery(jpql, Member.class)
                .getResultList();

        for (Member member : members) {
            System.out.println("username = " + member.getUsername() + ", "
                    + "teamName = " + member.getTeam().name());
        }
    }
}

fetch join으로 회원과 팀을 한 번에 조회한다.
- 지연 로딩하지 않는다.
- 즉, member.getTeam().name() 호출 시에 프록시가 아니라 실제 Entity가 담겨있다.
지연 로딩으로 되어있어도 fetch join이 우선 순위를 가진다.

컬렉션 fetch join

일대다 관계에서의 컬렉션 조회

반대로 팀에서 N인 회원을 조회한다.

회원만큼 팀이 중복으로 출력된다.
DB 입장에서는 일대다 join 시 데이터가 뻥튀기 된다.

팀 A로 조인을 하면 회원이 2명이므로 데이터를 2개 만들어 낸다.
JPA 입장에서는 회원이 몇 명 있는지 미리 알 수가 없으니 DB가 반환하는 대로 가져와야 한다.

row는 2개지만 영속성 컨텍스트에 있는 ID는 같이 공유하므로 주소 값이 같다.

fetch join과 DISTINCT

SQL의 DISTINCT
- 중복을 완벽하게 제거할 수 없다.
JPQL은 DISTINCT에 대해 2가지 기능을 제공한다.
- SQL에 DISTINCT를 추가
- SQL 결과를 애플리케이션에서 받은 뒤 엔티티의 중복을 제거

select distinct t
from Team t
         join fetch t.members
where t.name = '팀A'

SQL의 DISTINCT는 데이터가 100% 똑같아야 적용된다.
- join 결과를 보면 각 row의 PK가 다르기 때문에 중복 제거에 실패한다.
그래서 JPA가 애플리케이션에서 추가적인 중복 제거를 시도한다.

JPQL의 DISTINCT가 같은 식별자를 가진 Team Entity를 자동으로 제거한다.

일반 join과의 차이

일반 join

연관된 entity를 함께 조회하지 않는다.
- jpql에 일반 join을 쓰면 sql에서 team만 select 한다.
  - Team Entity만 조회하고 Member Entity는 조회하지 않는다.
- team.getMembers() 하는 시점에 쿼리가 다시 나간다.

fetch join

팀 정보를 가져올 때 회원 정보도 함께 가져온다.
fetch join을 사용할 때만 연관된 Entity를 함께 조회한다.
- 즉시 로딩의 개념
- 객체 그래프를 SQL 한 번에 조회할 수 있다.

한계

별칭 사용 불가

select t
From Team t
         -- as 사용 불가
         join fetch t.members as m

fetch join 대상에는 별칭을 줄 수 없다.
- 하이버네이트는 가능하지만 가급적 사용하지 않는다.

select t
From Team t
         -- 별칭으로 다시 걸러서 사용하는 방식 불가
         join fetch t.members as m
where m.username...

fetch join은 연관된 모든 것을 가져오는 용도다.
- 중간에 걸러서 가져오고 싶다면 fetch join을 쓰면 안된다.
- 별칭을 줘서 선별적으로 가져왔다가 잘못하면 데이터가 누락되고 이상하게 돌아갈 수 있다.
원하는 회원만 가져오고 싶다면 처음부터 팀이 아니라 회원에 대한 쿼리를 날려야 한다.
JPA는 객체 그래프 탐색으로 연관된 데이터를 모두 가져올 수 있다는 걸 가정한다.
- 잘못된 설정으로 몇 개가 걸러져서 나온다면 이 상황을 보장할 수 없다.
유일하게 쓰는 케이스는 별칭 안에서 또 join fetch를 해서 들어가야할 때 뿐이다.

둘 이상의 컬렉션 불가

둘 이상의 컬렉션은 fetch join 할 수 없다.
- 곱하기에 곱하기가 되면서 데이터가 기하급수적으로 늘어나기 때문이다.
- ex. team이 members와 orders를 가진다면 이 둘을 한번에 fetch join할 수 없다.

페이징 API 사용 불가

컬렉션을 fetch join 하면 페이징 API를 사용할 수 없다.
page size = 1이면 팀 A의 회원 2명이 다 나오는 게 아니라 짤려서 하나만 가져온다.
- JPA는 팀 A의 결과가 2명임에도 1명밖에 없다고 말하게 된다.
- 회원 2는 2 페이지에 있기 때문에 모른다.
일대일, 다대일 같은 단일 값 연관 필드는 fetch join으로도 페이징이 가능하다.
- 데이터 뻥튀기가 되지 않기 때문이다.
하이버네이트는 경고 로그를 남기고 메모리에서 페이징하지만 매우 위험하다.
- 데이터가 백만 건이면 다 일단 가져와서 그 안에서 페이징 하기 때문에 장애가 발생한다.

-- before
select t
From Team t
         join fetch t.members m
-- after
select m
From Member m
         join fetch m.team t

페이징을 하고 싶다면 쿼리를 바꿔야 한다.
쿼리를 반대로 뒤집으면 회원과 팀이 다대일이 되어 페이징이 가능해진다.

public class JpaMain {

    public static void main(String[] args) {
        String query = "select t From t";

        List<Team> result = em.createQuery(query, Team.class)
                .setFirstResult(0)
                .setMaxResult(2)
                .getResultList();

        for (Team team : result) {
      ...
        }
    }
}

쿼리를 수정할 수 없다면 maxResult를 건다.

하지만 지연 로딩으로 팀 A, B의 회원을 2번 더 쿼리한다.
- 즉, 쿼리가 총 3번이 나간다.
- 그래서 fetch join으로 한 번에 불러오는 게 좋은데 페이징이 힘들다.

@BatchSize

@Entity
public class Team {
  
  ...

    @BatchSize(size = 100)
    @OneToMany(mappedBy = "team")
    private List<Member> members = new ArrayList<>();
  
  ...
}

페이징 때문에 fetch join을 사용하지 않는다면 @BatchSize를 사용한다.

팀을 가져올 때 지연 로딩으로 되어있는 회원에 대해 where team_id in (A, B)로 가져온다.
지연 로딩은 N + 1이 발생하기 때문에 fetch join을 사용하지만 연관 관계가 컬렉션인 경우는 @BatchSize를 사용할 수 있다.
- 회원 수만큼이 아니라 딱 팀에 맞춰서 최적화된 쿼리로 불러올 수 있다.
보통 1000 이하의 값으로 주면 된다.

batchSize 설정은 글로벌로 두고 쓸 수도 있다.

fetch join의 특징

연관된 Entity들을 SQL 한 번으로 조회하므로 성능 최적화가 된다.
Entity에 직접 적용하는 글로벌 로딩 전략보다 우선한다.
- 글로벌 로딩 전략이 @OneTonMany(fetch = FetchType.LAZY) 지연 로딩이더라도 적용된다.
실무에서 글로벌 로딩 전략은 모두 지연로딩이다.
최적화가 필요한 곳은 fetch join을 적용한다.

한계

모든 것을 fetch join으로 해결할 수는 없다.
객체 그래프를 유지할 때 사용하면 효과적이다.
- team.getMembers()
여러 테이블을 join해서 Entity가 가진 모양과 다른 결과를 내야 한다면?
- 일반 join으로 필요한 데이터만 조회해서 DTO로 반환한다.

Previous경로 표현식 Next다형성 쿼리

Last updated 3 years ago

Was this helpful?