3. API 개발 고급 - 지연 로딩과 조회 성능 최적화

목표. xToOne 관계 최적화 하기
     Order를 조회할 때, 지연 로딩이면서 xToOne 관계인 Member와 Delivery를 조회할 때 성능을 최적화하는 방법

 

정리. 쿼리 방식 선택 권장 순서

1. 우선 엔티티를 DTO로 변환한다.
2. 필요하면 "fetch join"으로 성능을 최적화 한다.
3. 높은 성능이 요구되면 DTO로 직접 조회한다.
4. 마지막으로는 JPA가 제공하는 네이티브 SQL / JDBC Template에서 SQL 직접 사용하자.

 

 

1. V1 : 엔티티 직접 노출

문제 1) API 스펙이 변함

: Entity가 변하면 API 스펙이 변한다.

 

문제 2) '무한 루프' 발생

: 양방향 연관관계인 Member, Order 사이에서 루프에 빠진다.

 

→ 한 쪽에 @JsonIgnore 해주어야 한다.

 

문제 3) '프록시' 주입

: 지연 로딩이기 때문에, Order 객체를 생성할 때 프록시 Member 가 들어간다.

 

→ hibernate5JakartaModule 설치하여

지연 로딩일 때, Member를 가져오지 않도록 설정해야 한다. (기본적으로 초기화 되지 않은 프록시 객체는 노출하지 않도록..!!)

 

cf. 정말 간단한 애플리케이션이 아니라면 엔티티를 API 응답으로 외부에 노출하는 것은 좋지 않다.

따라서 hibernate5JakartaModule 를 사용하는 것보다는 DTO 로 변환해서 사용하자!!

 

 

 

 

2. V2 : 필요한 엔티티 정보를 DTO로 변환

문제) "1+N" 문제 발생

: 지연로딩의 조회로 인한 쿼리 N번 호출

 

→ V3에서 'fetch join' 으로 해결

 

DTO 생성자

 

- order → member 지연 로딩 조회 N번

- order → delivery 지연 로딩 조회 N번

 

 

 

3. V3 : 필요한 엔티티 정보를 DTO로 변환 + "fetch join 최적화"

이전 문제 해결

- entity를 fetch join을 사용해서 1번의 쿼리로 조회

- order → member, order → delivery 는 이미 조회된 상태이므로 지연 로딩 X

 

문제점(?)

- join 하는 entity의 모든 속성을 select 하여 조회한다.

 

 

 

 

4. V4 : JPA에서 DTO로 직접 조회

이전 문제 해결

- select 절에서 원하는 데이터만 선택해서 조회한다.

     → 네트워크 용량 최적화 (생각보다 미비)

 

문제점

- Repo 재사용성이 떨어진다.

     → 주어진 api 전용으로 만들어진 DTO

     → 별도의 entity.simpleQuery 폴더를 만들어 관리하는 것이 낫다.

 

- Repo는 순수하게 엔티티를 조회하는 용도로만 쓰자!

     → 최적화를 위해 fetch join

 

사용

- 통계형 API를 만들 때 사용하는 경우가 있다.

 

- new 명령어를 사용해서 JPQL의 결과를 DTO로 즉시 변환한다.