#11 API 고급 - 컬렉션 조회 최적화

[jimin-kiim]

Overview

• 주문내역 조회 기능에 추가로 일대다 관계인 주문한 상품 정보를 조회하고 성능을 최적화한다.

Contents

• v1
  • 엔티티로 조회, 엔티티로 반환
  • 한계: 엔티티의 스펙이 변하면 API 스펙도 변하게 된다.
• v2
  • 엔티티 조회, DTO로 반환
  • v1의 한계를 해결한다.
• v3
  • 엔티티 조회, DTO로 반환 + 쿼리 수 최적화
  • 모든 데이터를 fetch join하여 가져온다.
  • JPA의 distinct : SQL에 distinct 키워드 추가 + 동일 id를 갖는 엔티티들 중복 제거
  • 한계: 페이징이 불가하다.
  • 쿼리: 1번
• v3.1
  • 엔티티 조회, DTO로 반환 + 쿼리 수 최적화 + 페이징
  • toOne 관계인 루트는 fetch join을 이용해 가져오고
  • toMany 관계인 컬렉션은 fetch join에서 제외해 지연로딩으로 조회한다.
  • 지연 로딩 성능 최적화: hibernate.default_batch_fetch_size(글로벌 설정), @batchsize(개별 설정)
    • 컬렉션이나 프록시 객체를 한 번에 설정한 size만큼 in 쿼리로 조회
    • default_batch_fetch_size:
      • in 쿼리의 개수를 몇 개로 할 것인지, 루프 돌려 결국엔 모두 가져올 건데 한 루프에서 몇 개를 가져올 것인지
      • 100 ~ 1000 이 적당하다. 크게 잡을수록 DB에 가해지는 순간 부하가 크며, 작게 할수록 전송되는 쿼리의 수와 대기 시간이 증가한다.
  • 쿼리: 루트 1번, 컬렉션 1번
• v4
  • JPA에서 DTO로 직접 조회해 DTO로 반환
  • toOne 관계인 루트는 바로 조회
  • toMany 관계인 컬렉션은 조회한 루트 데이터를 루프에 돌릴 때 조회해 채우는 방식
  • 쿼리: 루트 1번, 컬렉션 N번
• v5
  • JPA에서 DTO로 직접 조회해 DTO로 반환
  • toOne 관계인 루트는 바로 조회
  • toMany 관계인 컬렉션은 따로 한 꺼번에 조회해 온 뒤 루프를 돌며 루트 데이터를 채우는 방식
  • 쿼리: 루트 1번, 컬렉션 1번
• v6
  • JPA에서 DTO로 직접 조회해 DTO로 반환
  • 모든 필드를 조인해 한 번에 가져오는 방식
  • 한계: 페이징이 불가하다.
  • 쿼리: 1번
• 권장 개발 순서
  • 1. 엔티티 조회 -> 엔티티 조회 + 쿼리 최적화 + 컬렉션 최적화
  • 2. DTO 조회
  • 3. NativeSQL or 스프링 JdbcTemplate

📸

Related Issue

• Resolved: [FEAT] API 고급 - 컬렉션 조회 최적화 #11