[JPA] API 조회 기능 개발 정리

 

엔티티 조회

1. 엔티티를 조회해서 그대로 반환
2. 엔티티 조회 후 DTO로 변환
3. fetch join으로 쿼리 수 최적화
4. 컬렉션 페이징과 한계 돌파
   1. 컬렉션은 fetch join시 불가
   2. ToOne 관계는 fetch join으로 쿼리 수 최적화
   3. 컬렉션은 fetch join 대신 지연 로딩을 유지하고 hibernate.default_batch_fetch_size, @BatchSize로 최적화

 

DTO 직접 조회

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

 

권장 순서

1. 엔티티 조회 방식으로 우선 접근
   1. fetch join으로 쿼리 수 최적화
   2. 컬렉션 최적화
      1. 페이징 필요 → hibernate.default_batch_fetch_size, @BatchSize로 최적화
      2. 페이징 필요x → fetch join 사용
2. 엔티티 조회 방식으로 해결이 안되면 DTO 조회 방식 사용
3. DTO 조회 방식으로 해결이 안되면 NativeSQL or Spring JdbcTemplate 사용

 

참고

• 엔티티 조회 방식은 코드를 거의 수정하지 않고, 옵션만 약간 변경해서 다양한 성능 최적화를 시도할 수 있다.
• DTO를 직접 조회하는 방식은 성능을 최적화 하거나 성능 최적화 방식을 변경할 때 많은 코드를 변경해야 한다.
• 엔티티를 조회할 경우 cache 하지 않고 DTO 조회 방식에서만 한다.
• 성능 최적화와 코드 복잡도 사이에서 줄타기를 해야 한다.
  • 엔티티 조회 방식은 JPA가 많은 부분을 최적화, 단순한 코드를 유지하면서 성능을 최적화 할 수 있다.
  • DTO 조회 방식은 SQL을 직접 다루는 것과 유사

 

DTO 조회 방식의 선택지

• DTO로 조회하는 방법도 각각 장단이 있다. → 단순하게 쿼리가 1번 실행된다고 좋은 건 아니다.