[jpa] 컬렉션 조회 최적화 - 2

컬렉션 조회 최적화 - 1 에서는 엔티티를 조회한 후에 DTO로 변환시키는 방식으로 하였지만,

이번 챕터에서는 JPA 에서 DTO를 직접 조회하는 방식으로 진행한다.

 

JPA에서 DTO 직접 조회

DTO를 조회할 때, ToOne 관계들을 먼저 조회하고 ToMany 관계들은 별도로 처리하는 방식이 좋다.ToOne 관계를 먼저 처리하는 이유는 Row  수에 영향을 주지 않기 때문이다.하지만 ToMany 관계는 Row수를 증가시키므로(데이터 뻥튀기) 별도로 처리하는 편이 좋다.

 

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

위의 코드에서 findOrder() 메소드를 통해 주문들을 모두 조회한다.

주문들을 모두 조회하는 이유는 엔티티와 주문은 ToOne 관계이기 때문이다.

 

주문 아이템들은 별도로 처리해주었는 데 이 역시 위에서 설명한대로 ToMany 관계이기 때문에 별도로 처리하였다.

 

public List<OrderQueryDto> findOrderQueryDtos() {
//루트 조회(toOne 코드를 모두 한번에 조회)
List<OrderQueryDto> result = findOrders();
//루프를 돌면서 컬렉션 추가(추가 쿼리 실행)
result.forEach(o -> {
List<OrderItemQueryDto> orderItems =
findOrderItems(o.getOrderId());
o.setOrderItems(orderItems);
});
ret

 

이렇게 조회된 결과들을 DTO에 매핑시켰다.

 

하지만 이렇게 하면, id 를 조회할때 쿼리 1번이 발생하고 그 뒤로 컬렉션을 조회할 때 쿼리 N번이 발생하므로 

1+N 문제가 생긴다. 

따라서 최적화가 필요하다.

 

JPA에서 DTO 직접 조회 - 컬렉션 조회 최적화

기존의 루프를 돌면서 조회했던 방식을 Map 자료구조를 이용함으로써 1+N 문제를 개선할 수 있다.

 

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

기존 코드와 다른 점은 파라미터로 주문Id (식별자) 가 담긴 리스트를 넘겨줬다는 것이다.

이렇게 함으로써 기존 루프 쿼리가 아닌 in쿼리를 통해 아이템 정보가 담긴 데이터들을 한번에 가져올 수 있다.

 

그리고 이렇게 불러온 데이터들을 Map 을 이용하여 메모리에 적재한다.

 

result.forEach(o -> o.setOrderItems(orderItemMap.get(o.getOrderId())));

마지막으로 DTO 에 매핑시킬 때, 이미 메모리에 적재되있는 상태이므로 추가 쿼리가 발생하지 않는다.

 

이렇게 함으로써 루트 쿼리에서 1번 , 컬렉션 조회할 때 1번만 쿼리가 발생하므로 1+N 문제를 해결할 수 있다.

 

JPA에서 DTO로 직접 조회, 플랫 데이터 최적화

쿼리를 한번만 날려서 필요한 데이터들을 모두 가져오는 방법으로 , 위와는 다른 접근 방식이다.

 

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

먼저 조회할 데이터들을 "모두" 가져온다.

 

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

그 다음 이처럼 어플리케이션 단계에서 API 스펙에 맞게 추가 작업을 해주어야한다.

보기만 해도 어지럽다 ..

 

이 방법은 여러가지 단점이 있다.

1. 모든 데이터를 필터링 없이 가져오기 때문에 중복 데이터가 발생한다.     

    중복 데이터까지 함께 가져오므로 쿼리는 줄었지만 오히려 성능은 저하될 수 있다..

2. 어플리케이션 단계에서 추가 작업을 해줘야한다. 

3. 페이징이 안된다!      

    주문 하나(1)당 여러개(N)의 데이터들이 딸려오는데 여기서 페이징을 하면 (N)을 기준으로 페이징이 된다.