주문 조회 V3.1: 엔티티를 DTO로 변환 - 페이징과 한계 돌파

결론 ToOne 관계는 페치 조인해도 페이징에 영향을 주지 않는다. =>ToOne 관계는 페치조인으로 쿼리 수를 줄이고 해결하고, 나머지는 hibernate.default_batch_fetch_size 로 최적화 하자.

정리 fetch join로 한번에 데이터 조획가능하지만 컬렉션은 fetch join을 사용하면 페이징을 하지 못하기 때문에 컬렉션을 지연로딩으로 하되, N+1 문제를 방지하기 위해 batch size를 설정함으로써 한계를 극복한다!

xToOne은 fetch join을 해도 데이터를 증가시키지 않기 때문에 Order와 연관된 xToOne 관계인 member, delivery는 fetch join을 해도 된다!

fetch join을 계속하더라도 데이터, row가 증가하는 게 아니라 하나의 row에 옆으로 member, delivery 이런 식으로 늘어나는 것이기 때문이다.

하지만 일대다 관계인 orderItems(oi)와 이 oi와 연관된 item은 fetch join 하면 안된다‼️ =>컬렉션은 지연 로딩으로 조회한다!(fetch join❌)

지연 로딩 성능 최적화를 위해 hibernate.default_batch_fetch_size , @BatchSize 를 적용한다.

hibernate.default_batch_fetch_size: 글로벌 설정
@BatchSize: (엔티티)개별 최적화
이 옵션을 사용하면 컬렉션이나, 프록시 객체를 한꺼번에 설정한 size 만큼 IN 쿼리로 조회한다.

보통 N+1 문제는 하나씩 가져오기 때문에 발생한다. 하지만 batch size를 적용하면 이 크기만큼 미리 가져온다!

public List<Order> findAllWithItem() {
    return em.createQuery(
            "select distinct o from Order o" +
                    " join fetch o.member m" +
                    " join fetch o.delivery d" +
                    " join fetch o.orderItems oi" +
                    " join fetch oi.item i", Order.class)//order와 orderItems를 조인! ex) 주문 한건에 주문상품 4개면 조인하면 결과는 4개가 된다.
            .getResultList();
}

N+1, SQL 쿼리 분석

findAllWithMemberDelivery 전체 쿼리(creatQuery)
Member와 Dlivery fetch join

주문1 : 3개

OrderItems 컬렉션 조회
orderItem1 > Item
orderItem2 > Item

주문2 : 3개

OrderItems 컬렉션 조회
orderItem1 > Item
orderItem2 > Item

@GetMapping("/api/v3.1/orders")
public List<OrderDto> ordersV3_page() {
    List<Order> orders = orderRepository.findAllWithMemberDelivery();

    List<OrderDto> result = orders.stream()
            .map(o -> new OrderDto(o))
            .collect(Collectors.toList());
    return result;
}

batch size = 100개 설정한 후 SQL 분석 : 총 3개의 SQL

findAllWithMemberDelivery 전체 쿼리(createQuery)
OrderItems 컬렉션 조회 : userA, userB의 orderItems를 한번에 들고옴.
Item 조회 : userA 주문 상품>item 2개, userB 주문 상품>item 2개 => 4개를 한번에 들고옴.

List<Order> orders 컬렉션과 관련된 것들을 in 쿼리로 가져온다.//batch size 1xNxM => 1x1x1 =>웬만한 경우 원하는 성능이 나온다! 하지마나 실시간으롤 더 빠른 조회 서비스를 제공하고자 한다면 Redis 캐시 사용하거나 DB의 한줄씩 normalization(정규화)

@GetMapping("/api/v3.1/orders")
public List<OrderDto> ordersV3_page(
        @RequestParam(value="offset",defaultValue = "0") int offset,
        @RequestParam(value="limit",defaultValue = "100") int limit) {

    List<Order> orders = orderRepository.findAllWithMemberDelivery(offset,limit);

    List<OrderDto> result = orders.stream()
            .map(o -> new OrderDto(o))
            .collect(Collectors.toList());
    return result;
}

이전 버전에 비해 쿼리는 1번 => 3번으로 되려 증가했지만, 이렇게 batch size를 설정함으로써 페이징과 성능 최적화를 동시에 할 수 있다!

이전 버전 : SQL 한번으로 원하는 데이터들 한번에 가져올 수 있지만 중복 데이터가 많음! 일대다 관계에서 join하면 '다'를 기준으로 join하기 때문에 데이터가 늘어난다! =>DB에서 에플리케이션으로 이 많은 양의 데이터들이 전송된다!!!용량+++++

장단점이 있다. 단건 조회인 경우 데이터 양이 별로 없으면 fetch join이 성능에 이로울 수 있다. 하지만 데이터를 한번에 1000개 이상씩 조회할 때 fetch join으로 한번에 하는 것보다 쿼리가 몇 번 더 나가더라도 이 방법이 더 좋을 수도 있다.

xToOne 관계 : join fetch 자체를 생략해도 된다?! => order, member, delivery 각각 따로 조회하기 때문에 네트워크를 더 많이 탄다! =>따라서 xToOne 관계는 join fetch으로 미리 잡는 게 좋다!(Member, Dlivery 에 나가는 쿼리 줄일 수 있다!) =>default_batch fetch size에 의해 개선된다!

개별로 설정하려면 @BatchSize 를 적용하면 된다. (컬렉션은 컬렉션 필드에, 엔티티는 엔티티 클래스에 적용) ⭐️Order 클래스에서 List<OrderItem> 컬렉션 필드에 @BatchSize(size=100)이에요! xToOne 관계인경우 가장 상위 클래스에 @BatchSize 적용 (현업에서는 주로 전체 설정으로 많이 함.)

Previous주문 조회 V3: 엔티티를 DTO로 변환 - 페치 조인 최적화 NextRepository와 API 분리2

Last updated 3 years ago