실전 스프링 부트와 JPA 활용2 정리

이상훈·2023년 5월 8일
JPASpring
0

Jpa

목록 보기
16/16

김영한님의 인프런 강의 '실전! 스프링 부트와 JPA 활용2'을 참고했습니다.

이 포스팅의 예제들은 위 엔티티 분석 그림을 따릅니다.


지연 로딩과 조회 성능 최적화 - XXToOne

❗️ 위 엔티티 분석 그림에서 Order를 조회할때(Member, Order, Delivery만 고려)

문제상황

@GetMapping("/api/v2/simple-orders")
public List<SimpleOrderDto> ordersV2() {
	List<Order> orders = orderRepository.findAll();
	List<SimpleOrderDto> result = orders.stream()
		.map(o -> new SimpleOrderDto(o))
		.collect(toList());
	return result;
}

@Data
static class SimpleOrderDto {
	private Long orderId;
	private String name;
	private LocalDateTime orderDate; //주문시간
	private OrderStatus orderStatus;
	private Address address;
	
    public SimpleOrderDto(Order order) {
		orderId = order.getId();
 		name = order.getMember().getName();
 		orderDate = order.getOrderDate();
 		orderStatus = order.getStatus();
 		address = order.getDelivery().getAddress();
	}
}

보통 이런식으로 API를 짜는 편이다. 하지만 쿼리가 총 1 + N + N번 실행되는 N+1문제가 발생하며 이는 경우에 따라 어플리케이션에 심각한 장애를 일으킨다.

1 + N + N

  • order 조회 1번
  • order -> member 지연 로딩 조회 N번
  • order -> delivery 지연 로딩 조회 N번

1. Entity로 바로 조회(using Fetch join)

@GetMapping("/api/v3/simple-orders")
public List<SimpleOrderDto> ordersV3() {
	List<Order> orders = orderRepository.findAllWithMemberDelivery();
	List<SimpleOrderDto> result = orders.stream()
		.map(o -> new SimpleOrderDto(o))
		.collect(toList());
	return result;
}

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

엔티티(Order)를 페치 조인(fetch join)을 사용해서 쿼리 1번에 조회했다. 그 다음 Dto로 변환하는데 페치 조인으로 member, delivery는 이미 조회 된 상태이므로 추가 쿼리가 나가지 않는다. 따라서 N + 1문제가 발생하지 않는다.


2. DTO로 바로 조회

@GetMapping("/api/v4/simple-orders")
public List<OrderSimpleQueryDto> ordersV4() {
	return orderSimpleQueryRepository.findOrderDtos();
}


public List<OrderSimpleQueryDto> findOrderDtos() {
	return em.createQuery(
		"select new	jpabook.jpashop.repository.order.simplequery.OrderSimpleQueryDto(o.id, m.name,
o.orderDate, o.status, d.address)" +
		" from Order o" +
		" join o.member m" +
		" join o.delivery d", OrderSimpleQueryDto.class)
	.getResultList();
}

new 명령어를 사용해서 JPQL의 결과를 DTO로 즉시 변환한다. SELECT 절에서 원하는 데이터를 직접 선택하므로 애플리케이션 네트워크 용량을 최적화할 수 있다(생각보다 미비). 하지만 리포지토리 재사용성이 떨어지고 API 스펙에 맞춘 코드가 리포지토리에 들어가는 단점이 존재한다.

따라서 만약 DTO로 즉시 반환할 경우에는 아래와 같이 따로 패키지를(simplequery) 만들어서 관리하는것이 좋다.


지연 로딩과 조회 성능 최적화 - XXToMany

❗️ 위 엔티티 분석 그림에서 Order를 조회할때(Member, Order, Delivery + OrderItem + Item)

문제상황

@GetMapping("/api/v2/orders")
public List<OrderDto> ordersV2() {
	List<Order> orders = orderRepository.findAll();
	List<OrderDto> result = orders.stream()
		.map(o -> new OrderDto(o))
		.collect(toList());
        
	return result;
}

@Data
static class OrderDto {

	private Long orderId;
	private String name;
	private LocalDateTime orderDate; //주문시간
	private OrderStatus orderStatus;
	private Address address;
	private List<OrderItemDto> orderItems;
    
	public OrderDto(Order order) {
		orderId = order.getId();
		name = order.getMember().getName();
		orderDate = order.getOrderDate();
		orderStatus = order.getStatus();
		address = order.getDelivery().getAddress();
		orderItems = order.getOrderItems().stream()
			.map(orderItem -> new OrderItemDto(orderItem))
			.collect(toList());
	}
}

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

지연로딩으로 너무 많은 SQL이 실행된다.

N + 1 문제

  • order 조회 1번
  • member, delivery 지연 로딩 조회 N번
  • orderItem 지연 로딩 조회 N번
  • item 지연 로딩 조회 N번

1. entity로 바로 조회(페치 조인 최적화)

@GetMapping("/api/v3/orders")
public List<OrderDto> ordersV3() {
	List<Order> orders = orderRepository.findAllWithItem();
	List<OrderDto> result = orders.stream()
		.map(o -> new OrderDto(o))
		.collect(toList());

	return result;
}

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

페치 조인으로 SQL이 1번만 실행된다. 여기서 중요한점은 query를 작성할때 distinct를 사용했다는 점이다. distinct를 사용한 이유는 1대다 조인이 있으므로 데이터베이스 row가 증가하기 때문이다. 그 결과 같은 order 엔티티의 조회 수도 증가하게 된다. JPA의 distinct는 SQL에 distinct를 추가하고 더해서 같은 엔티티가 조회되면 애플리케이션에서 중복을 걸러준다. 이 예에서는 order가 컬렉션 페치 조인 때문에 중복 조회되는 것을 막아준다.

참고로 일반 데이터베이스의 distinct는 row가 완전히 똑같아야 제거된다.

하지만 컬렉션 페치 조인을 사용하면 페이징이 불가능하다는 단점이 존재한다. 또한 컬렉션 페치 조인은 1개만 사용할 수 있다. 예를 들어 1 : N : N 같은 방식은 하용되지 않는다.


1.1 entity로 바로 조회(페이징과 한계 돌파)

컬렉션을 페치 조인하면 페이징이 불가능하다는 단점이 존재한다. 그렇다면 페이징 + 컬렉션 엔티티를 함께 조회하려면 어떻게 해야할까?

다음과 같은 방식을 따르면 된다.

  1. 먼저 ToOne 관계를 모두 페치조인한다. ToOne 관계는 row수를 증가시키지 않으므로 페이징 쿼리에 영향을 주지 않는다.
  2. 컬렉션을 지연 로딩으로 조회한다.
  3. 지연 로딩 성능 최적화를 위해 hibernate.default_batch_fetch_size or @BatchSize를 적용한다. 이 옵션들을 사용하면 컬렉션이나 프록시 객체를 한꺼번에 설정한 size 만큼 IN 쿼리로 조회한다.
    • 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;
}

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:
	jpa:
		properties:
			hibernate:
            	default_batch_fetch_size: 1000

아래와 같이 3개의 쿼리가 나간다.

이렇게 ToOne 관계는 fetch join, ToMany 관계는 hibernate.default_batch_fetch_size or @BatchSize를 적용하면 다음과 같은 장점이 있다.

  • 쿼리 호출 수가 1 + N -> 1 + 1 로 최적화 된다.
  • 조인보다 DB 데이터 전송량이 최적화 된다.
  • 페치 조인 방식과 비교해서 쿼리 호출 수가 약간 증가하지만, DB 데이터 전송량이 감소한다.
  • 컬렉션 페치 조인은 페이징이 불가능 하지만 이 방법은 페이징이 가능하다.

📌 결론
ToOne 관계는 페치 조인해도 페이징에 영향을 주지 않는다. 따라서 ToOne 관계는 페치조인으로 쿼리 수를 줄이고 컬렉션은 hibernate.default_batch_fetch_size or @BatchSize로 최적화 하자.

보통 1000으로 설정하는 것이 성능상 가장 좋지만, 결국 DB든 애플리케이션이든 순간 부하를 어디까지 견딜 수 있는지로 결정하면 된다.


2. DTO로 직접 조회

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

public class OrderQueryRepository {

	private final EntityManager em;
    
	/**
	* 컬렉션은 별도로 조회
	* 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();
	}
}

JPA에서 jpql을 날려 직접 DTO를 조회하는 방식이다. ToOne 관계들은 먼저 조회하고, ToMany 관계는 각각 별도로 처리한다. 따라서 Query가 루트 1번, 컬렉션 N번 실행된다. 이 방식은 코드가 단순하며 특정 OrderItem 한건만 조회하면 이 방식을 사용해도 성능이 잘나오지만 만약 OrderItem가 1000건이면 총 쿼리가 1 + 1000번 실행된다는 단점이 있다.


3. DTO로 직접 조회(컬렉션 조회 최적화)

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

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

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

ToOne 관계들을 먼저 조회하고 여기서 얻은 식별자 orderId로 ToMany 관계인 OrderItem을 한꺼번에 조회한다. 이러한 방식은 query가 루트 1번, 컬렉션 1번 나가고 MAP을 사용해서 매칭하기 때문에 성능에 이점이 있다. 코드가 복잡하다는 단점이 있지만 보통 DTO로 조회한다면 이 방식을 사용하는것이 좋다.

MAP : O(1)


4. DTO로 직접 조회(플랫 데이터 최적화)

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

조인을 써서 query 1번으로 DTO를 조회해오는 방식이다.

쿼리는 1번이지만 조인으로 인해 DB에서 애플리케이션에 전달하는 데이터에 중복 데이터가 추가되므로 상황에 따라 이전 방식에 비해 더 느릴 수도 있다. 중복이 발생하므로 추가 작업이 필요하고 이로 인해 페이징이 불가능하다. 따라서 보통 잘 사용되지 않으며 데이터가 많으면 중복 때문에 이전 방식과 비교해서 성능 차이도 미비하다.


📌결론

엔티티 조회 방식은 페치 조인이나, hibernate.default_batch_fetch_size , @BatchSize 같이 코드를 거의 수정하지 않고, 옵션만 약간 변경해서, 다양한 성능 최적화를 시도할 수 있다. 반면에 DTO를 직접 조회하는 방식은 성능을 최적화 하거나 성능 최적화 방식을 변경할 때 많은 코드를 변경해야 한다. 개발자는 성능 최적화와 코드 복잡도 사이에서 줄타기를 해야 한다. 항상 그런 것은 아니지만, 보통 성능 최적화는 단순한 코드를 복잡한 코드로 몰고간다. 엔티티 조회 방식은 JPA가 많은 부분을 최적화 해주기 때문에, 단순한 코드를 유지하면서, 성능을 최적화 할 수 있다. 반면에 DTO 조회 방식은 SQL을 직접 다루는 것과 유사하기 때문에, 둘 사이에 줄타기를 해야 한다.

따라서 다음과 같은 방식으로 고려하는 것을 권장한다.

  1. 엔티티 조회 방식으로 우선 접근
    • 페치조인으로 쿼리 수를 최적화
    • 컬렉션 최적화
      • 페이징 필요 hibernate.default_batch_fetch_size , @BatchSize 로 최적화
      • 페이징 필요X 페치 조인 사용
  2. 엔티티 조회 방식으로 해결이 안되면 DTO 조회 방식 사용
  3. DTO 조회 방식으로 해결이 안되면 NativeSQL or 스프링 JdbcTemplate
profile
이상훈
Problem Solving과 기술적 의사결정을 중요시합니다.
이전 포스트

실전 스프링 부트와 JPA 활용1 정리

0개의 댓글