toychip commented 8 months ago

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

학습기간: 11월 15일까지

Chapter1 API 개발 기본

[x] 회원 등록 API
[x] 회원 수정 API
[x] 회원 조회 API

Chapter2 API 개발 고급 - 준비

[x] API 개발 고급 소개

[x] 조회용 샘플 데이터 입력

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

[x] 간단한 주문 조회 V1: 엔티티를 직접 노출
[x] 간단한 주문 조회 V2: 엔티티를 DTO로 변환
[x] 간단한 주문 조회 V3: 엔티티를 DTO로 변환 - 페치 조인 최적화
[x] 간단한 주문 조회 V4: JPA에서 DTO로 바로 조회

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

[x] 주문 조회 V1: 엔티티 직접 노출
[x] 주문 조회 V2: 엔티티를 DTO로 변환
[x] 주문 조회 V3: 엔티티를 DTO로 변환 - 페치 조인 최적화
[x] 주문 조회 V3.1: 엔티티를 DTO로 변환 - 페이징과 한계 돌파
[x] 주문 조회 V4: JPA에서 DTO 직접 조회
[x] 주문 조회 V5: JPA에서 DTO 직접 조회 - 컬렉션 조회 최적화
[x] 주문 조회 V6: JPA에서 DTO로 직접 조회, 플랫 데이터 최적화
[x] API 개발 고급 정리

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

[x] OSIV와 성능 최적화

Chapter6 다음으로

[x] 스프링 데이터 JPA 소개
[x] QueryDSL 소개

songhee1 commented 7 months ago

지연로딩과 조회성능 최적화를 할 수 있는 방법 중에 DTO로 바로 리포지토리를 조회하는 방법이 있었다. 이 방법의 특징에 대해 설명하고 쿼리방식 선택에 있어서 권장하는 순서는 무엇인지?

dionisos198 commented 7 months ago

OSIV 를 끄면 어떤 점이 좋은가?

jyjyjy25 commented 7 months ago

엔티티로 조회하여 DTO로 변환하는 방식을 더 권장하는 이유는?

jaepyo-Lee commented 7 months ago

코드를 최적화 시켜보시오


public class House{

private List<People> people=new ArrayList<>();

private Dog dog;
}

public List findAllWithPeople(){ return em.createQuery( "select h from House h join fetch h.people p",House.class ).getResultList(); }

ankisile commented 7 months ago

컬렉션 페치 조인의 단점과 해결방안?

toychip commented 7 months ago

XToOne 일때 지연로딩으로 인한 n + 1 문제를 해결하기 위해 fetch join을 사용했다. 이 때 페이징 처리가 가능한지? XToMany는 지연로딩일 때 페이징 처리할면 어떻게 해야 성능이 준수한지?

jaepyo-Lee commented 7 months ago

1번 정답

엔티티로 조회하는 것보다, DTO로 리포지토리를 조회하는 경우 다음과 같은 특징이 있다.

일반적인 SQL을 사용하는 것처럼 원하는 값을 선택해서 조회할 수 있고
new 명령어를 사용해서 JPQL결과를 즉시 DTO로 변환
SELECT절에서 원하는 데이터를 직접 선택하기 때문에 DB에서 어플리케이션으로의 네트워크 용량이 최적화된다.(미비)
하지만, 리포지토리 재사용성이 떨어지며 API스펙에 맞춘 코드가 리포지토리에 작성되는 단점이 있다.

💯 쿼리방식 선택 권장 순서

우선 엔티티를 DTO로 변환하는 방법을 선택
필요하면 페치조인으로 성능 최적화
그래도 안되면 DTO로 직접 조회
최후 방법으로, 네이티브 SQL이나 스프링 JDBC Template을 사용해 SQL 직접 사용

2번 정답

기존에 default값이 OSIV가 켜져 있는 상태인데 이 상태는 트랜잭션이 끝나도 ,API 가 유저한테 반환될때까지 혹은 유저한테 화면이 렌더링될때까지 영속성 컨텍스트가 계속 살아있다 즉 DB connection을 물고 있다.

이 점 때문에 오랫동안 DB 커넥션 리소스를 사용할 수 있어서, 실시간 트래픽이 중요한 애플리케이션에서는 커넥션이 모자랄 수 있다.

김영한 강사는 고객서비스의 실시간 API는 OSIV를 끄고, 커넥션을 많이 사용하지 않는 곳에서는 OSIV를 켠다고 한다.

3번 정답

엔티티 조회 방식은 페치 조인이나 hibernate.default_batch_fetch_size, @BatchSize와 같이 코드를 거의 수정하지 않고 옵션만 약간 변경함으로써 다양한 성능 최적화를 시도할 수 있다. 반면에 DTO를 직접 조회하는 방식은 성능을 최적화하거나 성능 최적화 방식을 변경할 때 코드를 많이 변경해야 한다.

4번정답

ToOne관계의 fetch옵션을 수정한다.
@ BatchSize를 설정하고, 지연로딩의 객체를 불러오는 메서드를 정의한다.
distinct 키워드로 페치조인의 중복값을 삭제한다.

5번

일대다 조인으로 데이터가 예측할수 없이 증가함. 일대다에서 일을 기준으로 페이징을 해야되는데 다를 기준으로 row가 생겨버림. => 1+n문제 발생. 따라서 batch size를 적용하여 페이징을 한다

6번

xToOne은 fetch 조인하면서 페이징처리가 동시에 가능하다. xToMany는 이것이 동시에 불가능하다. 그렇기 때문에 xToMany은 fetch join을 사용하지 않고 지연로딩을 그대로 가져가면서 BatchSize를 설정하거나 default_batch_fetch_size를 설정한다.

Tave12st-Backend-Study / jpa-study

8주차 - 실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화 #91