[Spring] JPA 지연 로딩 & 조회 성능 최적화

반응형

728x90

JPA 지연 로딩

• 데이터베이스에서 객체를 가져오는 방식으로 필요한 시점에만 데이터를 로드
• 지연 로딩이 설정된 관계(예: @OneToMany, @ManyToMany)에서는 JPA가 프록시 객체를 생성
• 프록시 객체는 데이터의 위치 정보를 가짐

지연 로딩 설정 시 조회 -  엔티티를 노출하는 경우

• 지연 로딩 설정 시 엔티티를 직접 노출할 경우 지연 로딩으로 객체와 연결된 다른 객체의 데이터는 가져오지 않음
• 연관된 객체는 실제 엔티티가 아닌 프록시 객체로 Jackson 라이브러리는 이 프록시 객체를 JSON으로 변경 불가하여 에러  발생 -> Hibernate5JakartaModule을 사용할 경우 프록시 객체를 처리 가능

DTO를 사용한 조회

• 엔티티를 조회한 뒤 DTO를 사용하여 변환하여 사용하는 방법
• 엔티티를 조회하여 DTO에 필요한 데이터가 지연 로딩 설정된 객체의 정보 일 경우 강제로 프록시를 초기화하여 값을 얻은 뒤 DTO 객체에 담아 반환

DTO 조회 단점

• 쿼리의 수가 지연로딩이 되어있는 연관 객체의 수만큼 추가로 일어남
• 지연 로딩된 객체를 조회할 시 1 + N 문제로 강제로 프록시를 초기화하는 과정에서 무수한 SQL 호출이 생성

---

DTO를 사용한 fetch 조인

• 엔티티를 조회하여 프록시를 초기화하는 과정에서 발생하는 쿼리 성능 최적화를 위한 방법
• JPQL에서 제공하는 join fetch 기능을 사용해 미리 조인 시 연관된 데이터를 다 가져오는 방법
• 지정한 연관 객체의 정보를 처음에 다 가져오기 때문에 이후에 데이터는 1차 캐시에서 반환
• 처음에 필요한 정보를 다 가져오기 때문에 추가로 쿼리가 발생하지 않음

JPA에서 DTO로 바로 조회

• JPQL의 select 문에 DTO를 넣어 DTO에 필요한 값들만 가져오는 방식
• 원하는 값만 가져올 수 있어 애플리케이션 네트워크 용량 최적화 
• new 명령어를 통해 JPQL 결과를 바로 DTO로 반환
• 단점
  • 리포지토리 재사용성 떨어짐
  • API 스펙에 맞춘 코드가 리포지토리에 들어가게 됨

---

실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화 강의 | 김영한 - 인프런 강의 내용 참고