API 개발 고급 - 지연 로딩과 조회 성능 최적화

실무에서 매우 중요함. 100% 이해를 목표로 공부할 것.

 

간단한 주문 조회 V1: 엔티티를 직접 노출

엔티티를 노출하면 양방향 연관관계 있는 부분에서 무한루프에 빠질 위험이 있다. (@JsonIgnore로 해결가능하긴함)

엔티티를 직접 노출하면 엔티티가 변경되었을 때 API의 스펙이 모두 바뀐다.

성능상에도 문제가 생긴다. 따라서, DTO로 변환해서 반환하는 것이 좋은 방법이다.

 

 

간단한 주문 조회 V2: 엔티티를 DTO로 변환

DTO를 생성하여 반환하는 값들을 선언하고 반환한다.

엔티티가 바뀌어도 API 스펙이 바뀔리가 없다.

 

그런데 V1과 V2 모두 LAZY_Loading으로 인한 쿼리가 너무 많이 호출된다는 문제가 있다.

-> N+1 문제가 발생함

 

 

간단한 주문 조회 V3: 엔티티를 DTO로 변환 - 페치 조인 최적화

public List<Order> findAllWithMemberDelivery() {
    return em.createQuery(
            "select o from Order o" +
                    " join fetch o.member m" +
                    " join fetch o.delivery d", Order.class
    ).getResultList();
}

V3에서는 위와 같은 fetch join을 이용했는데

V2는 주문내역조회를 위한 쿼리가 5번 호출되었으나

V3는 쿼리가 1번 호출되었다.

페치 조인은 100% 이해해야함.

실무에서 정말 많이 사용하는 기법.

 

 

간단한 주문 조회 V4: JPA에서 DTO로 바로 조회

V3는 페치조인된 엔티티를 모두 갖고오고

V4는 엔티티 중 내가 원하는 것 DTO만 갖고온다.

 

V3보다는 V4가 성능상 조금 좋지만 (*미비하다)

재사용성이 V3가 더 좋다.

두개는 우열을 가리기 힘들다.

 

권장하는 방법은 다음과 같다.

쿼리 방식 선택 권장 순서

1. 우선 엔티티를 DTO로 변환하는 방법을 선택한다.

2. 필요하면 페치 조인으로 성능을 최적화 한다. 대부분의 성능 이슈가 해결된다.

3. 그래도 안되면 DTO로 직접 조회하는 방법을 사용한다.

4. 최후의 방법은 JPA가 제공하는 네이티브 SQL이나 스프링 JDBC Template을 사용해서 SQL을 직접 사용한다.

---

인프런 김영한님의 JPA 활용2 편을 듣고 작성한 글입니다.

https://inf.run/rjf5

실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화 - 인프런 | 강의