[jpa] 지연로딩과 조회 성능 최적화

 

이전 강의 내용 

 

엔티티를 Request Body 에 직접 매핑할 경우 문제점

- 엔티티에 프레젠테이션 , API 검증을 위한 로직이 추가된다. 

  하지만 실무에서는 엔티티를 이용한 여러 API들이 만들어지는데 , 각각의 API들을 위한 모든 요청사항들을 담기는 어렵다.

  또한 엔티티가 변경되면 API 스펙이 변한다 !

 

- 따라서 엔티티를 Requst Body 에 직접 매핑시키는 것이 아닌 , API 를 위한 DTO를 따로 만들어서 이것을 파라미터로 받아야한다.

 

- DTO를 통해서 파라미터를 받으면 다음과 같은 장점이 있다.

  1. 엔티티와 프레젠테이션을 위한 로직을 분리할 수 있다.

       - 이제 더 이상 엔티티가 여러 API들을 위한 요청사항들을 담을 필요가 없다. 

  2. 엔티티와 API 스펙을 명확하게 분리할 수 있다.

       - 엔티티가 변경되도 API 스펙이 변하지 않는다.

 

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

---

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

API를 개발할 때 위의 코드를 사용한다고 생각해보자 !

위의 코드는 두 가지의 문제가 있다.

1. 엔티티를 직접 노출한다.

2. 프록시 객체를 조회하므로 예외가 발생한다.

 

엔티티를 직접 노출하는 거는 그렇다치고 먼저 예외를 해결해야한다.

 

 

위 코드가 예외가 발생하는 이유는 엔티티를 불러오는 방식이 fetch.LAZY 인데,

JACKSON 라이브러리가 프록시 객체를 어떻게 json으로 생성할지 모르기 때문이다.

 

이 문제를 해결하기 위해선 하이버네이트 모듈을 설치함으로써 해결할 수 있다. 

이렇게 함으로써 초기화된 프록시 객체만 노출하고 초기화되지 않는 프록시 객체는 노출시키지 않는다.(null로 나옴)

 

근데 엔티티를 직접 노출시키는 것은 매우 안좋기 때문에 애초에 이렇게 하면 안된다 !

차라리 DTO를 반환시키자

 

주의사항

1. 엔티티를 직접 노출할 때 양방향 연관관계가 걸린 곳은 꼭 @JsonIgnore 처리를 해야한다. (안하면 무한루프 걸림)

2. 지연 로딩 문제를 해결한다고 EAGER 로 바꾸면 더 골치아파 진다.

 

엔티티를 DTO로 반환

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

 

이제 엔티티를 직접 노출시키는 게 아닌 DTO를 반환시키는 방식으로 코드를 수정했다.

하지만 이 코드는 1+N 문제를 일으킨다.

로딩방식이 fetch.LAZY이므로 , order에서 member를 조회할때 N번

                                                order에서 Delivery를 조회할때 N번 조회된다.(1+N+N)

 

*지연로딩은 연속성 컨텍스트에서 조회되므로 , 이미 조회된 경우 쿼리 생략 

 

페치 조인 최적화

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+N 문제는 다음과 같이 페치 조인을 사용해서 해결할 수 있다.

원래는 member 와  delivery 를 따로 따로 조회했지만 이제는 한번에 조회함으로써 조회 성능을 높일 수 있다.

(지연로딩이 되지 않는다)

 

*페치조인(fetch join)이란? 

  - jpql에서 성능 최적화를 위해 제공하는 기능 

    연관된 엔티티나 컬렉션을 한번에 같이 조회할 수 있다.

 

리포지토리에서 DTO 직접 조회

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

일반적인 SQL문을 사용하는 것처럼 원하는 값을 선택해서 조회하는 방법이다.

select 절에서 원하는 데이터를 직접 선택하기 때문에 네트워크 용량을 '근소하게' 최적화 할 수 있다.

하지만 결국 API 스펙에 맞춘 코드가 리포지토리에 들어간다는 점과 특정 API 만을 위한 값만을 반환해줘서 리포지토리 재사용이 떨어지는 다는 점을 감안해보면, 페치 조인보다 결코 좋다고 할 수는 없는 방식이다.

 

만약 이와 같은 API를 만들어야한다면 따로 패키지를 만들어서 관리해주는 것이 좋다.

(DTO를 직접 조회하는 것은 화면을 위한 로직이기 때문)

 

정리하자면,

먼저 엔티티를 조회하는 방식을 사용하고 페치조인으로 최적화를 한다.

여기서 대부분 문제가 해결되지만 추가로 성능 최적화를 진행해야 한다면 DTO를 직접 조회하는 방법을 선택한다.

 

이래도 안된다면 네이티브 SQL이나 JDBC 템플릿을 이용해서 SQL을 직접 사용한다. (촤후의 방법)