1. 엔티티 조회
- 엔티티를 조회해서 그대로 반환: ver1
- 엔티티 조회 후 DTO로 변환: ver2
- 페치조인으로 쿼리 수 최적화: ver3
- 컬렉션 페이징과 한계 돌파: ver3.1
- 컬렉션 페치 조인시 페이징이 불가능하다는 한계가 존재
- 그렇다면 어떻게 해결? (실무에서는 페이징 처리 필요)
- ToOne 관계는 페치조인으로 쿼리 수 최적화
- 컬렉션은 페치조인 대신 지연로딩을 유지하고, hibernate.default_batch_fetch_size, @BatchSize로 최적화
2. DTO로 직접 조회
- JPA에서 DTO를 직접 조회: ver4
- 컬렉션 조회 최적화: 일대다 관계인 컬렉션은 IN절을 활용해서 메모리에서 미리 조회한 뒤 최적화: ver5
- 플랫 데이터 최적화: JOIN 결과를 그대로 조회한 뒤 애플리케이션에서 원하는 모양으로 직접 변환: ver6
📌 권장 순서
- 엔티티 조회 방식으로 우선 접근
- 페치조인으로 쿼리 수 최적화
- 컬렉션 최적화
- 페이징 O: hibernate.default_batch_fetch_size, @BatchSize로 최적화
- 페이징 X: 페치조인 사용
- 엔티티 조회방식으로 해결이 안될 경우 DTO 조회 방식 사용
- DTO 조회방식으로 해결이 안될 경우 NativeSQL or 스프링 JdbcTemplate 사용
[참고] 엔티티 조회 방식을 우선 권장하는 이유?
- 엔티티 조회방식은 페치조인, hibernate.default_batch_fetch_size, @BatchSize 등 코드를 거의 수정하지 않고 옵션만 변경해서 다양한 성능최적화를 시도할 수 있음!
- DTO를 직접 조회할 경우에는, 성능 최적화 혹은 성능 최적화 방식이 변할 경우 많은 코드 변경이 필요
[참고] DTO 조회 방식의 선택지
- Ver4
- 코드의 단순성
- 특정 주문 한 건만 조회할 경우에는 이 방식을 사용해도 성능이 좋음. 예를 들어 조회한 Order 데이터가 1건이면 OrderItem을 찾기 위한 쿼리도 1번만 실행
- Ver5
- 코드의 복잡성
- 여러 주문을 한꺼번에 조회하는 경우에는 Ver4 대신 이것을 최적화한 Ver5 방식을 사용해야 함
- 예를 들어서 조회한 Order 데이터가 1000건인데, Ver4 방식을 그대로 사용하면, 쿼리가 총
1 + 1000번(N) 실행. but Ver5의 경우 쿼리가 총 1 + 1번만 실행(상황에 따라 다르겠지만 운영 환경에서 100배 이상의 성능 차이가 날 수 있음)- Ver6은 사실 완전히 다른 접근방식
- 쿼리 한번으로 최적화 되어서 상당히 좋아보이지만, Order를 기준으로 페이징이 불가능
- 실무에서는 수백이나, 수천건 단위로 페이징 처리가 꼭 필요하므로, 이 경우 선택하기 어려운 방법
- 그리고 데이터가 많으면 중복 전송이 증가해서 Ver5 비교해서 성능 차이도 미비
