[JPA2] API개발과 고급 정리

• 엔티티 조회

  • 엔티티를 조회해서 그대로 반환: V1
    // 엔티티 스펙이 변할경우, API 스펙도 변환됨

  • 엔티티 조회 후 DTO로 변환: V2
    //API 스펙에 맞게 DTO로 변환해서 사용

  • 페치 조인으로 쿼리 수 최적화: V3
    //여러 테이블 조인할 경우 성능 안나올 때 이용

  • 컬렉션 페이징과 한계 돌파: V3.1

    • 컬렉션은 페치 조인시 페이징이 불가능
    • ToOne 관계는 페치 조인으로 쿼리 수 최적화
    • 컬렉션은 페치 조인 대신에 지연 로딩을 유지하고, hibernate.default_batch_fetch_size , @BatchSize로 최적화

• DTO 직접 조회
  • JPA에서 DTO를 직접 조회: V4
  • 컬렉션 조회 최적화 - 일대다 관계인 컬렉션은 IN 절을 활용해서 메모리에 미리 조회해서 최적화: V5
  • 플랫 데이터 최적화 - JOIN 결과를 그대로 조회 후 애플리케이션에서 원하는 모양으로 직접 변환: V6

---

DTO 직접 조회 비교

V4

• 코드가 단순하다.
• 특정 주문 한건만 조회하면 이 방식을 사용해도 성능이 잘 나옴.
  • 예를 들어서 조회한 Order 데이터가 1건이면 OrderItem을 찾기 위한 쿼리도 1번만 실행하면 됨

V5

• 코드가 복잡하다.
• 여러 주문을 한꺼번에 조회하는 경우에는 V4 대신에 이것을 최적화한 V5 방법을 사용해야 함.
  • 예를 들어서 조회한 Order 데이터가 1000건인데, V4 방식을 그대로 사용하면, 쿼리가 총 1 + 1000번 실행된다. 여기서 1은 Order 를 조회한 쿼리고, 1000은 조회된 Order의 row 수
  • V5 방식으로 최적화 하면 쿼리가 총 1 + 1번만 실행된다. 상황에 따라 다르겠지만 운영 환경에서 100배 이상의 성능 차이가 날 수 있다.

V6

• 완전히 다른 접근방식이다. 쿼리 한번으로 최적화 되어서 상당히 좋아보이지만, Order를 기준으로 페이징이 불가능.
• 실무에서는 이정도 데이터면 수백이나, 수천건 단위로 페이징 처리가 꼭 필요하므로, 이 경우 선택하기 어려운 방법
• 데이터가 많으면 중복 전송이 증가해서 V5와 비교해서 성능 차이도 미비.

---

권장 순서

1. 엔티티 조회 방식으로 우선 접근
   • 페치조인으로 쿼리 수를 최적화
   • 컬렉션 최적화
     • 페이징 필요 hibernate.default_batch_fetch_size , @BatchSize 로 최적화
     • 페이징 필요X 페치 조인 사용
2. 엔티티 조회 방식으로 해결이 안되면 DTO 조회 방식 사용
3. DTO 조회 방식으로 해결이 안되면 NativeSQL or 스프링 JdbcTemplate