컬렉션 조회 최적화 (OneToMany)

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

v3, v3.1 사용하자

dto 조회 방식은 다루지 않는다

페이징 필요 없는 경우 -> v3

페이징 필요한 경우 -> v3.1

 

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

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

        return result;
    }

    @Data
    static class OrderDto{
        private Long orderId;
        private String name;
        private LocalDateTime orderDate;
        private OrderStatus orderStatus;
        private Address address;
        private List<OrderItemDto> orderItems;

        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());
            orderItems = order.getOrderItems().stream()
                    .map(orderItem -> new OrderItemDto(orderItem))
                    .collect(Collectors.toList());
        }
    }

    @Data
    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();
        }
    }

• 지연 로딩으로 너무 많은 SQL 실행
• SQL 실행 수
  
  • order 1번
  • member , address N번(order 조회 수만큼)
  • orderItem N번(order 조회 수만큼)
  • item N번(orderItem 조회 수만큼)

 

> 참고: 지연 로딩은 영속성 컨텍스트에 있으면 영속성 컨텍스트에 있는 엔티티를 사용하고 없으면 SQL을 실행한다. 

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

 

 

▶ 주문 조회 V3: 엔티티를 DTO로 변환 - 페치 조인 최적화 - 페이징 안 할 때만 사용할 것

v2와 다른 점은 repository에서 조회할 때 distinct를 사용하고 fetch조인을 사용했다는 것뿐.

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

        return result;
    }

    @Data
    static class OrderDto{
        private Long orderId;
        private String name;
        private LocalDateTime orderDate;
        private OrderStatus orderStatus;
        private Address address;
        private List<OrderItemDto> orderItems;

        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());
            orderItems = order.getOrderItems().stream()
                    .map(orderItem -> new OrderItemDto(orderItem))
                    .collect(Collectors.toList());
        }
    }

    @Data
    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();
        }
    }

repository

   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 엔티티의 조회 수도 증가하게 된다. JPA의 distinct는 SQL에 distinct를 추가하고, 더해서 같은 엔티티가 조회되면, 애플리케이션에서 중복을 걸러준다. 이 예에서 order가 컬렉션 페치 조인 때문에 중복 조회되는 것을 막아준다.

 

단점

★★★★★페이징 불가능★★★★★

oneToMany를 fetch조인하는 순간 페이징이 안된다. 치명적 단점. - 중복 데이터가 나오기 때문

 

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

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

 

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

 

 

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

• 컬렉션을 페치 조인하면 페이징이 불가능하다.
  
  • 컬렉션을 페치 조인하면 일대다 조인이 발생하므로 데이터가 예측할 수 없이 증가한다.
  • 일대다에서 일(1)을 기준으로 페이징을 하는 것이 목적이다. 그런데 데이터는 다(N)를 기준으로 row가 생성된다.
  • Order를 기준으로 페이징 하고 싶은데, 다(N)인 OrderItem을 조인하면 OrderItem이 기준이 되어버린다.
  • (더 자세한 내용은 자바 ORM 표준 JPA 프로그래밍 - 페치 조인 한계 참조)

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

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

 

한계 돌파

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

지금부터 코드도 단순하고, 성능 최적화도 보장하는 매우 강력한 방법을 소개하겠다. 

대부분의 페이징 + 컬렉션 엔티티 조회 문제는 이 방법으로 해결할 수 있다.

• 먼저 ToOne(OneToOne, ManyToOne) 관계를 모두 페치 조인한다. ToOne 관계는 row 수를 증가시키지 않으므로 페이징 쿼리에 영향을 주지 않는다.
• 컬렉션은 지연 로딩으로 조회한다. (페치 조인 사용 x)
• 지연 로딩 성능 최적화를 위해 hibernate.default_batch_fetch_size , @BatchSize를 적용한다.
  
  • hibernate.default_batch_fetch_size: 글로벌 설정  <<<< yml 파일 설정
  • @BatchSize: 개별 최적화
  • 이 옵션을 사용하면 컬렉션이나, 프락시 객체를 한꺼번에 설정한 size 만큼 IN 쿼리로 조회한다.

controller

    @GetMapping("/api/v3.1/orders")
    public List<OrderDto> ordersV3_page(
            @RequestParam(value = "offset", defaultValue = "0") int offset,
            @RequestParam(value = "limit", defaultValue = "100") int limit)
            {
        // ToOne 관계만 먼저 가져옴
        List<Order> orders = orderRepository.findAllWithMemberDelivery(offset, limit);

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

        return result;
    }

 

repository

xToOne 만 페치 조인 처리

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", Order.class)
                .setFirstResult(offset)
                .setMaxResults(limit)
                .getResultList();
    }

 

ToMany 처리

-> properties.yml

spring:
  jpa:
    properties:
      hibernate:
        default_batch_fetch_size: 100 # 페이징 최적화 'in' query를 사용해서 지연로딩을 초기화 시켜준다

지연 로딩 초기화를 위해 N+1 문제를 가진 쿼리가 호출되는 것을 IN 쿼리를 사용해 fectch_size 만큼의 in 쿼리 데이터를 불러와 처리해 해결

size 100~1000 개 설정 가능 (max 1000)

 

 

xToMany에게는 멤버 변수에 / ToOne에게는 class 자체에 

@BatchSize(size = 1000)

붙여서 사용 가능 -> but global 설정으로 yml 설정으로 사용

 

 

장점

• 쿼리 호출 수가 1 + N 1 + 1로 최적화된다.
• 조인보다 DB 데이터 전송량이 최적화된다. (Order와 OrderItem을 조인하면 Order가 OrderItem 만큼 중복해서 조회된다. 이 방법은 각각 조회하므로 전송해야 할 중복 데이터가 없다.)
• 페치 조인 방식과 비교해서 쿼리 호출 수가 약간 증가하지만, DB 데이터 전송량이 감소한다.
• 컬렉션 페치 조인은 페이징이 불가능 하지만 이 방법은 페이징이 가능하다.

 

결론

ToOne 관계는 페치 조인해도 페이징에 영향을 주지 않는다. 

따라서 ToOne 관계는 페치 조인으로 쿼리 수를 줄이고 해결하고, 나머지는 hibernate.default_batch_fetch_size 로 최적화 하자.

 

> 참고: default_batch_fetch_size의 크기는 적당한 사이즈를 골라야 하는데, 100~1000 사이를 선택하는 것을 권장한다.

이 전략을 SQL IN 절을 사용하는데, 데이터베이스에 따라 IN 절 파라미터를 1000으로 제한하기도 한다. 1000으로 잡으면 한 번에 1000개를 DB에서 애플리케이션에 불러오므로 DB에 순간 부하가 증가할 수 있다.

하지만 애플리케이션은 100이든 1000이든 결국 전체 데이터를 로딩해야

하므로 메모리 사용량이 같다. 1000으로 설정하는 것이 성능상 가장 좋지만, 결국 DB든 애플리케이션이든

순간 부하를 어디까지 견딜 수 있는지로 결정하면 된다.

 

 

 

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와 비교해서 성능 차이도 미비하다.