Spring/API 성능 최적화 (5) 썸네일형 리스트형 컬렉션 조회 API 성능 최적화 (V5. JPA에서 DTO 직접 조회) https://praaay.tistory.com/8 컬렉션 조회 API 성능 최적화 (V4. hibernate.default_batch_fetch_size)https://praaay.tistory.com/7 컬렉션 조회 API 성능 최적화https://praaay.tistory.com/6 API 조회 성능 최적화추가, 수정 API 보다도 조회 API가 성능에 가장 민감한 만큼 JPA를 사용할 때 조회 API의 성능을 최적화praaay.tistory.com 위 글의 연장선으로 V5. JPA에서 DTO를 직접 조회하는 방식을 살펴보겠습니다. 이전 V4에서는 컬렉션이 아닌 xToOne 관계의 엔티티들을 페치 조인하는 쿼리 한 번과 컬렉션인 xToMany 관계의 엔티티를 where in 절로 가져오는 쿼리 한 .. OSIV와 성능 최적화 OSIVOSIV는 Open Session in View의 줄임말로 영속성 컨텍스트 생존 범위를 결정하는 중요한 설정입니다. 영속성 컨텍스트를 Service와 Repository 영역 이상으로 Controller와 View 영역까지 살려둬서 영속성 컨텍스트의 지연 로딩과 같은 기능을 Controller와 View 영역에서 사용할 수 있도록 만듭니다. OSIV는 정확히는 하이버네이트에서 사용되는 용어이고 JPA에서는 OEIV(Opern EntityManager in View)라고 합니다. 하지만 관례상 OSIV라고 부릅니다. OSIV는 설정이기 때문에 On/Off 할 수 있습니다. 지금부터 OSIV를 On 했을 때와 Off 했을 때 영속성 컨텍스트의 생존 범위를 확인하고 장단점을 살펴봅시다. OSIV ONs.. 컬렉션 조회 API 성능 최적화 (V4. hibernate.default_batch_fetch_size) https://praaay.tistory.com/7 컬렉션 조회 API 성능 최적화https://praaay.tistory.com/6 API 조회 성능 최적화추가, 수정 API 보다도 조회 API가 성능에 가장 민감한 만큼 JPA를 사용할 때 조회 API의 성능을 최적화하는 방법을 단계별로 정리하려 합니다. 주문과 배praaay.tistory.com위의 글에 이어서 컬렉션 조회 API 성능을 최적화해 보겠습니다. 위 글에서 살펴본 V3은 컬렉션을 포함한 조회 API에서 JPA의 페치 조인과 함께 distinct 문법을 사용해 1번의 SQL문으로 필요한 결과를 얻었습니다. 하지만 이 방식으로는 페이징이 불가능하다는 치명적인 단점이 존재했습니다. V4에서는 V3의 단점을 보완하며 성능 최적화도 보장하는 방법.. 컬렉션 조회 API 성능 최적화 (V1 ~ V3. 컬렉션 페치 조인과 데이터 뻥튀기) https://praaay.tistory.com/6 API 조회 성능 최적화추가, 수정 API 보다도 조회 API가 성능에 가장 민감한 만큼 JPA를 사용할 때 조회 API의 성능을 최적화하는 방법을 단계별로 정리하려 합니다. 주문과 배송정보 그리고 회원을 조회하는 API를 만들praaay.tistory.comAPI 조회 성능 최적화 글에서는 xToOne(OneToOne, ManyToOne) 관계로 물린 엔티티를 조회할 때 어떤 방식으로 성능을 최적화할지 살펴보았습니다. 사실 xToOne 관계라면 fetch join을 사용하면 웬만해서는 성능에 문제가 없었습니다. 하지만 이번에는 xToMany(OneToMany) 관계로 물린 엔티티를 조회하는 API의 성능을 개선해보려 합니다.컬렉션 조회의 경우 xToO.. xToOne 관계 조회 API 성능 최적화 추가, 수정 API 보다도 조회 API가 성능에 가장 민감한 만큼 JPA를 사용할 때 조회 API의 성능을 최적화하는 방법을 단계별로 정리하려 합니다. 주문과 배송정보 그리고 회원을 조회하는 API를 만들고 지연 로딩에 의해 발생하는 성능 문제를 해결해보려 합니다. 이번 글에서는 ManyToOne, OneToOne 과 같은 xToOne 관계를 조회하는 경우를 살펴보겠습니다. 아래 그림과 같이 주문, 배송정보, 회원은 모두 엔티티로 존재하고 주문과 회원이 다대일 양방향 연관관계 그리고 주문과 배송정보가 일대일 양방향 연관관계로 되어 있습니다. 주문 조회 V1: 엔티티를 직접 노출@RestController@RequiredArgsConstructorpublic class OrderSimpleApiContro.. 이전 1 다음
