-
지연 로딩과 조회 성능 최적화Working/jpa 성능 최적화 2021. 3. 2. 18:08
xToOne(ManyToOne, OneToOne)
Order
Order -> Member
Order -> Delivery
양방향 연관관계가 걸리는 컬럼들 -> @JsonIgnore 옵션을 한곳에 주어야 한다.
@ManyToOne(fetch=LAZY)
-> ByteBuddyInterceptor() 가짜 프록시 객체를 넣어둠
-> 접근 할때 db 실제 조회
Jackson DataType Hibernate5
- 지연 로딩 -> null(옵션 조절 해서 조회 하게도 가능)
- 불필요 엔티티 외부 노출 X
- 이 모듈을 따로 사용하기 보다는 DTO로 변경해서 반환하는게 best
Lazy-Loading - 너무 많은 테이블을 조회 해야 하는 경우 중요한 성능 문제
ORDER -> SQL 1번 -> 결과 row 2개
2개를 DTO로 변환하는 동안 Lazy 로딩 초기화 될떄
연관된 테이블 수(2) * Row 수 만큼 쿼리가 늘어남(2) -> 추가 쿼리 4번
Fetch Join 사용(join fetch)
- sql join 조회
- select o from Order o join fetch o.member m join fetch o.delivery d
- lazyloading 모두 무시, 쿼리의 join 기능을 사용 하는것
- 쿼리 호출 횟수는 줄지만 db 부하는 늘어나는 trade-off
JPA entity에서 DTO를 바로 조회 하자(성능 차이는 별로 없음, 결국 join을 하기 때문)
- QueryDto
- select new QueryDto(o.id, m.name, d.address) from Order o join Member m join Delivery d
- new 명령어를 사용해서 JPQL의 결과를 DTO로 즉시 변환
- 필요한 param 데이터만 가져온다. -> 재사용성 떨어진다.
- 데이터 양을 줄일 수 있다.
- 오히려 Repository에서 화면단에 의존 로직이 포함된다고 할수도 있음.
최후의 방법은 JPA가 제공하는 네이티브 SQL이나 JDBC Template으로 SQL 직접 사용
'Working > jpa 성능 최적화' 카테고리의 다른 글
컬렉션 조회 최적화(oneToMany) (0) 2021.03.02 데이터 저장(Post) API(엔티티를 API 스펙에 노출하지 말자) (0) 2021.03.02