실전! 스프링 부트와 JPA 활용2 - API 개발 고급 - 지연 로딩과 조회 성능 최적화

 

 

 

 

 

 

조회용 샘플 데이터 입력

 

https://github.com/Lemon-soju/Spring-Boot-and-JPA-toddler-practice-02/commit/01307b218115c762bcdc6591c5e3a2792339baf5

Merge pull request #3 from Lemon-soju/slave-01 · Lemon-soju/Spring-Boot-and-JPA-toddler-practice-02@01307b2

 

 

 

 

userA

    JPA1 BOOK

    JPA2 BOOK

 

userB

    SPRING1 BOOK

    SPRING2 BOOK

 

사용자 각각 한 개의 주문에 2개의 아이템

 

 

 

 

 

 

---

 

 

 

 

 

 

 

간단한 주문 조회 V1:엔티티를 직접 노출

 

 

https://github.com/Lemon-soju/Spring-Boot-and-JPA-toddler-practice-02/commit/f571a7ccc9155c37654dc580a69ac465d808c7af

Merge pull request #4 from Lemon-soju/slave-01 · Lemon-soju/Spring-Boot-and-JPA-toddler-practice-02@f571a7c

 

 

배운 것

 

1. 엔티티를 직접 노출할 때는 양방향 연관관계가 걸린 곳은 한 곳은 JsonIgnore 처리해야 한다. 그렇지 않으면 무한 루프가 발생한다.

 

2. 엔티티를 API 응답으로 외부로 노출하는 것은 좋지 않다. DTO로 변환해서 반환해야 한다.

 

 

 

 

 

 

 

 

 

 

---

 

간단한 주문 조회 V2:엔티티를 DTO로 변환

 

https://github.com/Lemon-soju/Spring-Boot-and-JPA-toddler-practice-02/commit/f25b090c9b79e0eb86b57828367de4fa4da409dc

Merge pull request #5 from Lemon-soju/slave-01 · Lemon-soju/Spring-Boot-and-JPA-toddler-practice-02@f25b090

 

배운 것

 

1. Dto를 사용해도 LAZY 때문에 성능에서 N+1 문제가 발생한다.

 

쿼리가 총 1 + N + N번 실행된다. (v1과 쿼리수 결과는 같다.)

    order 조회 1번(order 조회 결과 수가 N이 된다.)

    order -> member 지연 로딩 조회 N 번

    order -> delivery 지연 로딩 조회 N 번

 

예) order의 결과가 2개면 최악의 경우 1 + 2 + 2번 실행된다.(최악의 경우)

    지연로딩은 영속성 컨텍스트에서 조회하므로, 이미 조회된 경우 쿼리를 생략한다

 

 

 

 

 

 

 

 

---

 

간단한 주문 조회 V3:엔티티를 DTO로 변환 - 페치 조인 최적화

 

https://github.com/Lemon-soju/Spring-Boot-and-JPA-toddler-practice-02/commit/f305d4195702292698cc08d0512461ade8d47d9f

Merge pull request #6 from Lemon-soju/slave-01 · Lemon-soju/Spring-Boot-and-JPA-toddler-practice-02@f305d41

 

 

이전 예제 V2에서는 5개의 쿼리가 실행된 것에 비해서 V3에서는 쿼리가 1개만 실행됨

 

 

 

 

 

 

---

간단한 주문 조회 V4: JPA에서 DTO로 바로 조회

 

https://github.com/Lemon-soju/Spring-Boot-and-JPA-toddler-practice-02/commit/1533edf324c568ec61644be53ce4597a1f63e592

Merge pull request #7 from Lemon-soju/slave-01 · Lemon-soju/Spring-Boot-and-JPA-toddler-practice-02@1533edf

 

 

모든 필드를 가져오는 페치 조인에 비해서 같은 쿼리 안에서 필요한 쿼리를 가져오므로 조금 더 성능을 향상할 수 있다.

 

단점:

 

재사용이 거의 불가능하다. 

 

코드가 더럽다.

 

네트워크 용량을 최적화 할 수 있지만 생각보다 효과가 미미하다. 

 

API 스펙에 맞춘 코드가 리포지토리에 들어간다.

 

그냥 페치조인을 사용하자.