JPA(2) - 지연 로딩과 조회 성능 최적화

 

 

1. 엔티티 직접 노출 

 

 private final OrderRepository orderRepository;
 /**
 * V1. 엔티티 직접 노출
 * - Hibernate5Module 모듈 등록, LAZY=null 처리
 * - 양방향 관계 문제 발생 -> @JsonIgnore
 */
 @GetMapping("/api/v1/simple-orders")
 public List<Order> ordersV1() {
 List<Order> all = orderRepository.findAllByString(new OrderSearch());
 for (Order order : all) {
 order.getMember().getName(); //Lazy 강제 초기화
 order.getDelivery().getAddress(); //Lazy 강제 초기환
 }
 return all;
 }

 

- 일단 엔티티 직접 노출부터 문제

- 가져온 것을 바로 리턴하면 무한 루프 문제 발생합니다.

   

   해결법1: @JsonIgnore

 Order와 관련된 모든 Lazy로딩 (프록시 객체)에 @JsonIgnore를 사용해야함

 양방향은 한쪽에 JsonIgnore를 붙여준다. 

	//Order
    @JsonIgnore
    @OneToMany(mappedBy = "order", cascade = CascadeType.ALL)
    private List<OrderItem> orderItems = new ArrayList<>();

    @JsonIgnore
    @OneToOne(fetch = LAZY, cascade = CascadeType.ALL)
    @JoinColumn(name = "delivery_id")
    private Delivery delivery;
    
    //Member
    @JsonIgnore
    @OneToMany(mappedBy = "member")
    private List<Order> orders = new ArrayList<>();
    
    //orderItem
    @JsonIgnore
    @ManyToOne(fetch = LAZY)
    @JoinColumn(name = "order_id")
    private Order order;
    //..

 

해결법2: Hibernate5JakartaModule 등록 -> 지연로딩일 경우 response를 제외시켜준다.

implementation 'com.fasterxml.jackson.datatype:jackson-datatype-hibernate5-
jakarta'

 

- 초기화된 프록시 객체만 노출 초기화 안된건 노출 안함 

- Json으로 만들 때 강제 지연로딩 설정 : 다 불러와서 초기화하라고 설정하는 것 

 Hibernate5Module hibernate5Module = new Hibernate5Module();
 //강제 지연 로딩 설정
 hibernate5Module.configure(Hibernate5Module.Feature.FORCE_LAZY_LOADING, 
true);
 return hibernate5Module;

 

해결법 3: 리턴전에 Lazy강제 초기화 -> N+1문제 발생 (애플리케이션 레벨에서 지연로딩 풀어주기)

 

 - 물론 이 옵션을 켜면 order -> member, member -> orders 양방향 연관관계를 계속 로딩해야함 따라서 @JsonIgnore를 한 곳에 주어야함 (엔티티 직접 노출 + 양방향 관계에선 반드시 한쪽에 @JsonIgnore 걸어야함)

 

- em.find는 성능과 별개 (어차피 식별자로 불러오는거라) 즉시로딩은 jpql에서 성능문제 발생 (연관관계만큼 select)

- 항상 지연로딩 -> 성능 최적화 필요시 페치 조인을 사용 

 

 * 3가지 해결법 모두 구린 방법! 결국 엔티티를 그냥 리턴하기위한 궁리일 뿐이다.

 

2. 엔티티 DTO로 변환 

 

@GetMapping("/api/v2/simple-orders")
public List<SimpleOrderDto> ordersV2() {
 List<Order> orders = orderRepository.findAllByString(new OrderSearch());
 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();
 }
}

 

 - 엔티티를 DTO로 바꾸는 일반적인 방법임 

 - 하지만 지연로딩때문에 1 + N + N 실행 

     -> order 1번조회 (member 지연로딩 2개, 주소 지연로딩 2개) 

     -> 두 지연로딩을 풀기위해 추가로 select 4번 나감 

 

 

3. DTO 변환 + 페치조인 최적화 

 

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


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

 

- 패치조인용으로 따로 메서드를 생성했다.

- 패치 조인을 통해 쿼리가 1번만 나가서 엔티티를 채웠다! (이미 조회 상태이므로 지연로딩 x)

 

4. 한발 더 나아가서 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();
 }

 

 - value object나 Entity 제외하고, jqpl의 리턴값을 만드려면 new 연산자를 사용해줘야함 (queryDSL에서 이를 해결한다함)

- DTO를 바로 만들어서 리턴하면, 애플리케이션 레벨에서 변환 로직이 빠지고, 조회결과 데이터 수가 줄어서 성능 최적화를 노려볼 수 있음 

 - 하지만 리포지토리 재사용성이 떨어지고, API 스펙에 맞춘 코드가 리포지토리에 들어감 (상충관계있음)

 

 

* 권장 순서 

  엔티티 -> DTO는 무조건 지켜야한다.

  엔티티에 지연로딩이 걸려있어 성능 최적화 필요시 페치조인을 사용한다.

  더 나아가 성능을 최적화하고 싶을 때만 DTO직접조회 방식을 사용해본다.

  최후의 방법은 네이티브 SQL 혹은 JDBC Template를 사용해서 직접 SQL을 사용한다.