[Spring][JPA] 최대한 쉽게 알아보는 @EntityGraph의 개념

 

 

 

연관관계가 있는 DB가 있는 경우
한쪽에 @EntityGraph를 사용했다.
@EntityGraph의 역할이 뭐길래
연관관계 테이블에 필요할까?

 

 

 

 

 

미리 알아야할 개념 설명

• @EntityGraph를 알기 위해서, 프록시(Proxy)와 Lazy(지연로딩), Eager(즉시로딩)에 대해서 알아야한다.
• 아마 @EntityGraph의 개념이 궁금한 이유는, 코드에 @ManyToOne과 같은 코드를 작성했기 때문이다.
• 이때 @ManyToOne에 fetch = FetchType.Lazy를 설정한 경우 @EntityGraph가 필요하다. → 이 조합을 많이 쓴다는 걸 알고 일단은 넘어가자. 왜 이 조합을 많이 쓰는지 뒤에 설명하겠다.
• JPA가 DB에서 데이터를 가져올 때 당장 필요 없는 연관 데이터는 진짜 객체 대신 가짜 객체를 넣어두는데, 이때 이 가짜 객체를 프록시라고 말한다.
• 그러면 @ManyToOne(fetch = FetchType.Lazy)는 프록시를 사용하겠다는 말로, 개발자가 진짜 데이터를 달라고 요청하면 그제서야 진짜 객체를 찾아 보내주는 것이다. → 게시글엔 작성자 이름이 포함된 경우, 게시글 조회시 작성자 이름은 프록시로 가져온다. 그리고 작성자 이름을 요청하면 그때서야 직접 진짜 객체를 찾아서 들고온다.
• @ManyToOne의 기본값은 Eager이다. Eager은 원하지 않아도 관련된 데이터를 모두 찾아가지고 오는 것이다.

 

 

 

---

 

 

 

 

 

@EntityGraph

• 객체 그래프라는 이름과 같이, 엔티티 간의 연관관계를 타고 데이터를 가져올 때만 의미가 있다.
• DB 입장에서 JOIN을 하겠다는 뜻이다.
• JPA 입장에서는 프록시 대신 진짜 객체를 한꺼번에 채워 넣겠다는 뜻이다.
• 만약 연관관계가 설정이 안된 테이블에 사용한다면 경로 자체가 없기 때문에 사용할 수 없다. → 이럴 때는 직접 JOIN 쿼리를 짜거나 따로 조회해야한다.
• 실제 데이터가 즉시 필요한 곳에서만 사용한다. 

 

 

 

---

 

 

 

 

 

EAGER과 LAZY의 예시 코드와 결과

- 예시) 3개의 게시글이 있고, 게시글엔 작성자가 포함된다고 가정하자.

• EAGER

// 엔티티 설정
@Entity
public class Post {

    // 즉시로딩
    @ManyToOne(fetch = FetchType.EAGER) 
    private Member member;
}

// Repository (JPQL 사용 시)
@Query("select p from Post p")
List<Post> findAllJPQL();

게시글을 가져오라고 했을 때, EAGER로 설정해두면 작성자 이름도 무조건 함께 가져온다.

1) JPA는 @Query("select p from Post p")를 보고 SQL을 만든다. 그렇게 생성된 SQL은 SELECT * FROM post;로 포스트만 가져오도록 한다. 

2) DB로부터 게시글 3개의 데이터를 가져온다. → 쿼리 1번 발생

3) Post가 EAGER인 걸 알게 됐다. 데이터가 비어져 있는 걸 알고 작성자를 채우기 위해 하나하나 DB에 물어본다. Post1을 보고 SELECT * FROM member WHERE id = ?;를 실행한다. 그렇게 모든 게시글을 돌면서 작성자의 정보를 물어보는 것이다. 게시글이 3개라면 3번 물어본다. → 3개의 쿼리가 발생, 이걸 N+1 문제라고 한다.

요약해보자면, 먼저 SQL을 날리고 보니 EAGER인 걸 나중에 알게되어서 부랴부랴 부족한 데이터를 채우려고 추가 쿼리를 날리는 것이다. 그래서 N+1 문제가 발생하고 만약 조회할 게시글이 엄청나게 많다면 제대로 작동하지 않을 것이다.

 

 

 

• LAZY

// 엔티티 설정
@Entity
public class Post {

    // 지연로딩
    @ManyToOne(fetch = FetchType.LAZY) 
    @JoinColumn(name = "member_id")
    private Member member;
}

게시글을 가져오라고 했을 땐, 작성자 이름이 프록시로 온다. 그런데 작성자 이름을 요청하게 되면 그때 N+1 문제가 발생한다.

1) SELECT * FROM post;로 게시글 3개를 가져왔다. 그러나 작성자 자리는 프록시 상태이다. → 쿼리 1번 발생

2) 이름을 물어봤다. 1번 게시글의 작성자 이름 출력을 시도하니, 비어있고 그걸 채우기 위해 SELECT * FROM member WHERE id = 1;을 보낸다. 그렇게 게시글의 수만큼 반복하게 된다. → 3개의 쿼리가 발생, 이걸 N+1 문제라고 한다.

LAZY를 썼어도 이런 상황이 발생하면 EAGER처럼 성능을 떨어뜨린다. 그래서 쿼리가 많이 발생할 것 같은 상황엔 @EntityGraph를 붙여 한 번에 데이터를 들고오도록 한다.

 

 

 

 

---

 

 

 

 

@EntityGraph의 사용 이유

• 그니까 결론적으로 LAZY를 기본값으로 지정했더라도 가짜 객체를 진짜 객체로 데리고 올 때 N+1 문제가 발생하니 그걸 방지하고자 @EntityGraph를 사용한다.
• @EntityGraph를 적용한 메서드는, 해당 메서드가 호출될 때 LAZY 설정을 무시하고 SQL JOIN을 통해 실제 데이터를 한 번에 가져온다. 정적인 설정을 동적으로 변경한 것이다.

@Entity
public class Post {

    // 지연로딩 설정
    @ManyToOne(fetch = FetchType.LAZY)
    private Member member;
}

public interface PostRepository extends JpaRepository<Post, Long> {

    // member도 같이 데려와.
    @EntityGraph(attributePaths = {"member"})
    List<Post> findAll();
}

findAll( )인 특정 메서드를 실행할 때, @EntityGraph를 통해 member도 같이 데려오라고 작성했다. Post의 전체를 조회할 때 작성자 이름도 한 번에 오도록 한거니, left outer join member m on p.member_id = m.id; 쿼리가 발생하고 이 한 번의 쿼리로 끝난다.

attributePaths는 속성 경로를 지정한 것이다. 조회하고 싶은 연관 관계의 필드 이름을 attributePaths에 배열 형태로 넣기만 하면 된다. 지금 이 코드에서는 게시글을 작성한 작성자를 알고 싶은거니, 그 정보가 들어있을 Member를 지정했다.

위쪽 설명에 left outer join member m on p.member_id = m.id; 쿼리가 발생한다고 했는데, Left Outer Join 사용이 @EntityGraph의 주요 특징이다. 이 말을 쉽게 풀어서 설명하면 왼쪽 테이블은 모두 보여주고 오른쪽 테이블(연관데이터)은 있으면 가져오고 없으면 비워두라는 방식을 말한다. 그럼 왜 Left Outer Join을 사용하는걸까?

예를 들어서 3명의 학생이 간식을 신청했다고 가정하자. A 학생은 초코바, B 학생은 사탕, C 학생은 신청하지 않았다. 왼쪽 테이블엔 학생 A, B, C가 있고 오른쪽 테이블엔 A(초코바), B(사탕)이 있다. (C는 간식을 신청하지 않았으니 오른쪽 테이블엔 없다)

ineer join(내부 조인)은 [ 학생과 간식이 둘 다 있는 경우만 가져와 ]라서 결과적으로 A(초코바)와 B(사탕)만 나오고 C는 사라진다.
left outer join(왼쪽 외부 조인)은 [ 학생은 모두 보여줘. 대신 간식이 있으면 옆에 붙이고 없으면 null로 보여줘 ]라서  A(초코바), B(사탕), C(NULL)로 학생 3명 모두 유지된다. right outer join은 간식을 모두 보여주는거니까 C는 누락되게 된다.

이렇게 @EntityGraph가 왜 left outer join을 사용하는지 알게되었다. 그러니 왼쪽 테이블은 주인공을 배치해야한다. 해당 코드에선 게시글이 주인공이다. 게시글을 조회할건데, 작성자가 포함되어있으면 함께 보여줘라고 해야한다. 만약 @EntityGraph가 right outer join으로 사용하면 게시글을 조회하려고 한건데, 게시글을 작성하지 않은 멤버까지 모두 나올 수 있게 된다. 

 

 

Q. @EntityGraph는 언제 써야할까?

A. LAZY를 기본 값으로 설정한 곳에서 연관 데이터가 한꺼번에 필요할 때 해당 레포지토리 메서드에만 @EntityGraph를 사용하는게 좋다. 부모 엔티티를 조회할 때 자식 엔티티의 필드가 반드시 필요한 경우, 예를 들어서 주문 내역을 출력할 때 어떤 상품인지 리스트가 꼭 필요한 것과 같이 이런 식으로 무조건 엮여 있을 때 넣는게 좋다. 나중에 모니터링을 해보고 쿼리가 많이 나가는 걸 확인하면 그때 선택적으로 추가해도 좋다. 

 

 

Q. 주의해야할 점?

A. 중복 데이터이다. 만약 게시글 1개에 댓글이 3개가 달렸다고 가정하자. left join을 하면 결과 표에 게시글 제목이 3번 중복해서 나타나게 된다. 리스트로 받으면 데이터가 늘어날 수 있어서, 이런 경우 distinct 키워드를 사용하거나 Set 자료형을 써서 중복을 제거해야한다.