지연 로딩과 조회 성능 최적화

  • XtoOne(ManyToOne, OneToOne) 관계 최적화

  • Order

  • Order -> Member

  • Order -> Delivery

  • 모든 연관관계는 지연로딩(LAZY)으로 설정 되어있음.

주문 조회 - V1

@RestController
@RequiredArgsConstructor
@RequestMapping("/api")
public class OrderSimpleApiController {

    private final OrderRepository orderRepository;
    private final OrderSimpleQueryRepository orderSimpleQueryRepository;

    @GetMapping("/v1/simple-orders")
    public List<Order> ordersV1() {
        List<Order> all = orderRepository.findAllByString(new OrderSearch());
        for (Order order : all) {
            order.getMember().getName();//Lazy 강제 초기화
            order.getDelivery().getAddress();//Lazy 강제 초기화
        }
        return all;
    }
}

  • 조회 V1 - 엔티티를 직접 노출

    • 엔티티를 직접 노출할 때는 양방향 연관관계가 걸린 곳은 한곳을 @JsonIgnore처리 해야한다.(안 그러면 양쪽을 서로 호출하면서 무한 루프)

    • 엔티티를 API 응답으로 외부로 노출하는 것은 좋지 않다. DTO로 변환해서 반환하는 것이 더 좋은 방법이다.

    • 지연 로딩(LAZY)을 피하기 위해 즉시 로딩(EAGER)으로 설정하면 안 된다.

      • 즉시 로딩 때문에 연관관계가 필요 없는 경우에도 데이터를 항상 조회해서 성능 문제가 발생할 수 있다.

      • 즉시 로딩으로 설정하면 성능 튜닝이 매우 어려워진다.

      • 항상 지연 로딩을 기본으로 하고, 성능 최적화가 필요한 경우에 페치 조인(fetch join)을 사용하자.

주문 조회 - V2

@GetMapping("/v2/simple-orders")
public List<SimpleOrderDto> ordersV2() {
    return orderRepository.findAllByString(new OrderSearch())
                          .stream()
                          .map(SimpleOrderDto::new)
                          .toList();
}

@Data
static class SimpleOrderDto {
    private Long orderId;
    private String name;
    private LocalDateTime orderDate;
    private OrderStatus orderStatus;
    private Address address;


    public SimpleOrderDto(Order order) {
        orderId = order.getId();
        name = order.getMember().getName();//지연 로딩
        orderDate = order.getOrderDate();
        orderStatus = order.getStatus();
        address = order.getDelivery().getAddress();//지연 로딩
    }
}

  • 조회 V2 - 엔티티를 DTO로 변환

    • 엔티티를 DTO로 변환하는 가장 일반적인 방법이다.

    • 쿼리가 총 1 + N + N번 실행된다.

      • order 조회 1번(여기서 조회 결과 수가 N이 된다.)

      • order -> member 지연 로딩 조회 N번

      • order -> delivery 지연 로딩 조회 N번

      • 예를 들어 order의 결과가 4개면 최악의 경우 1 + 4 + 4번 실행된다.

        • 지연로딩은 영속성 컨텍스트에서 조회하므로, 이미 조회된 경우 쿼리를 생략할 수 있다.(같은 회원이 있는 경우)

주문 조회 - V3

@GetMapping("/v3/simple-orders")
public List<SimpleOrderDto> ordersV3() {
    return orderRepository.findAllWithMemberDelivery()
                          .stream()
                          .map(SimpleOrderDto::new)
                          .toList();
}

@Data
static class SimpleOrderDto {
    private Long orderId;
    private String name;
    private LocalDateTime orderDate;
    private OrderStatus orderStatus;
    private Address address;


    public SimpleOrderDto(Order order) {
        orderId = order.getId();
        name = order.getMember().getName();//지연 로딩
        orderDate = order.getOrderDate();
        orderStatus = order.getStatus();
        address = order.getDelivery().getAddress();//지연 로딩
    }
}
@Repository
@RequiredArgsConstructor
public class OrderRepository {

    private final EntityManager em;

    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 - 엔티티를 DTO로 변환, 페치 조인 최적화

    • 엔티티를 페치 조인(fetch join)을 사용해서 쿼리 1번에 조회한다.

    • 페치 조인으로 order -> member, order -> delivery는 이미 조회 된 상태이므로 지연로딩을 하지 않는다.

주문 조회 - V4

@GetMapping("/v4/simple-orders")
    public List<OrderSimpleQueryDto> ordersV4() {
        return orderSimpleQueryRepository.findOrderDtos();
    }
@Repository
@RequiredArgsConstructor
public class OrderSimpleQueryRepository {

    private final EntityManager em;

    public List<OrderSimpleQueryDto> findOrderDtos() {
        return  em.createQuery(
            "select new jpabook.jpashop.repository.simpleQuery.OrderSimpleQueryDto(o.id, m.name, o.orderDate, o.status, d.address)" +
            " from Order o" +
            " join o.member m" +
            " join o.delivery d", OrderSimpleQueryDto.class)
                .getResultList();
    }
}

  • 전용 레포지토리

@Data
public class OrderSimpleQueryDto {
    
    private Long orderId;
    private String name;
    private LocalDateTime orderDate;
    private OrderStatus orderStatus;
    private Address address;
    
    public OrderSimpleQueryDto(Long orderId, String name, LocalDateTime orderDate,
                               OrderStatus orderStatus, Address address) {
        this.orderId = orderId;
        this.name = name;
        this.orderDate = orderDate;
        this.orderStatus = orderStatus;
        this.address = address;
    }
}

  • 조회 V4 - JPA에서 DTO로 바로 조회

    • 일반적인 SQL을 사용할 때처럼 원하는 값만 선택해서 조회한다.

    • new 명령어를 사용해서 JPQL의 결과를 DTO로 바로 변환한다.

    • SELECT절에서 원하는 데이터를 직접 선택하므로 DB -> 애플리케이션 네트워크 용량을 최적화할 수 있지만 생각보다는 미비하다.

    • 단점

      • 레포지토리 재사용성이 떨어진다.(V3 방식은 다른 곳에서도 재사용할 수 있다.)

      • API 스펙에 맞춘 코드가 레포지토리에 들어간다.(패키지를 분리해서 사용하는 것 추천)

정리

엔티티를 DTO로 변환하거나 DTO로 바로 조회하는 방법은 각각 장단점이 있다. 둘중 상황에 따라서 더 나은 방법을 선택하면 된다. 엔티티로 조회하면 레포지토리 재사용성도 좋고, 개발도 단순해진다.

쿼리 방식 선택 권장 순서

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

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

  3. 그래도 안되면 DTO로 직접 조회하는 방법을 선택한다.(V4)

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

PreviousOSIV(Open Session In View)NextJPA를 활용한 웹 애플리케이션 개발

Last updated