[JPA활용 2] 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

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

DTO 조회 방식의 선택지

• V4는 코드가 단순하다. 특정 주문 한 건만 조회하면 이 방식을 사용해도 성능이 잘 나온다.
  • Ex) 조회한 Order 데이터가 1건이면 OrderItem을 찾기 위한 쿼리도 1번만 실행하면 된다.
• V5는 코드가 복잡하다. 여러 주문을 한꺼번에 조회하는 경우에는 V4 대신에 이를 최적화한 V5 방식을 사용해야 한다.
  • Ex) 조회한 Order 데이터가 1000건인데, V4 방식을 사용하면 쿼리가 총 1 + 1000번 실행된다.
  • V5 방식으로 최적화 하면 쿼리가 총 1 + 1번만 실행된다.
• V6는 쿼리 한번으로 최적화 되어서 상당히 좋아보이지만, Order를 기준으로 페이징이 불가능하다. 실무에서는 이정도 데이터면 수백, 수천건 단위로 페이징 처리가 꼭 필요하므로, 이 경우 선택하기 어려운 방법이다. 그리고 데이터가 많으면 중복 전송이 증가해서 V5와 비교해봐도 성능 차이가 미미하다.

<출처 : 인프런 - 실전! 스프링 부트와 JPA 활용2 (김영한)>