Home API 성능 최적화 - 컬렉션 조회 최적화
Post
Cancel

API 성능 최적화 - 컬렉션 조회 최적화

Posted Jan 16, 2024 Updated Feb 23, 2024
By
15 min read

컬렉션 조회 최적화

ManyToOne, OneToOne 관계는 페치조인이 핵심이었다. 이러한 관계가 아닌, 컬렉션인 OneToMany 관계에서의 조회 그리고 최적화에 대해 알아보자.

V1 - 엔티티 직접 노출

1
2
3
4
5
6
7
8
9
10
11
12

@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.stream().forEach(o -> o.getItem().getName());  
	}  
	  
	return all;  
}

지연로딩된 부분을 직접 호출해 프록시 객체를 초기화해준다.

  • 엔티티 직접 노출 문제 (엔티티가 변하면 API 스펙도 변동)
  • 트랜잭션 안에서 지연 로딩 필요
  • 양방향 연관관계 문제

V2 - 엔티티를 조회해 DTO로 변환

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

@GetMapping("/api/v2/orders")  
public List<OrderDto> ordersV2() {  
	List<Order> orders = orderRepository.findAllByString(new OrderSearch());  
	return orders.stream()  
			.map(OrderDto::new)  
			.collect(Collectors.toList());  
}  
  
@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(Collectors.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();  
	}  
}
  • orderItem.getOrderItem()은 엔티티이다. 지연로딩 문제가 발생하여 null 값이 들어가게 된다.
  • stream 으로 호출하여 프록시 객체를 직접 초기화하면 되는데, 이 때도 엔티티를 그대로 노출시키면 안된다.
    • 같은 문제가 발생한다.
    • 따라서 이 또한 DTO를 통해 반환한다.
    • 원하는 데이터만 추출할 수 있다.
  • 문제는 지연 로딩이 많기 때문에 매우 많은 쿼리가 발생하게 된다는 것이다.

V3 - 엔티티를 DTO로 변환 + 페치조인

1
2
3
4
5
6
7
8
9
10
11

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

이렇게 페치조인을 하면 해결될 것 같지만 orderItems가 컬렉션이기 때문에 발생하는 문제가 있다.

DB입장에서는 조인이 된 것이기 때문에 만약 하나의 Order에 OrderItem이 2개가 있다면 OrderId = 1 의 주문이라는 행이 1개가 아닌 2개가 되어버리는 문제가 발생한다.

데이터베이스 row가 증가하는 것이다.

  • 이 문제는 distinct를 사용하여 중복을 걸러줄 수 있다.
  • 최신 하이버네이트 버전에서는 distinct를 사용하지 않아도 중복을 제거해주긴 한다.
1
2

select distinct o from Order o
//...
  • 하지만 단점은 페이징이 불가능하다는 점이다.

페이징을 할 것이 아니라면 이러한 방식을 채택해도 무방하다.

V3 - 페이징 한계 개선

  • 컬렉션을 페치 조인하면 페이징이 불가능하다.
    • 컬렉션을 페치 조인하면 일대다 조인이 발생하여 데이터가 예측할 수 없이 증가한다.
    • 일대다에서 일을 기준으로 페이징을 하는 것이 목적이다. 그런데 데이터는 다를 기준으로 row가 생성된다.
    • 하이버네이트는 경고 로그를 남기고 모든 DB 데이터를 읽어 메모리에서 페이징을 시도하기 때문에 매우 위험하다.

이렇게 페이징이 불가능한 문제를 어떻게 해결할까?

해결

1
2
3
4
5
6
7
8
9
10
11

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

1
2
3
4
5
6
7
8
9
10
11
12
13

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

1
2
3
4
5

spring: 
	jpa: 
		properties: 
			hibernate: 
				default_batch_fetch_size: 1000

위는 yml에서 최적화 옵션을 설정하는 방법이다.

ToOne 관계만 우선 페치 조인으로 최적화 하는 방법이다.

컬렉션 관계는 hibernate.default_batch_fetch_size, @BatchSize를 통해 최적화 한다.

  • 장점
    • 쿼리 호출 수가 1 + N 에서 1 + 1 로 최적화 된다.
    • 조인보다 DB 데이터 전송량이 최적화된다.
      • Order와 OrderItem을 조인하면 Order가 OrderItem만큼 중복해 조회되는데 이 방법은 각각 조회하므로 전송해야할 중복 데이터가 없다.)
    • 페치 조인 방식과 비교해 쿼리 호출 수가 약간 증가하지만, DB 데이터 전송량이 감소한다.
    • 컬렉션 페치 조인은 페이징이 불가능하지만 이 방법은 페이징이 가능하다.

ToOne 관계는 페치 조인을 해도 페이징에 영향을 주지 않는다.

따라서 ToOne 관계는 페치조인으로 쿼리 수를 줄여 해결하고, 나머지는 hibernate.default_batch_fetch_size를 통해 최적화하는 방법을 시도하는 것을 권장한다.

V4 - JPA에서 DTO 직접 조회

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

@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,  
			List<OrderItemQueryDto> orderItems) {  
		this.orderId = orderId;  
		this.name = name;  
		this.orderDate = orderDate;  
		this.orderStatus = orderStatus;  
		this.address = address;  
		this.orderItems = orderItems;  
	}  
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

//OrderQueryRepository

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

1
2
3
4

@GetMapping("/api/v4/orders")  
public List<OrderQueryDto> ordersV4() {  
	return orderQueryRepository.findOrderQueryDtos();  
}
  • 쿼리 : 루트 1번, 컬렉션 N번 실행
  • ToOne(N:1, 1:1) 관계들을 먼저 조회하고, ToMany(1:N) 관계는 각각 별도로 처리한다.
    • ToOne 관계는 조인해도 데이터 row수가 증가하지 않는다.
    • ToMany 관계는 조인하면 row수가 증가한다.
    • 따라서 row수가 증가하지 않는 관계는 조인으로 최적화하기 쉬워 한번에 조회하고, ToMany 관계는 최적화가 어려워 findOrderItems() 같은 메서드로 별도로 조회한다.

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

//OrderQueryRepository

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

1
2
3
4

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

V4의 경우 컬렉션의 크기가 크면 문제가 발생한다. 따라서 위와 같이 최적화할 수 있다.

  • 쿼리 : 루트 1번, 컬렉션 1번
  • ToOne 관계들을 먼저 조회하고, 여기서 얻어낸 식별자 (orderId)로 ToMany 관계인 OrderItem을 한 번에 조회
  • Map을 사용해 매칭 성능 향상 (O(1))

V6 - JPA에서 DTO로 조회 - 플랫 데이터 최적화

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

//OrderFlatDto

@Data  
public class OrderFlatDto {  
	private Long orderId;  
	private String name;  
	private LocalDateTime orderDate; //주문시간  
	private Address address;  
	private OrderStatus orderStatus;  
	private String itemName;//상품 명  
	private int orderPrice; //주문 가격  
	private int count; //주문 수량  

	public OrderFlatDto(Long orderId, String name, LocalDateTime orderDate,  
		OrderStatus orderStatus, Address address, String itemName, int orderPrice, int  count) {  
		
		this.orderId = orderId;  
		this.name = name;  
		this.orderDate = orderDate;  
		this.orderStatus = orderStatus;  
		this.address = address;  
		this.itemName = itemName;  
		this.orderPrice = orderPrice;  
		this.count = count;  
	}  
}

1
2
3
4
5
6
7
8
9
10
11

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

@GetMapping("/api/v6/orders")  
public List<OrderQueryDto> ordersV6() {  
  
	List<OrderFlatDto> flats = orderQueryRepository.findAllByDto_flat();  
	  
	return flats.stream()  
		.collect(Collectors.groupingBy(o -> new OrderQueryDto(o.getOrderId(),  
		o.getName(), o.getOrderDate(), o.getOrderStatus(), o.getAddress()),  
			Collectors.mapping(o -> new OrderItemQueryDto(o.getOrderId(),  
		o.getItemName(), o.getOrderPrice(), o.getCount()), Collectors.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(Collectors.toList());  
}
  • 쿼리가 단 한번이다.

하지만 단점이 존재한다.

  • 쿼리는 한 번이지만 조인으로 인해 DB에서 애플리케이션에 전달하는 데이터에 중복 데이터가 추가되어 상황에따라 V5보다 더 느릴 수 있다.
  • 애플리케이션에서 추가 작업이 매우 크다.
  • 페이징이 불가능하다.

API 성능 최적화 정리

권장 방식을 정리해본다.

  • 엔티티 조회 방식으로 우선 접근 (엔티티 조회 -> DTO 변환 방식)
    • 페치 조인으로 쿼리 수를 최적화
    • 컬렉션 최적화
      • 페이징 필요 -> @BatchSize와 같은 옵션
      • 페이징 필요 X -> 페치 조인 사용
  • 엔티티 조회 방식으로 해결할 수 없다면 DTO 조회 방식 사용
  • DTO 조회 방식으로 해결이 불가능하다면 NativeSQL or 스프링 JdbcTemplate

참고: 엔티티 조회 방식은 페치 조인이나, hibernate.default_batch_fetch_size , @BatchSize 같 이 코드를 거의 수정하지 않고, 옵션만 약간 변경해서, 다양한 성능 최적화를 시도할 수 있다. 반면에 DTO를 직접 조회하는 방식은 성능을 최적화 하거나 성능 최적화 방식을 변경할 때 많은 코드를 변경해야 한다.

참고2: 개발자는 성능 최적화와 코드 복잡도 사이에서 줄타기를 해야 한다. 항상 그런 것은 아니지만, 보통 성능 최 적화는 단순한 코드를 복잡한 코드로 몰고간다. 엔티티 조회 방식은 JPA가 많은 부분을 최적화 해주기 때문에, 단순한 코드를 유지하면서, 성능을 최적화 할 수 있다. 반면에 DTO 조회 방식은 SQL을 직접 다루는 것과 유사하기 때문에, 둘 사이에 줄타기를 해야 한다.

Spring, JPA + Spring
java Spring SpringBoot
This post is licensed under CC BY 4.0 by the author.
Recently Updated
Contents