[JPA 활용2] 기본~ 고급 요약

인프런 - 실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화

API 개발 기본

1. API는 항상 DTO로 변환하여 값을 반환한다. 엔티티가 변해도 API 스펙이 변하지 않도록한다. (엔티티 직접 사용 X)
2. DTO를 배열로 바로 반환하지 않게 래핑 후 반환한다
3. 수정용 DTO는 등록에 비해 데이터가 제한적이기 때문에 별도로 가져가는게 좋다
4. 커맨드와 쿼리를 분리하자

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

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

API 개발 고급 - 컬렉션 조회 최적화

엔티티 조회 - DTO변환 ( V3.1)

지연로딩은 유지 하고 페치 조인으로 최적화

• 컬렉션 조인인 경우 toOne 관계는 페치 조인으로 처리 후hibernate.default_bache_fetch_join 옵션 또는 @BatchSize 옵션 사용으로 최적화

DTO 직접 조회 (V5)

• in 절을 활용해서 최적화 (일대다 관계인 컬렉션은 IN 절을 활용해서 메모리에 미리 조회해서 최적화)
• toOne 관계는 페치조인으로 처리
• Many 부분은 조회후 맵으로 변환 하고 in절 사용 - 근데 이렇게 할꺼면 엔티티 조회로 하는게 낫다

API 개발 고급 - 실무 필수 최적화

OSIV와 성능 최적화

1. OSIV 문제점 : 영속성컨텍스트 생존 범위가 요청에서 응답까지 살아있다 : 요청이 많은 경우 커넥션이 모자른 경우가 발생 : 특히 외부와 연계된 처리 시 응답이 없는 경우 커넥션을 계속 물고 있다 (default: true)

2. spring.jpa.open-in-view 옵션을 false로 변경하면 영속성 컨텍스트 생존 범위가 Service ~ Repository로 한정된다(@Transactional 범위 이내 )
   대신 이렇게 할 경우 컨트롤러 단에서 처리하던 지연 로딩의 프록시 초기화 처리가 불가하기 때문에 기존의 소스를 서비스단으로 옮기는 작업이 필요하다

3. 대부분 성능이슈는 복잡한 화면을 출력하기위한 조회 쿼리에서 발생한다 (화면용)
   비지니스 로직과 쿼리(읽기 전용 트랜잭션) 를 분리하는게 좋다. -> 고객서비스와같은 실시간 API는 OSIV는 끄고 ADMIN 같은 커넥션 수가 적은 곳에서는 OSIV를 켠다

기타

캐시 * 레디스 / 엔티티는 절대 캐시하지 않는다 !
개발자는 성능 최적화와 코드 복잡도 사이에서 항상 줄타기를 한다. 상황에 맞게 잘 선택하여 처리하자.