[강의] 실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화 2

 

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81%EB%B6%80%ED%8A%B8-JPA-API%EA%B0%9C%EB%B0%9C-%EC%84%B1%EB%8A%A5%EC%B5%9C%EC%A0%81%ED%99%94/dashboard

실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화 - 인프런 | 강의

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

- 주문 조회 V1: 엔티티 직접 노출

@RestController
@RequiredArgsConstructor
public class OrderApiController {

    private final OrderRepository orderRepository;

    @GetMapping("/api/v1/orders")
    public List<Order> ordersV1(){
        List<Order> all = orderRepository.findAllByString(new OrderSearch());
        for (Order order : all) {
            order.getMember().getName();
            order.getDelivery().getAddress();
            List<OrderItem> orderItems = order.getOrderItems();
            orderItems.forEach(o -> o.getItem().getName());
        }
        return all;
    }
}

전부 lazy기 때문에 프록시를 강제 초기화 한 후 데이터를 뿌리게 함

결국 엔티티 직접 노출이라 별로

 

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

@RestController
@RequiredArgsConstructor
public class OrderApiController {

    /*생략*/

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

        return collect;
    }

    //@Data 가 너무 많으면 애매해서 안쓰는 게 나을 수도 있음
    @Getter
    static class OrderDto {
        private Long orderId;
        private String name;
        private LocalDateTime orderDate;
        private OrderStatus orderStatus;
        private Address address;
        private List<OrderItemDto> orderItems;
        //놓치기 위한 실수 : OrderItem도 DTO로 바꿔서 보내야함
        //private List<OrderItem> orderItems;

        public OrderDto(Order order){
            orderId = order.getId();
            name = order.getMember().getName();
            orderDate = order.getOrderDate();
            orderDate = order.getOrderDate();
            orderStatus = order.getStatus();
            address = order.getMember().getAddress();
            /*//이거 안쓰면 lazy라 아무것도 나오지 않음
            order.getOrderItems().stream().forEach(o -> o.getItem().getName());
            orderItems = order.getOrderItems();*/
            //-> OrderItem도 Dto로 변경
            orderItems = order.getOrderItems().stream()
                    .map(orderItem -> new OrderItemDto(orderItem))
                    .collect(Collectors.toList());

        }

    }

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

원하는 정보만 보이는 것을 알 수 있다.

지연 로딩이 많아서

Order 조회에 두개나옴

각 Order마다

멤버 한 명 조회

delivery 정보

Items 두개 조회

Items마다 Item 조회에 2번씩

...

SQL 쿼리가 조지게 많이 나감

딱 봐도 성능 뚝 떨어져 보임

 

- 주문 조회 V3: 엔티티를 DTO로 변환 - 패치 조인 최적화

@Repository
@RequiredArgsConstructor
public class OrderRepository {

    /*생략*/

    public List<Order> findAllWithItem() {
        return em.createQuery(
                "select 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();
    }
}

DB에서 일대다일때 다에 맞춰서 리턴하기 때문에 order 4개가 리턴된다 -> distinct를 추가하면 2개 리턴
사실 쿼리에서는 완전히 똑같아야 중복제거이므로, 여전히 4개가 나오지만,
JPA에서 자체적으로 distinct를 보면 중복을 걸러서 컬렉션에 담아준다.

distinct가 중복 조회를 막아준다

@RestController
@RequiredArgsConstructor
public class OrderApiController {
	/*생략*/
    @GetMapping("/api/v3/orders")
    public List<OrderDto> orderV3(){
        List<Order> orders = orderRepository.findAllWithItem();

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

        return collect;
	/*생략*/
    }
}

패치 조인으로 SQL이 한 번반 실행됨

 

하지만 단점, 일대다를 하는 순간 페이징이 불가능하다

.setFirstResult(1), .setMaxResults(100) : 1부터 100개 가져옴

WARN : firstResult/maxResults sepcified with collection fetch; applying in memory

Distinct된 결과 기준이 아닌, 뻥튀기 된 상태, order item을 기준으로 적용이 됨

적절한 개수를 불러올 수 없어 매우 위험함(ex) OutOfMemory), 페이징이 불가능함

 

또한 컬렉션 패치 조인은 한 번만 사용할 수 있다.

두개 이상 사용하게 되면 뻥튀기에 뻥튀기 해서 혼란을 일으킬 수 있음

 

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

@Repository
@RequiredArgsConstructor
public class OrderRepository {
	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();
    }

@RestController
@RequiredArgsConstructor
public class OrderApiController {

    /*생략*/

    @GetMapping("/api/v3/orders")
    public List<OrderDto> orderV3(){
        List<Order> orders = orderRepository.findAllWithItem();

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

        return collect;
    }

    @GetMapping("/api/v3.1/orders")
    public List<OrderDto> orderV3_page(
            @RequestParam(value = "offset" , defaultValue = 0) int offset,
            @RequestParam(value = "limit" , defaultValue = 100) int limit){
        //ToOne 관계까지만 뭉탱이로 한번에 가져온다
        List<Order> orders = orderRepository.findAllWithMemberDelivery(offset, limit);
        // 여기까지만 하면 1 + orders 루프 (2번 + 1) * (orderItems 1 + orderitem 2  * item 2)... 계산 다음에 마저 일단 열라 많음

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

        return collect;
    }
    /*생략*/
}

jpa.hibernate.properties.default_batch_fetch_size: 100  추가

 

100의 의미는 inquery의 개수를 몇개로 할 것인가

한 방에 100개를 다 땡겨온다

사이즈 : 고고익선 하지만 순간 부하를 견딜 수 있어야함 주로 100~1000 사이

1 + N + N문제 해결

 

데이터 양이 엄청 많아지면 오히려 한번에 전부 join해 가져오는 윗 방법보다 이 방법이 더 좋을 수 도 있다

결론 장점 : 

쿼리 호출 수가 1 + N -> 1 + 1 로 최적화
조인보다 DB 데이터 전송량이 최적화 , 중복된 데이터 전송 안해도 됨

패치 조인 방식과 비교해서 쿼리 호출 수가 약간 증가하지만, DB 데이터 전송량은 감소
컬렉션 페치 조인은 페이징 불가능 하지만 이 방법은 페이징 가능

 

- 주문 조회 V4: JPA에서 DTO 직접 조회

repository 새로 생성

@Repository
@RequiredArgsConstructor
public class OrderQueryRepository {
    private final EntityManager em;

    public List<OrderQueryDto> findOrderQueryDtos(){

        //컬렉션을 바로 넣을 수는 없음
        List<OrderQueryDto> result = findOrders();

        //컬렉션을 직접 채운다
        result.forEach(o ->{
            List<OrderItemQueryDto> orderItems = findOrderItems(o.getOrderId());
            o.setOrderItems(orderItems);
        });
        return result;
    }

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

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

 

@RestController
@RequiredArgsConstructor
public class OrderApiController {
    /*생략*/
	@GetMapping("/api/v4/orders")
	public List<OrderQueryDto> orderV4(){
    	return orderQueryRepository.findOrderQueryDtos();
	}
    /*생략*/
}

DTO 생성

@Data
public class OrderQueryDto {
    private Long orderId;
    private String name;
    private LocalDateTime orderDate;
    private OrderStatus orderStatus;
    private Address address;
    private List<OrderItemQueryDto> orderItems;

    public OrderQueryDto(Long orderId, String name, LocalDateTime orderDate, OrderStatus orderStatus, Address address) {
        this.orderId = orderId;
        this.name = name;
        this.orderDate = orderDate;
        this.orderStatus = orderStatus;
        this.address = address;
    }
}

@Data
public class OrderItemQueryDto {

    @JsonIgnore
    private Long orderId;
    private String itemName;

    private int orderPrice;
    private int count;

    public OrderItemQueryDto(Long orderId, String itemName, int orderPrice, int count) {
        this.orderId = orderId;
        this.itemName = itemName;
        this.orderPrice = orderPrice;
        this.count = count;
    }
}

결과는 뭐... 비슷

 

row 수가 증가하지 않는 ToOne 관계는 조인으로 최적화 하기 쉬우므로 한번에 조회하고, ToMany
관계는 최적화 하기 어려우므로 findOrderItems() 같은 별도의 메서드로 조회한다.

별도의 메서드를 쓰는 과정에서 N+1번 쿼리가 나가는 단점이 있음

 

- 주문 조회 V5: JPA에서 DTO 직접 조회 - 컬렉션 조회 최적화

@RestController
@RequiredArgsConstructor
public class OrderApiController {
    /*생략*/
	@GetMapping("/api/v5/orders")
    public List<OrderQueryDto> orderV5(){
        return orderQueryRepository.findAllByDto_optimization();
    }
    /*생략*/
}

@Repository
@RequiredArgsConstructor
public class OrderQueryRepository {
    public List<OrderQueryDto> findAllByDto_optimization(){
        List<OrderQueryDto> result = findOrders();

        List<Long> orderIds = result.stream().map(o -> o.getOrderId())
                .collect(Collectors.toList());

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

        //사용하기 편하게 맵 형식으로 변경
        Map<Long, List<OrderItemQueryDto>> orderItemMap = orderItems.stream()
                .collect(Collectors.groupingBy(orderItemQueryDto -> orderItemQueryDto.getOrderId()));

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

        return result;

    }
}

쿼리 두 번으로 최적화 가능

루트 1번, 컬렉션 1번

Map을 사용해서 매칭 성능 향상

 

- 주문 조회 V6: JPA에서 DTO 직접 조회, 플랫 데이터 최적화

쿼리 한번으로 해결 가능

@RestController
@RequiredArgsConstructor
public class OrderApiController {
    /*생략*/
	//쿼리가 한 번만 나감
    //하지만 join을 이용하기 때문에 다에 맞춰서 뿔려져 나옴
    //따라서 페이징을 못함
    //API 스펙이 안맞는 문제는 그냥 노가다로 발라내는 코드를 짜면 됨
    @GetMapping("/api/v6/orders")
    public List<OrderFlatDto> orderV6(){
        return orderQueryRepository.findAllByDto_flat();
    }
    /*생략*/
}

package jpabook.jpashop.repository.order.query;

import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Repository;

import javax.persistence.EntityManager;
import java.util.List;
import java.util.Map;
import java.util.stream.Collectors;

@Repository
@RequiredArgsConstructor
public class OrderQueryRepository {
    /*생략*/

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

직접 정리하는 코드(정리 안되어있음, 그냥 복붙)

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

 

그리고 OrderQueryDto에 @EqualsAndHashCode(of = orderId) 추가

orderId 기준으로 묶어줌

단 :

쿼리는 한번이지만 조인으로 인해 DB에서 애플리케이션에 전달하는 데이터에 중복 데이터가 추가

-> V5 보다 더 느릴 수 도
애플리케이션에서 추가 작업이 큼
페이징 불가능

 

- 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

 

5. API 개발 고급 - 실무 필수 최적화

- OSIV와 성능 최적화