[JPA 활용2] 고급 - 지연 로딩과 조회 성능 최적화

인프런 - 실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화
주문 + 배송정보 + 회원을 조회하는 API를 만들자
지연 로딩 때문에 발생하는 성능 문제를 단계적으로 해결해보자.

@PostConstruct
> 와스가 올라가면서 빈이 생성 될 때 딱 한번 초기화 된다.
> 빈이 여러번 초기화 되는 걸 방지, 의존성 주입 후 초기화를 수행하는 메서드이다

@Component
> 컴포넌트 스캔을 위한 기본 어노테이션, 스프링 사용시 역할에 맞게 사용 @Repository @Service, @Controller 

V1 엔티티 직접 노출 (이렇게 쓰지 말자 방법)

• 양방향 연관관계에서 무한 루프가 일어나게 된다. -> @JsonIgnore 으로 처리
• 초기화되지 않은 객체를 하이버네이트는 프록시 객체로 생성한다. Jackson 라이브러리에서 프록시 객체를 어떻게 json으로 생성해야하는지 알지 못해 2번째 예외가 발생한다.
  => Hibernate5Module을 등록해서 사용/해결

  @Bean
  Hiberrnate5Module hibernate5Module() {
    //강제 지연 로딩
    Hibernate5Module hibernate5Module = new Hibernate5Module();
    hibernate5Module.configure(Hibernate5Module.Feature.FORCE_LAZY_LOADING, true);
    return new Hibernate5Module();
  }

• 기본적으로 초기화 된 프록시 객체만 노출, 초기화 되지 않은 프록시 객체는 노출 안함
• DTO로 변환해서 반환하고, 지연로딩을 항상 기본으로 하자!

V2 엔티티를 DTO로 변환

• N+1 문제가 발생한다.
• 성능이 안좋다 ~

V3 fetch join을 통한 성능 개선

• 기본으로 LAZY를 깔고 필요할 경우 fetch join으로 객체 그래프를 탐색해서 묶어서 한방에 가져오면 대부분의 성능 문제가 해결된다

V4 JPA에서 DTO 바로 조회

• DTO 생성 및 select 절에서 new Dto(필요 필드(컬럼) 명) 으로 조회하여 엔티티 조회시 dto반환

    em.createQuery(select new jpabook.~~package.xxxDto(o.id, o.name, o.status, o.adress from xxx o join o.member), xxxDto.class).getResultList();

• 일반적인 SQL을 사용할 때 처럼 원하는 값을 선택 조회

• new 명령어를 사용해서 JPQL의 결과를 DTO로 즉시 변환

• select 절에서 원하는 데이터를 직접 선택하므로 DB -> 애플리케이션 네트웍 용량 최적화(생각보다 미비하다)

• 리포지토리 재 사용성이 떨어짐, API스펙에 맞춘 코드가 리포지토리에 들어가는 단점 / 패키지 분리 등을 해주는게 좋을지도.