API 개발 고급 정리

지금까지 내용 정리

엔티티 조회

• 엔티티를 조회해서 그대로 반환: V1
• 엔티티 조회 후 DTO로 변환: V2
• 페치 조인으로 쿼리 수 최적화: V3
• 컬렉션 페이징과 한계 돌파: V3.1 -> 컬렉션은 페치 조인 시 페이징이 불가하다. ToOne 관계는 페치 조인으로 쿼리수를 최적화하고 컬렉션은 패치 조인 대신에 지연 로딩을 유지한다. hibernate.default_batch_fetch_size , @BatchSize로 최적화한다

DTO 직접 조회

• JPA에서 DTO를 직접 조회: V4
• 컬렉션 조회 최적화 - 일대다 관계인 컬렉션은 IN 절을 활용해서 메모리에 미리 조회해서 최적화: V5
• 플랫 데이터 최적화 - JOIN 결과를 그대로 조회 후 애플리케이션에서 원하는 모양으로 직접 변환: V6

 

강사님의 추천 순서

• 엔티티 조회 방식으로 우선 접근 

1. 페치조인으로 쿼리 수를 최적화

2. 컬렉션 최적화 -> 페이징 필요 hibernate.default_batch_fetch_size , @BatchSize 로 최적화

                           -> 페이징 필요 없으면 페치 조인 사용

• 엔티티 조회 방식으로 해결이 안되면 DTO 조회 방식 사용
• DTO 조회 방식으로 해결이 안되면 NativeSQL or 스프링 JdbcTemplate

엔티티 조회 방식은 페치 조인이나, hibernate.default_batch_fetch_size , @BatchSize 같이 코드를 거의 수정하지 않고, 옵션만 약간 변경해서, 다양한 성능 최적화를 시도할 수 있다.

반면에 DTO를 직접 조회하는 방식은 성능을 최적화 하거나 성능 최적화 방식을 변경할 때 많은 코드를 변경해야 한다.

엔티티는 캐시에 올리면 안된다. 영속성 컨텍스트가 관리하고 있어 꼬일 수가 있다. 그러므로 캐시에 올릴 때는 DTO로 반환하고 캐시에 집어 넣어야 한다.

 

개발자는 성능 최적화와 코드 복잡도 사이에서 줄타기를 해야 한다.

항상 그런 것은 아니지만, 보통 성능 최적화는 단순한 코드를 복잡한 코드로 몰고간다. (강사님 말씀)

• 엔티티 조회 방식은 JPA가 많은 부분을 최적화 해주기 때문에, 단순한 코드를 유지하면서, 성능을 최적화 할 수 있다.
• 반면에 DTO 조회 방식은 SQL을 직접 다루는 것과 유사하기 때문에, 둘 사이에 줄타기를 해야 한다

 

 

출처

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81%EB%B6%80%ED%8A%B8-JPA-API%EA%B0%9C%EB%B0%9C-%EC%84%B1%EB%8A%A5%EC%B5%9C%EC%A0%81%ED%99%94/dashboard

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