[JPA] 연관관계 컬렉션 필드 조회 최적화 : 엔티티/DTO 조회 방식

엔티티 조회 방식

XToOne 필드에 대하여 JOIN FETCH를 적용하고, 연관관계 컬렉션 필드(XToMany)에 대해서는 batch size를 설정하는 방법을 이용하여 엔티티 조회 방식에 최적화를 이뤄낼 수 있었다.

 

이는 JPA에서 제공해주는 기능을 적극적으로 활용한 로직이므로, 유지보수시에 코드를 거의 수정하지 않고 옵션만 약간 변경해서 적용해가며 다양한 성능 최적화를 시도할 수 있다.

 

/**
 * 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;
}

// paging : x
public List<Order> findAllWithMemberDelivery() {
    return em.createQuery(
            "select o from Order o" +
                    " join fetch o.member m" +
                    " join fetch o.delivery d", Order.class)
            .getResultList();
}

// paging : o
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();
}

spring:
  datasource:
#    url: jdbc:h2:tcp://localhost/~/jpashop
#    username: sa
#    password:
    driver-class-name: org.h2.Driver

  jpa:
    hibernate:
      ddl-auto: create
    properties:
      hibernate:
#        show_sql: true
        format_sql: true
        default_batch_fetch_size: 1000 #최적화 옵션 - 글로벌하게 적용

 

하지만 이 방식을 적용하여 엔티티 조회를 하여도 성능이 너무 느리다고 판단될 경우, DTO 조회 방식을 고려해볼 수 있다. DTO를 직접 조회하는 방식은 조금 더 성능이 최적화될 수 있는 여지가 있지만, 적용하거나 수정할 때 많은 양의 코드를 제어해야 하므로 유지보수성이 떨어진다.

 일반적인 경우, 극한의 성능 개선을 위한 코드는 대게 복잡하기 마련이다. 이는 코드 간에 강하게 결속되는 경향이 있어서 유지보수를 할 때에도 많은 코드를 수정해줘야 한다. 운동을 할 때에도 '고중량 고반복'은 없듯이, 항상 트레이드오프를 고려하면서 성능 최적화와 코드 복잡도 사이에서 줄타기를 잘 해야 한다.

 

DTO 직접 조회 방식

QueryDSL을 사용하지 않고 DTO를 직접 조회하기 위해선 JPQL에 new 연산자를 이용하여 DTO를 생성해줘서 받아줘야 한다.

 

V4

V4는 코드가 단순하다. 특정 주문 한건만 조회하면 이 방식을 사용해도 성능이 잘 나온다. 예를 들어서 조회한 Order 데이터가 1건이면 OrderItem을 찾기 위한 쿼리도 1번만 실행하면 된다.

@GetMapping("/api/v4/orders")
public List<OrderQueryDto> ordersV4() {
    return orderQueryRepository.findOrderQueryDtos();
}

/**
 * 컬렉션은 별도로 조회
 * Query: 루트 1번, 컬렉션 N 번
 * 단건 조회에서 많이 사용하는 방식
 */
public List<OrderQueryDto> findOrderQueryDtos() {
    //루트 조회(toOne 코드를 모두 한번에 조회)
    List<OrderQueryDto> result = findOrders();

    //루프를 돌면서 컬렉션 추가(추가 쿼리 실행)
    result.forEach(o -> {
        List<OrderItemQueryDto> orderItems = 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();
}

 

 

V5

V5는 코드가 복잡하다. 여러 주문을 한꺼번에 조회하는 경우에는 V4 대신에 이것을 최적화한 V5 방식을 사용해야 한다. 예를 들어서 조회한 Order 데이터가 1000건인데, V4 방식을 그대로 사용하면, 쿼리가 총 1 + 1000번 실행된다. 여기서 1은 Order 를 조회한 쿼리고, 1000은 조회된 Order의 row 수다. V5 방식으로 최적화 하면 쿼리가 총 1 + 1번만 실행된다. 상황에 따라 다르겠지만 운영 환경에서 100배 이상의 성능 차이가 날 수 있다.

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

/**
 * 최적화
 * Query: 루트 1번, 컬렉션 1번
 * 데이터를 한꺼번에 처리할 때 많이 사용하는 방식
 *
 */
public List<OrderQueryDto> findAllByDto_optimization() {

    //루트 조회(toOne 코드를 모두 한번에 조회 with fetch join)
    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));
}

 

V6

V6는 완전히 다른 접근방식이다. 쿼리 한번으로 최적화 되어서 상당히 좋아보이지만, Order를 기준으로 페이징이 불가능하다. 실무에서는 이정도 데이터면 수백이나, 수천건 단위로 페이징 처리가 꼭 필요하므로, 이 경우 선택하기 어려운 방법이다. 그리고 데이터가 많으면 중복 전송이 증가해서 V5와 비교해서 성능 차이도 미비하다.

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

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

 

결론

1. 엔티티 조회 방식으로 충분히 성능이 나오는지 우선 체크한다. 성능이 괜찮다면 구태여 DTO 직접 조회 방식을 적용하기보단, 유지보수성을 위해 엔티티 조회 방식 안에서 최적화를 이뤄내는 것이 적절할 수 있다.

2. 만약 성능이 너무 안나올 경우에는 DTO 직접 조회 방식을 고려해볼 수 있다. 이 때에는 여러 방식을 적용해볼 수 있으므로 단건 조회인지, 여러 건 조회인지 등 각 상황에 따라 적절하게 선택하는 것이 중요하다.

3. DTO 직접 조회로도 성능이 충분하지 않을 경우에는 개발 측면에서 해결해볼 수 있는 여지는 네이티브 SQL 또는 JDBC Template을 이용하는 것인데, 사실 위 방법들에서 최적화가 이루어져지 않은 경우에는 스키마 설계가 너무 복잡하거나 또는 트래픽이 너무 방대하여 Redis 등을 통해 인프라 측면에서 캐시를 도입하는 것이 더욱 적절할 수 있다.

캐시 구현 방식을 적용하는 경우, 하이버네이트 2차 캐시로 구현하는 것이 아니라 Redis 등을 통해 캐시를 구현한다면, 캐시에 올라가는 것 또한 엔티티가 아니라 반드시 Dto여야 한다. 영속성 컨텍스트에 의해 관리되는 엔티티가 캐시에 있으면 이 것이 지워지지 않아서 꼬이게 된다. 아울러 하이버네이트 2차 캐시는 실무 적용에 어려운 부분이 많아, 일반적으로 Redis 등을 통해 캐시를 구현하며, 이러한 경우 엔티티가 아니라 Dto를 올려야 한다.