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

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

• 컬렉션을 페치 조인하면 페이징이 불가능 하다.
  • 컬렉션을 페치 조인하면 일대다 조인이 발생하므로 데이터가 예측할 수 없이 증가한다.
  • 일대다에서 일을 기준으로 페이징을 하는 것이 목적이다. 그런데 데이터는 다(N)를 기준으로 row가 생성된다.
  • Order를 기준으로 페이징 하고 싶은데, 다(N) 인 OrderItem을 조인하면 OrderItem이 기준이 되어버린다.
• 이 경우 하이버네이트는 경고 로그를 남기고 모든 DB데이터를 읽어서 메모리에서 페이징을 시도한다. 최악의 경우 장애로 이어질 수 있다..

한계 돌파

그러면 페이징 + 컬렉션 엔티티를 함께 조회하려면 어떻게 해야할까? 대부분의 페이징 + 컬렉션 엔티티 조회 문제는 다음 방법으로 해결 할 수 있다.

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

hibernate.default_batch_fetch_size : 글로벌 설정

application.yml

jpa:  
  hibernate:  
    ddl-auto: create  
  properties:  
    hibernate:  
      #show_sql: true  
      format_sql: true  
      dialect: org.hibernate.dialect.H2Dialect  
      default_batch_fetch_size: 100 # 페이징 ..

@GetMapping("/api/v3.1/orders")  
public List<OrderDto> orderV3_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(OrderDto::new)  
            .collect(Collectors.toList());  
    return result;  
}

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

이런식으로 컨트롤러와 레퍼지토리를 사용하면…

쿼리가 총 3번이 나간다.

보면 order, member, delevery 는 컬랙션 관계가 아니니깐 처음에 join 해서 다 가져오고, 나머지 컬렉션은 fetch 이기 때문에 원래라면 엄청나게 쿼리가 많이 나가야 하는데, default_batch_fetch_size: 100 옵션 때문에 in 쿼리로 where문에 다 들어가게 된다. 이러면 pk 인덱스로 조회하는 것이기 때문에 조회 속도도 빠르다. ? 갯수가 많은 것은 hibernate 버전마다 최적화 방법이 달라서 그렇다고 한다.

아무튼 저 3 쿼리를 직접 db에 날려보면 진짜 최적화 (중복이 없는) 쿼리들만 딱딱 나오게 된다.

• 장점
  • 쿼리 호출 수가 1 + N → 1 + 1로 최적화 된다.
  • 조인보다 DB 데이터 전송량이 최적화 된다. (Order와 OrderItem을 조인하면 Order가 OrderItem 만큼 중복해서 조회된다. 이 방법은 각각 조회하므로 전송해야 할 중복 데이터가 없다.)
  • 페치 조인 방식과 비교해서 쿼리 호출 수가 약간 증가하지만, DB 데이터 전송량이 감소한다.
  • 컬렉션 페치 조인은 페이징이 불가능 하지만, 이 방법은 페이징이 가능하다.
• 결론
  • ToOne 관계는 페치 조인에도 페이징에 영향을 주지 않는다. 따라서 ToOne 관계는 페치조인으로 쿼리 수를 줄이고 해결하고, 나머지는 hibernate.default_batch_fetch_size 로 최적화 하자.

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