Entity 조회 후 DTO 변환
V1
Entity를 조회해서 직접 반환
Entity가 변하면 API 스펙도 변하기 때문에 DTO로 변환하는 걸 권장
V2
Entity 조회 후 DTO로 변환
여러 테이블을 join 할 때 성능이 나오지 않는다.
V3
fetch join으로 쿼리 수를 최적화
V3.1
컬렉션은 fetch join 시 페이징이 불가능
실무에서는 페이징을 할 일이 많으므로 다음과 같이 구현
- ToOne 관계는 fetch join으로 쿼리 수를 최적화
- 컬렉션은 fetch join 대신 지연 로딩을 유지
(fetch join을 하면 페이징이 안되기 때문) hibernate.default_batch_fetch_size,@BatchSize로 최적화
DTO 직접 조회
단순히 쿼리가 1번 실행된다고 V6이 항상 좋은 방법인 것은 아니다.
V4
JPA에서 DTO를 직접 조회
코드가 단순
그냥 loop만 돌면 된다.
컬렉션이 아니라 특정 주문 한 건만 조회하면 성능이 잘 나온다.
V5
컬렉션 조회를 최적화
- IN절을 활용해 메모리 상에서 map으로 값을 매칭
쿼리가 총 1 + 1만 실행
쿼리가 2번 나가지만 정규화된 데이터를 보낸다.
DTO를 직접 조회해야할 때는 거의 V5 방식을 많이 사용
V6
플랫 데이터로 최적화
join 결과를 그대로 조회한 후 애플리케이션에서 원하는 모양으로 직접 변환
특정 필드를 기준으로 페이징이 불가능
데이터가 많으면 중복 전송이 증가해서 V5와의 성능 차이도 미비
-> 데이터가 뻥튀기 되어서 네트워크 전송량이 많아지기 때문에 V5가 더 좋을 수도 있다.
권장 순서
-
Entity 조회 후 DTO로 변환하는 방식으로 접근
- fetch join으로 쿼리 수를 최적화
- 컬렉션을 최적화
- 페이징 필요 ->
hibernate.default_batch_fetch_size,@BatchSize로 최적화 - 페이징 필요 X -> fetch join
- 페이징 필요 ->
-
Entity 조회 방식으로 해결이 안되면 DTO 조회 방식을 사용
-
DTO 조회 방식으로 해결이 안되면 NativeSQL 또는 스프링 JdbcTemplate을 사용
참고
-
Entity 조회 방식은 코드를 거의 수정하지 않는다.
fetch join,hibernate.default_batch_fetch_size,@BatchSize등 옵션만 약간 변경해서 다양한 성능 최적화를 시도할 수 있다.
-
DTO를 직접 조회하는 방식은 성능을 최적화하거나 성능 최적화 방식을 변경할 때 많은 코드를 변경해야 한다.
-
Entity 조회 방식으로 대부분의 애플리케이션이 해결된다.
-
해결이 안되는 문제는 정말 트래픽이 많은 것이므로 캐시 등 다른 방법을 생각해봐야 한다.
- 참고로 Entity는 영속성 컨텍스트에서 관리되는 상태가 있기 때문에 캐싱하면 안된다.
- Entity를 DTO로 변환한 값을 캐시해야 한다.
-
Entity 조회 방식은 JPA가 많은 부분을 최적화해주기 때문에 단순한 코드를 유지하면서 성능을 최적화할 수 있다.
- DTO 조회 방식은 SQL을 직접 다루는 것과 유사하기 때문에 성능 최적화와 코드 복잡도 사이에서 줄타기를 해야한다.
참고 :
