API 개발 - 컬렉션 조회(페치 조인의 페이징 한계 돌파)

• 주문 내역에서 추가로 주문한 상품 정보를 조회한다. 
• 하나의 주문에 상품은 여러 개가 있을 수 있으므로 xToMany형태의 컬렉션 조회가 될 것이다.
• 지금까지 게시글로 원하는 API 반환을 위해서는 API 스펙에 맞춰 DTO 클래스를 설계하여 반환해야한다는 것을 알고 있다는 가정 하, DTO로 변환하여 반환하는 코드로 작성
• 조건 : API 반환으로 원하는 조건은 { 주문 번호, 사용자 이름, 주문 날짜, 주문 상태, 배송지 정보, 주문한 상품 정보} 이다. 이 스펙에 맞춰 DTO를 개발해야한다.

 

위 조건에 대해

1. < API 스펙에 맞는 DTO 설계 API 개발 > : 엔티티에 의존하는 API 개발 한계 해결

2. < DTO + 페치 조인 API 개발 > : DTO 개발 설계 시 발생하는 비효율성 한계 해결

까지 진행했다. 하지만 2번으로 진행할 시 컬렉션 조회의 경우 페이징 처리가 불가능했다.

 

페치 조인으로 API 컬렉션 개발을 할 경우 페이징 처리가 불가능하다는 것은 페치 조인을 사용하면 안된다는 뜻이고,

페치 조인을 사용하지 않으면 전처럼 1+N 문제가 발생하여 매우 비효율적이게 된다.

(1+N 문제가 무엇인지 알 수 있는 게시글)

https://wonsjung.tistory.com/424?category=1024251 

API 개발 : 간단한 주문 조회 (지연 로딩)

이번 게시글을 통해 1+N문제가 발생하지 않으면서 페이징 처리를 할 수 있는 방법에 대해 알아본다.

---

 

페이징과 한계 돌파

• 컬렉션을 페치 조인하면 페이징이 불가능하다.
  • 컬렉션을 페치 조인하면 일대다 조인이 발생하므로 데이터가 예측할 수 없이 증가한다.
  • 일대다에서 일(1)을 기준으로 페이징을 하는 것이 목적이다. 그런데 데이터는 다(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 쿼리로 조회한다.

 

즉, 지연로딩을 하게 되면 원하는 정보를 모두 담기 위해 각각에 테이블에 쿼리문을 날리게 된다.

1 <-> N <-> M 이렇게 연관관계가 있다고 가정해보자. 우리가 원하는 정보를 얻기 위해서는 1테이블을 시작으로 해서 M 테이블까지 정보를 가져와야한다.

그럼 1개를 가져오기 위한 쿼리문을 날리고, 그 안에 정보와 연관이 있는 N개의 정보를 위해 N개의 쿼리문을 날리고, 또 N과 연관관계가 있는 M개의 정보를 가져오기 위해 M개의 쿼리문을 날려야한다. (1 + N + M)문제가 발생하게 된다.

 

이것을 BatchSize를 통해 한 번에 설정한 size만큼 끌어가져오는 것이다. 만약 size가 max(N, M)보다 클 경우에는 쿼리문 한 번에 모든 정보를 IN 쿼리로 가져오는 것이다.

ex) N이 1000이고 size가 100이면 10번의 IN쿼리로 가져오는 것이다.

 

 

 

이를 구현하는 방법은

 

< OrderApiController class >

@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;
    }
}

 

< OrderRepository class >

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

    }

이렇게 우리가 원하는 크기를 @RequestParam을 통해 설정해주고 쿼리문에도 등록해주는 것이다.

 

 

< 최적화 옵션 - application.yml >

spring:
    jpa:
        properties:
            hibernate:
                default_batch_fetch_size: 1000

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

 

---

• 장점
  • 쿼리 호출 수가 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든 애플리케이션이든 순간 부하를 어디까지 견딜 수 있는지로 결정하면 된다.