#실전2 - 7 컬렉션 조회 최적화

API 개발 고급 - 컬렉션 조회 최적화

주문내역에서 추가로 주문한 상품 정보를 추가로 조회하자.

Order 기준으로 컬렉션인 OrderItem 와 Item 이 필요하다.

 

앞의 예제에서는 toOne(OneToOne, ManyToOne) 관계만 있었다.

이번에는 컬렉션인 일대다 관계 (OneToMany)를 조회하고, 최적화하는 방법을 알아보자

 

주문 조회 V1: 엔티티 직접 노출

package jpabook.jpashop.api;

import jpabook.jpashop.domain.Order;
import jpabook.jpashop.domain.OrderItem;
import jpabook.jpashop.repository.OrderRepository;
import jpabook.jpashop.repository.OrderSearch;
import lombok.RequiredArgsConstructor;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

import java.util.List;
/**
 * V1. 엔티티 직접 노출
 * - 엔티티가 변하면 API 스펙이 변한다.
 * - 트랜잭션 안에서 지연 로딩 필요
 * - 양방향 연관관계 문제
 *
 * V2. 엔티티를 조회해서 DTO로 변환(fetch join 사용X)
 * - 트랜잭션 안에서 지연 로딩 필요
 * V3. 엔티티를 조회해서 DTO로 변환(fetch join 사용O)
 * - 페이징 시에는 N 부분을 포기해야함(대신에 batch fetch size? 옵션 주면 N -> 1 쿼리로 변경
 가능)
 *
 * V4. JPA에서 DTO로 바로 조회, 컬렉션 N 조회 (1 + N Query)
 * - 페이징 가능
 * V5. JPA에서 DTO로 바로 조회, 컬렉션 1 조회 최적화 버전 (1 + 1 Query)
 * - 페이징 가능
 * V6. JPA에서 DTO로 바로 조회, 플랫 데이터(1Query) (1 Query)
 * - 페이징 불가능...
 *
 */
@RestController
@RequiredArgsConstructor
public class OrderApiController {

    private final OrderRepository orderRepository;
    /**
     * V1. 엔티티 직접 노출
     * - Hibernate5Module 모듈 등록, LAZY=null 처리
     * - 양방향 관계 문제 발생 -> @JsonIgnore
     */
    @GetMapping("/api/v1/orders")
    public List<Order> ordersV1(){
        List<Order> all = orderRepository.findAllByCriteria(new OrderSearch());
        for (Order order : all) {
            order.getMember().getName();//lazy 초기화
            order.getDelivery().getAddress();//lazy 초기화
            List<OrderItem> orderItems = order.getOrderItems();
            orderItems.stream().forEach(o -> o.getItem().getName());
            //주문과 관련된 orderItem를 가져와 루프를돌면서 아이템까지도 proxy 초기화
        }
        return all;
    }
}

hibernate5Module

· orderItem , item 관계를 직접 초기화하면 Hibernate5Module 설정에 의해 엔티티를 JSON으로 생성한다.

  -proxy를 강제 초기화 시켜줘야지 json이 얘는 뿌려야한다고 인식함

· 양방향 연관관계면 무한 루프에 걸리지 않게 한곳에 @JsonIgnore 를 추가해야 한다.

· 엔티티를 직접 노출하므로 좋은 방법은 아니다.

v1결과 orderItems가 보이지만 Entity가 외부로 노출됨

 

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

만만치 않은 부분이다 위로 치면 orderIteam도 dto로 변환 item도 dto로 변환해야하는 작업이 필요하다.

    @GetMapping("/api/v2/orders")
    public List<OrderDto> orderV2(){
        List<Order> orders = orderRepository.findAllByCriteria(new OrderSearch());
        List<OrderDto> collect = orders.stream().map(o -> new OrderDto(o))
                .collect(Collectors.toList());
        return collect;
    }

OrderApiController에 추가

OrderDto

    @Getter // 자바에서 properties가 없다고 하는 에러가나오면 거의 getter setter 이다.
    private class OrderDto {

        private Long orderId;
        private String name;
        private LocalDateTime orderDate;
        private OrderStatus orderStatus;
        private Address address;
        private List<OrderItem> orderItems;

        public OrderDto(Order order){
            orderId = order.getId();
            name = order.getMember().getName();
            orderDate = order.getOrderDate();
            orderStatus = order.getStatus();
            address =order.getDelivery().getAddress();
            orderItems = order.getOrderItems();

        }

    }

여기서 이렇게까지만하면 orderItems가 null로 나온다.

orderItems가 null이 나오는 이유는 OrderItems가 Entity였기 때문이라고 생각하여DTO안에 order를 래핑시켜주었다.

 

해당처럼 item의 proxy를 초기화 시켜주니 null이아닌값이 나온다.

 

Dto 생성자안에서 entity 래핑으로인해 결과는 획득..

하지만 이렇게 DTO안에는 Entity가 있으면 안된다. Entity에 대한 의존을 완전히 끊어야한다.

OrderItem 조차도 다 Dto로 바꾸어야한다.

 

모든 Entity Dto로 변환

package jpabook.jpashop.api;

import jpabook.jpashop.domain.Address;
import jpabook.jpashop.domain.Order;
import jpabook.jpashop.domain.OrderItem;
import jpabook.jpashop.domain.OrderStatus;
import jpabook.jpashop.repository.OrderRepository;
import jpabook.jpashop.repository.OrderSearch;
import lombok.Data;
import lombok.Getter;
import lombok.RequiredArgsConstructor;
import org.springframework.data.domain.jaxb.SpringDataJaxb;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

import java.time.LocalDateTime;
import java.util.List;
import java.util.stream.Collectors;

/**

 * V2. 엔티티를 조회해서 DTO로 변환(fetch join 사용X)
 * - 트랜잭션 안에서 지연 로딩 필요
 */
@RestController
@RequiredArgsConstructor
public class OrderApiController {

    private final OrderRepository orderRepository;


    @GetMapping("/api/v2/orders")
    public List<OrderDto> orderV2(){
        List<Order> orders = orderRepository.findAllByCriteria(new OrderSearch());
        List<OrderDto> collect = orders.stream().map(o -> new OrderDto(o))
                .collect(Collectors.toList());
        return collect;
    }

    @Getter // 자바에서 properties가 없다고 하는 에러가나오면 거의 getter setter 이다.
    static class OrderDto {

        private Long orderId;
        private String name;
        private LocalDateTime orderDate;
        private OrderStatus orderStatus;
        private Address address;
        private List<OrderItemDto> orderItems; //OrderItem -> OrderItemDto

        public OrderDto(Order order){
            orderId = order.getId();
            name = order.getMember().getName();
            orderDate = order.getOrderDate();
            orderStatus = order.getStatus();
            address =order.getDelivery().getAddress();
            //order.getOrderItems().stream().forEach(o -> o.getItem().getName());
            // DTO안에는 Entity가 있으면 안된다 Enity와의 의존을 아에 끊어야한다.
            orderItems = order.getOrderItems().stream()
                    .map(orderItem -> new OrderItemDto(orderItem))
                    .collect(Collectors.toList());

        }

    }
    @Getter
    static class OrderItemDto{
        //나는 상품명만 필요해 라는 요구조건
        private String itemName;
        private int orderPrice;
        private int count;

        public OrderItemDto(OrderItem orderItem) {
            itemName = orderItem.getItem().getName();
            orderPrice = orderItem.getOrderPrice();
            count = orderItem.getCount();
        }
    }
}

value Object를 제외한 Entity는 외부로 노출하면 안된다.!!

 

· 지연 로딩으로 너무 많은 SQL 실행

· SQL 실행 수

    · order 1번

    · member , address N번(order 조회 수 만큼)

    · orderItem N번(order 조회 수 만큼)

    · item N번(orderItem 조회 수 만큼)

 

참고: 지연 로딩은 영속성 컨텍스트에 있으면 영속성 컨텍스트에 있는 엔티티를 사용하고 없으면 SQL을 실행한다. 따라서 같은 영속성 컨텍스트에서 이미 로딩한 회원 엔티티를 추가로 조회하면 SQL을 실행하지 않는다.

 

 

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

@GetMapping("/api/v3/orders")
public List<OrderDto> ordersV3() {
     List<Order> orders = orderRepository.findAllWithItem();
     List<OrderDto> result = orders.stream()
         .map(o -> new OrderDto(o))
         .collect(toList());
     return result;
}

 

OrderRepository에 추가

    public List<Order> findAllWithItem() {
        return em.createQuery("select 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).getResultList();
    }

현재는 일대다 구조이기때문에 다만큼 ROW가 검출되어 중복된 데이터가나온다.

중복된 데이터가 나온다.,

findAllWithItem method의 query에 distinct추가 

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)
             .getResultList();
}

중복 제거

· 페치 조인으로 SQL이 1번만 실행됨

· distinct 를 사용한 이유는 1대다 조인이 있으므로 데이터베이스 row가 증가한다.

  그 결과 같은 order 엔티티의 조회 수도 증가하게 된다.

  DB의 distinct는 row가 완전 똑같아야 중복이 제거가 되지만!

  JPA의 distinct는 SQL에 distinct를 추가하고, 더해서 같은 엔티티가 조회되면, 애플리케이션에서 중복을 걸러준다.

  이 예에서 order가 컬렉션 페치 조인 때문에 중복 조회 되는 것을 막아준다.

· 단점

    · 페이징 불가능

 

 

참고: 컬렉션 페치 조인을 사용하면 페이징이 불가능하다. 하이버네이트는 경고 로그를 남기면서 모든 데이터를 DB에서 읽어오고, 메모리에서 페이징 해버린다(매우 위험하다). 1:N 패치조인에서는 페이징하면안된다 1:N가 아니면 상관없다.

자세한 내용은 자바 ORM 표준 JPA 프로그래밍의 페치 조인 부분을 참고하자.

참고: 컬렉션 페치 조인은 1개만 사용할 수 있다. 컬렉션 둘 이상에 페치 조인을 사용하면 안된다. 데이터가 부정합하게 조회될 수 있다. 자세한 내용은 자바 ORM 표준 JPA 프로그래밍을 참고하자.

 

 

 

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

페이징과 한계 돌파

· 컬렉션을 페치 조인하면 페이징이 불가능하다.

    · 컬렉션을 페치 조인하면 일대다 조인이 발생하므로 데이터가 예측할 수 없이 증가한다.

    · 일다대에서 일(1)을 기준으로 페이징을 하는 것이 목적이다. 그런데 데이터는 다(N)를 기준으로 row 가 생성된다.

    · Order를 기준으로 페이징 하고 싶은데, 다(N)인 OrderItem을 조인하면 OrderItem이 기준이 되어버린다.

    · (더 자세한 내용은 자바 ORM 표준 JPA 프로그래밍 - 페치 조인 한계 참조)

· 이 경우 하이버네이트는 경고 로그를 남기고 모든 DB 데이터를 읽어서 메모리에서 페이징을 시도한다.

  최악의 경우 장애로 이어질 수 있다

 

 

한계 돌파

그러면 페이징 + 컬렉션 엔티티를 함께 조회하려면 어떻게 해야할까?

지금부터 코드도 단순하고, 성능 최적화도 보장하는 매우 강력한 방법을 소개하겠다. 대부분의 페이징 + 컬렉션 엔티티 조회 문제는 이 방법으로 해결할 수 있다.

 

· 먼저 ToOne(OneToOne, ManyToOne) 관계를 모두 페치조인 한다. ToOne 관계는 row수를 증가시키지 않으므로

  페이징 쿼리에 영향을 주지 않는다.

findAllWithItem에서 to one 관계는 member와 delivery이다. orderItems같은 경우에는 toMany로간다음에 orderItem이랑 item끼리 하는거기 때문에 패치조인을 하면 안된다.

· 컬렉션은 지연 로딩으로 조회한다.

· 지연 로딩 성능 최적화를 위해 hibernate.default_batch_fetch_size(글로벌로 세팅) , @BatchSize(특정 엔티티에 세팅) 를 적용한다.         

    · hibernate.default_batch_fetch_size: 글로벌 설정

    · @BatchSize: 개별 최적화

    · 이 옵션을 사용하면 컬렉션이나, 프록시 객체를 한꺼번에 설정한 size 만큼 IN 쿼리로 조회한다.

 

 

findAllWithMemberDelivery(int offset, int limit) 추가

@Repository
public class OrderRepository {
   public List<Order> findAllWithMemberDelivery(int offset, int limit) {
   return em.createQuery(
           "select o from Order o" +
               " join fetch o.member m" +
               " join fetch o.delivery d", Order.class)
               .setFirstResult(offset)
               .setMaxResults(limit)
           .getResultList();
   }
}

이건 페이징이 가능하다 toOne 관계인 Member와 delivery만 패치 조인했기 때문이다.    

/**
 * V3.1 엔티티를 조회해서 DTO로 변환 페이징 고려
 * - ToOne 관계만 우선 모두 페치 조인으로 최적화
 * - 컬렉션 관계는 hibernate.default_batch_fetch_size, @BatchSize로 최적화
 */
@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(toList());
       return result;
       
}

1:N 자체가 지연로딩이기때문에 페이징이 잘된다.

최적화 옵션

spring:
 jpa:
   properties:
     hibernate: //bibernate 전용 속성 넣는곳
       default_batch_fetch_size: 1000

위와같이 설정하면

 

toOne관계 호출했을시 쿼리 /(만약 offset이 0이면 hibernate가 알아서 지운다. 0이면 계산할 필요가 없기 떄문.)

    select
        order0_.order_id as order_id1_6_0_,
        member1_.member_id as member_i1_4_1_,
        delivery2_.delivery_id as delivery1_2_2_,
        order0_.delivery_id as delivery4_6_0_,
        order0_.member_id as member_i5_6_0_,
        order0_.order_date as order_da2_6_0_,
        order0_.status as status3_6_0_,
        member1_.city as city2_4_1_,
        member1_.street as street3_4_1_,
        member1_.zipcode as zipcode4_4_1_,
        member1_.name as name5_4_1_,
        delivery2_.city as city2_2_2_,
        delivery2_.street as street3_2_2_,
        delivery2_.zipcode as zipcode4_2_2_,
        delivery2_.status as status5_2_2_ 
    from
        orders order0_ 
    inner join
        member member1_ 
            on order0_.member_id=member1_.member_id 
    inner join
        delivery delivery2_ 
            on order0_.delivery_id=delivery2_.delivery_id limit ?

    select
        item0_.item_id as item_id2_3_0_,
        item0_.name as name3_3_0_,
        item0_.price as price4_3_0_,
        item0_.stock_quantity as stock_qu5_3_0_,
        item0_.artist as artist6_3_0_,
        item0_.etc as etc7_3_0_,
        item0_.author as author8_3_0_,
        item0_.isbn as isbn9_3_0_,
        item0_.actor as actor10_3_0_,
        item0_.director as directo11_3_0_,
        item0_.dtype as dtype1_3_0_ 
    from
        item item0_ 
    where
        item0_.item_id in (
            ?, ?, ?, ?
        )

collection의 정보를 조회한 것을 자신도 알고있어서 collection과 관련된 orders 애들의 orderItems미리 IN쿼리로 다날려서 한번에 다가져온다 default_batch_fetch_size: 100    이라는 숫자가 인쿼리를 몇개 날릴거냐고 묻는 것이다.

그리고 ITEM은 userA 2개 userB 2개를 LAZY LOADING을 통해 4번의 쿼리가 나갓는데 이옵션을통해 한번에 가져옴.

1:N:M이 1:1:1이 되버리는 정도의 최적화가 된다.

 

· 개별로 설정하려면 @BatchSize 를 적용하면 된다. (컬렉션은 컬렉션 필드에, 엔티티는 엔티티 클래스에 적용)

컬렉션에 적용

orderItem에서 item은 toOne관계 이기때문에 Entity에 설정한다

엔티티 클래스에 적용

하지만 주로 글로벌에 거의 적용한다.

 

· 장점

    · 쿼리 호출 수가 1 + N → 1 + 1 로 최적화 된다.

    · 조인보다(v3) DB 데이터 전송량이 최적화 된다. (Order와 OrderItem을 조인하면 Order가 OrderItem 만큼

     중복해서 조회된다. 이 방법은 각각 조회하므로 전송해야할 중복 데이터가 없다.)

     - 데이터 양이적은경우에는 네트워크를 여러번타는 v3로 해도되지만 데이터 양이 많다면 V3.1로 하는게 좋다.

    · 페치 조인 방식과 비교해서 쿼리 호출 수가 약간 증가하지만, DB 데이터 전송량이 감소한다.

    · 컬렉션 페치 조인은 페이징이 불가능 하지만 이 방법은 페이징이 가능하다.

· 결론

    · ToOne 관계는 페치 조인해도 페이징에 영향을 주지 않는다. 따라서 ToOne 관계는 페치조인으로 쿼리 수를

      줄이고 해결하고, 나머지는 hibernate.default_batch_fetch_size 로 최적화 하자.

 

참고: default_batch_fetch_size 의 크기는 적당한 사이즈를 골라야 하는데, 100~1000 사이를 선택하는 것을 권장한다. 이 전략을 SQL IN 절을 사용하는데, 데이터베이스에 따라 IN 절 파라미터를 1000으로 제한하기도 한다. 1000으로 잡으면 한번에 1000개를 DB에서 애플리케이션에 불러오므로 DB 에 순간 부하가 증가할 수 있다. 10개로 했다고 가정했을때 DB랑 applicaiton이랑 10개씩주고 받지만 부하가 준다 하지만 시간은 더오래걸린다. 결국 애플리케이션은 100이든 1000이든 !!결국 전체 데이터를 로딩!!해야 하므로 메모리 사용량이 같다. 1000으로 설정하는 것이 성능상 가장 좋지만, 결국 DB든 애플리케이션이든 순간 부하를 어디까지 견딜 수 있는지로 결정하면 된다.

 

 

주문 조회 V4: JPA에서 DTO 직접 조회

@GetMapping("/api/v4/orders")
public List<OrderQueryDto> ordersV4() {
 return orderQueryRepository.findOrderQueryDtos();
}
package jpabook.jpashop.repository.order.query;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Repository;
import javax.persistence.EntityManager;
import java.util.List;
import java.util.Map;
import java.util.stream.Collectors;
@Repository
@RequiredArgsConstructor
public class OrderQueryRepository {
 private final EntityManager em;
 /**
 * 컬렉션은 별도로 조회
 * Query: 루트 1번, 컬렉션 N 번
 * 단건 조회에서 많이 사용하는 방식
 */
 public List<OrderQueryDto> findOrderQueryDtos() {
     //루트 조회(toOne 코드를 모두 한번에 조회)
     List<OrderQueryDto> result = findOrders(); //Query 1번 ->N개
     //루프를 돌면서 컬렉션 추가(추가 쿼리 실행)
     result.forEach(o -> {List<OrderItemQueryDto> orderItems //Query N번
                             = findOrderItems(o.getOrderId());
                             o.setOrderItems(orderItems);
     });
     return result;
 }
 
 
 /**
 * 1:N 관계(컬렉션)를 제외한 나머지를 한번에 조회
 */
 private List<OrderQueryDto> findOrders() {
     return em.createQuery(
             "select new
            jpabook.jpashop.repository.order.query.OrderQueryDto(o.id, m.name, o.orderDate,
                    o.status, d.address)" +
                     " from Order o" +
                     " join o.member m" +
                     " join o.delivery d", OrderQueryDto.class)
             .getResultList();
 }
 
 /**
 * 1:N 관계인 orderItems 조회
 */
 private List<OrderItemQueryDto> findOrderItems(Long orderId) {
   return em.createQuery(
         "select new jpabook.jpashop.repository.order.query.OrderItemQueryDto(oi.order.id, i.name,
            oi.orderPrice, oi.count)" +
             " from OrderItem oi" +
             " join oi.item i" +
             " where oi.order.id = : orderId",
       	 OrderItemQueryDto.class)
         .setParameter("orderId", orderId)
         .getResultList();
   }
}

OrderQueryRepository

package를 나누는 이유

OrderRepository는 Order Entity를 조회하거는 용도를쓰고(핵심비지니스 용)

query는 화면이나 API에 의존관계가 있는것을 때어내기 위해만듬(특정화면에 FIT한 것들은 내보냄)

 

장점

-화면과 관련되있는 것은 생각보다 쿼리랑 밀접한 경우가 많다고 중요한 핵심비지니스는 OrderRepository를 참조해서 사용할 수 있다.

-서로다른 라이프사이클의 관심사를 분리할 수 있다.

 

OrderDto를 안쓰고 OrderQueryDto를 쓰는 이유

OrderAPI에 있는 OrderDto를 안쓰는이유 참조해버리면 Repository가 Controller를 참조하는 의존관계가 순환이된다.
그리고 findOrderQueryDtos가 만드는 거니깐 OrderQueryDto가 알아야해서 같은 패키지에 넣음

OrderQueryDto 

 

package jpabook.jpashop.repository.order.query;
import jpabook.jpashop.domain.Address;
import jpabook.jpashop.domain.OrderStatus;
import lombok.Data;
import lombok.EqualsAndHashCode;
import java.time.LocalDateTime;
import java.util.List;


@Data
@EqualsAndHashCode(of = "orderId")
public class OrderQueryDto {
     private Long orderId;
     private String name;
     private LocalDateTime orderDate; //주문시간
     private OrderStatus orderStatus;
     private Address address;
     private List<OrderItemQueryDto> orderItems;
     
     public OrderQueryDto(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;
 	}

OrderItemQueryDto

package jpabook.jpashop.repository.order.query;
import com.fasterxml.jackson.annotation.JsonIgnore;
import lombok.Data;

@Data
public class OrderItemQueryDto {
     @JsonIgnore
     private Long orderId; //주문번호
     private String itemName;//상품 명
     private int orderPrice; //주문 가격
     private int count; //주문 수량
 
     public OrderItemQueryDto(Long orderId, String itemName, int orderPrice, int
              count) {
               this.orderId = orderId;
               this.itemName = itemName;
               this.orderPrice = orderPrice;
               this.count = count;
       }
}

· Query: 루트 1번, 컬렉션 N 번 실행

· ToOne(N:1, 1:1) 관계들을 먼저 조회하고, ToMany(1:N) 관계는 각각 별도로 처리(루프를 돌면서 처리)한다.

    · 이런 방식을 선택한 이유는 다음과 같다.

    · ToOne 관계는 조인해도 데이터 row 수가 증가하지 않는다.

    · ToMany(1:N) 관계는 조인하면 row 수가 증가한다. (함부로 조인해서 가져올 수 없다.)

· row 수가 증가하지 않는 ToOne 관계는 조인으로 최적화 하기 쉬우므로 한번에 조회하고,

 ToMany 관계는 최적화 하기 어려우므로 findOrderItems() 같은 별도의 메서드로 조회한다.

 

 

과정

1. List<OrderItemQueryDto> orderItems제거 

List<OrderItemQueryDto> orderItems제거 

2. jpql를 짜더라도 바로 collection을 넣을 수는 없기때문에 collection제거

jpql를 짜더라도 바로 collection을 넣을 수는 없기때문에 collection제거

new operation을 쓸땐 sql 처럼 쓸뿐인데 그냥 DTO를 할뿐이라서 데이터를 플랫하게 한줄뿐이 못넣는데

orderItems를 넣게되면 일대다이기때문에 DATA가 뻥튀기된다. 그래서 이렇게 쿼리를 날리고끝을 낸다.

 

3. orderItems를 넣어주기위해서 method 분리

4. orderItems를 넣어주기위해 findOrderItem method를 만들어 일대다 에서 '다'부분을 해결하기위해 쿼리를통해 가져온 orderItems를 OrderQueryDto에 추가

 

 

주문 조회 V5: JPA에서 DTO 직접 조회 - 컬렉션 조회 최적화(쿼리 N+1 해결)

@GetMapping("/api/v5/orders")
public List<OrderQueryDto> ordersV5() {
   return orderQueryRepository.findAllByDto_optimization();
}

//OrderQueryRepository에 추가
/**
 * 최적화
 * Query: 루트 1번, 컬렉션 1번
 * 데이터를 한꺼번에 처리할 때 많이 사용하는 방식
 *
 */
public List<OrderQueryDto> findAllByDto_optimization() {
   //루트 조회(toOne 코드를 모두 한번에 조회)
   List<OrderQueryDto> result = findOrders();
   
   //orderItem 컬렉션을 MAP 한방에 조회
   Map<Long, List<OrderItemQueryDto>> orderItemMap =
   findOrderItemMap(toOrderIds(result));
   
   //루프를 돌면서 컬렉션 추가(추가 쿼리 실행X)
   result.forEach(o -> o.setOrderItems(orderItemMap.get(o.getOrderId())));
   return result;
}

private List<Long> toOrderIds(List<OrderQueryDto> result) {
   return result.stream()
   .map(o -> o.getOrderId())
   .collect(Collectors.toList());
}

private Map<Long, List<OrderItemQueryDto>> findOrderItemMap(List<Long> orderIds) {
   List<OrderItemQueryDto> orderItems = em.createQuery(
       "select new
            jpabook.jpashop.repository.order.query.OrderItemQueryDto(oi.order.id, i.name,
            oi.orderPrice, oi.count)" +
             " from OrderItem oi" +
             " join oi.item i" +
             " where oi.order.id in :orderIds", OrderItemQueryDto.class)
       .setParameter("orderIds", orderIds)
       .getResultList();
       
   return orderItems.stream()
  				 .collect(Collectors.groupingBy(OrderItemQueryDto::getOrderId));
}

refactoring전

· Query: 루트 1번, 컬렉션 1번 (쿼리 두번 호출로 해결)

· ToOne 관계들을 먼저 조회하고, 여기서 얻은 식별자 orderId로 ToMany 관계인 OrderItem 을 한꺼번에 조회

· MAP을 사용해서 매칭 성능 향상(O(1))

 

여기서드는 의문이 직접 JPQL을 DTO로 하는게 마냥 편하지만은 않다. -> 많은 코드를 직접작성하기 때문 

그렇지만 장점이 이전 fetch join들보단 데이터 조회양이 줄어든다.

 

 

주문 조회 V6: JPA에서 DTO로 직접 조회, 플랫 데이터 최적화(쿼리한번으로 해결)

OrderFlatDto 생성

OrderFlatDto class 생성

package jpabook.jpashop.repository.order.query;
import jpabook.jpashop.domain.Address;
import jpabook.jpashop.domain.OrderStatus;
import lombok.Data;
import java.time.LocalDateTime;

@Data
public class OrderFlatDto {
     private Long orderId;
     private String name;
     private LocalDateTime orderDate; //주문시간
     private Address address;
     private OrderStatus orderStatus;
     private String itemName;//상품 명
     private int orderPrice; //주문 가격
     private int count; //주문 수량
 
 public OrderFlatDto(Long orderId, String name, LocalDateTime orderDate,
          OrderStatus orderStatus, Address address, String itemName, int orderPrice, int
          count) {
          
     this.orderId = orderId;
     this.name = name;
     this.orderDate = orderDate;
     this.orderStatus = orderStatus;
     this.address = address;
     this.itemName = itemName;
     this.orderPrice = orderPrice;
     this.count = count;
     
 }
 
}

findAllByDto_flat생성

    select
        order0_.order_id as col_0_0_,
        member1_.name as col_1_0_,
        order0_.order_date as col_2_0_,
        order0_.status as col_3_0_,
        delivery2_.city as col_4_0_,
        delivery2_.street as col_4_1_,
        delivery2_.zipcode as col_4_2_,
        item4_.name as col_5_0_,
        orderitems3_.order_price as col_6_0_,
        orderitems3_.count as col_7_0_ 
    from
        orders order0_ 
    inner join
        member member1_ 
            on order0_.member_id=member1_.member_id 
    inner join
        delivery delivery2_ 
            on order0_.delivery_id=delivery2_.delivery_id 
    inner join
        order_item orderitems3_ 
            on order0_.order_id=orderitems3_.order_id 
    inner join
        item item4_ 
            on orderitems3_.item_id=item4_.item_id

이쿼리를 그대로실해아하면 중복을 포함해서 나갈수 밖에 없다.일대다 조인을 했기때문에 중복 생성

 

 

 

@GetMapping("/api/v6/orders")
public List<OrderQueryDto> ordersV6() {
     List<OrderFlatDto> flats = orderQueryRepository.findAllByDto_flat();
     return flats.stream()
     			.collect(groupingBy(o -> new OrderQueryDto(o.getOrderId(),
   						 o.getName(), o.getOrderDate(), o.getOrderStatus(), o.getAddress()),
   				 mapping(o -> new OrderItemQueryDto(o.getOrderId(),
    			o.getItemName(), o.getOrderPrice(), o.getCount()), toList())
   				)).entrySet().stream()
    				.map(e -> new OrderQueryDto(e.getKey().getOrderId(),
                    e.getKey().getName(), e.getKey().getOrderDate(), e.getKey().getOrderStatus(),
                    e.getKey().getAddress(), e.getValue()))
   				  .collect(toList());
}


//OrderQueryRepository
public List<OrderFlatDto> findAllByDto_flat() {
 return em.createQuery(
       "select new
      jpabook.jpashop.repository.order.query.OrderFlatDto(o.id, m.name, o.orderDate,
      o.status, d.address, i.name, oi.orderPrice, oi.count)" +
       " from Order o" +
       " join o.member m" +
       " join o.delivery d" +
       " join o.orderItems oi" +
       " join oi.item i", OrderFlatDto.class)
       .getResultList();
}

· 장점

     · Query: 1번

    · 중복된 쿼리로 페이징은 가능..   결국 안되는거랑 다름없음 ..

· 단점

    · 쿼리는 한번이지만 조인으로 인해 DB에서 애플리케이션에 전달하는 데이터에 중복 데이터가 추가되므로

      상황에 따라 V5 보다 더 느릴 수 도 있다.(데이터가 많을경우)

    · 애플리케이션에서 추가 작업이 크다.(위에 stream을 쓴것처럼 분해를 해야하기때문에)

    · 페이징 불가능 -> order를 기준으로 데이터 중복이 되기때문에 페이징이 안된다. orderItem 기준은 가능

    · V5와 같은 API 스팩으로 반환해야하면 노가다를 해야함... 

 

 

API 개발 고급 정리

정리

· 엔티티 조회

    ·  엔티티를 조회해서 그대로 반환: V1

    · 엔티티 조회 후 DTO로 변환: V2

    · 페치 조인으로 쿼리 수 최적화: V3

    · 컬렉션 페이징과 한계 돌파: V3.1

         · 컬렉션은 페치 조인시 페이징이 불가능

         · ToOne 관계는 페치 조인으로 쿼리 수 최적화

         · 컬렉션은 페치 조인 대신에 지연 로딩을 유지하고, hibernate.default_batch_fetch_size

            , @BatchSize 로 최적화

· DTO 직접 조회

    · JPA에서 DTO를 직접 조회: V4

    · 컬렉션 조회 최적화 - 일대다 관계인 컬렉션은 IN 절을 활용해서 메모리에 미리 조회해서 최적화: V5

    · 플랫 데이터 최적화 - JOIN 결과를 그대로 조회 후 애플리케이션에서 원하는 모양으로 직접 변환: V6

 

 

권장 순서

1. 엔티티 조회 방식으로 우선 접근

    1. 페치조인으로 쿼리 수를 최적화

    2. 컬렉션 최적화

        1. 페이징 필요 hibernate.default_batch_fetch_size , @BatchSize 로 최적화

        2. 페이징 필요X →페치 조인 사용

2. 엔티티 조회 방식으로 해결이 안되면 DTO 조회 방식 사용

3. DTO 조회 방식으로 해결이 안되면 NativeSQL or 스프링 JdbcTemplate

 

 

참고: 엔티티 조회 방식은 페치 조인이나, hibernate.default_batch_fetch_size , @BatchSize 같이 코드를

 거의 수정하지 않고, 옵션만 약간 변경해서, 다양한 성능 최적화를 시도할 수 있다. 반면에 DTO를 직접

 조회하는 방식은 성능을 최적화 하거나 성능 최적화 방식을 변경할 때 많은 코드를 변경해야 한다

 

참고: 개발자는 성능 최적화와 코드 복잡도 사이에서 줄타기를 해야 한다. 항상 그런 것은 아니지만,

        보통 성능 최적화는 단순한 코드를 복잡한 코드로 몰고간다.

 

엔티티 조회 방식은 JPA가 많은 부분을 최적화 해주기 때문에, 단순한 코드를 유지하면서, 성능을 최적화 할 수 있다.

 

반면에 DTO 조회 방식은 SQL을 직접 다루는 것과 유사하기 때문에, 둘 사이에 줄타기를 해야 한다.

 

 

DTO 조회 방식의 선택지

· DTO로 조회하는 방법도 각각 장단이 있다. V4, V5, V6에서 단순하게 쿼리가 1번 실행된다고

  V6이 항상 좋은 방법인 것은 아니다.

 

· V4는 코드가 단순하다. 특정 주문 한건만 조회하면 이 방식을 사용해도 성능이 잘 나온다.

  예를 들어서 조회한 Order 데이터가 1건이면 OrderItem을 찾기 위한 쿼리도 1번만 실행하면 된다.

 

· V5는 코드가 복잡하다. 여러 주문을 한꺼번에 조회하는 경우에는 V4 대신에 이것을 최적화한

  V5 방식을 사용해야 한다. 예를 들어서 조회한 Order 데이터가 1000건인데, V4 방식을 그대로 사용하면,

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

  여기서 1은 Order 를 조회한 쿼리고, 1000은 조회된 Order의 row 수다. V5 방식으로 최적화 하면 쿼리가

  총 1 + 1번만 실행된다. 상황에 따라 다르겠지만 운영 환경에서 100배 이상의 성능 차이가 날 수 있다.

 

· V6는 완전히 다른 접근방식이다. 쿼리 한번으로 최적화 되어서 상당히 좋아보이지만,

  Order를 기준으로 페이징이 불가능하다. 실무에서는 이정도 데이터면 수백이나, 수천건 단위로 페이징 처리가

  꼭 필요하므로, 이 경우 선택하기 어려운 방법이다. 그리고 데이터가 많으면 중복 전송이 증가해서 V5와 비교해서

  성능 차이도 미비하다.