QueryDsl을 이용한 zero offset paging

Hyuk·2023년 9월 3일
0

HappyScrolls 개발기

목록 보기
7/24
post-thumbnail
post-custom-banner

개요

이전 포스팅에서의 고민을 통해 네이티브 쿼리가 아닌 Jpa 연관관계를 살리는 방법과 QueryDsl을 사용하기로 결정했고, 이에 지난번에 작성한 네이티브 쿼리를 QueryDsl로 작성하였다.

문제 해결

작성한 코드는 다음과 같다.

응답시간은 네이티브 쿼리를 사용했을 때와 비슷하게 가용한 수준으로 나온 것을 알 수 있다.

Hibernate: select member0_.id as id1_5_, member0_.email as email2_5_, member0_.nickname as nickname3_5_, member0_.point as point4_5_, member0_.thumbnail as thumbnai5_5_ from member member0_ where member0_.email=?
Hibernate: select article0_.id as id1_0_0_, member1_.id as id1_5_1_, article0_.body as body2_0_0_, article0_.create_date as create_d3_0_0_, article0_.member_id as member_i6_0_0_, article0_.title as title4_0_0_, article0_.view_count as view_cou5_0_0_, member1_.email as email2_5_1_, member1_.nickname as nickname3_5_1_, member1_.point as point4_5_1_, member1_.thumbnail as thumbnai5_5_1_ from article article0_ inner join member member1_ on article0_.member_id=member1_.id where article0_.id>? limit ?

실제 실행된 쿼리는 위와 같다.

결과 쿼리

네이티브 쿼리와 비교해보겠다.

네이티브 쿼리를 이용하였을 때

Hibernate: 
SELECT Article.id as id, Article.title as title, Article.body as body ,Article.member_id as memberId, Member.nickname as nickname 
	FROM Article 
	INNER JOIN Member ON Article.member_id=Member.id 
	where Article.id> ? 
	limit ?

QueryDsl을 사용했을 때

Hibernate: 
select article0_.id as id1_0_0_, member1_.id as id1_5_1_, article0_.body as body2_0_0_, article0_.create_date as create_d3_0_0_, article0_.member_id as member_i6_0_0_, article0_.title as title4_0_0_, article0_.view_count as view_cou5_0_0_, member1_.email as email2_5_1_, member1_.nickname as nickname3_5_1_, member1_.point as point4_5_1_, member1_.thumbnail as thumbnai5_5_1_ 
from article article0_ 
inner join member member1_ on article0_.member_id=member1_.id 
where article0_.id>? 
limit ?

거의 동일한 쿼리가 나갔음을 알 수 있다.

QueryDsl을 사용한 이유

QueryDsl을 사용해야 했던 이유
다른 부분은 네이티브 쿼리를 이용했을 때에는 프로젝션을 이용했다는 점이고 지금은 전체를 조회한다는 점인데,

그 이유는 페치조인을 사용하기 위함이다.

페치 조인은 엔티티가 아닌 DTO 상태로 조회하는 것은 불가능하다고한다.

이걸 해결하려면 일반 조인을 사용해야하는데, 그렇게되면 네이티브 쿼리에서 QueryDsl로 넘어온 이유도 일부 사라진다.

N+1 문제를 해결함과 동시에 영속성 컨텍스트도 잘 활용하려면 일반 조인이 아니라 페치조인을 사용하고 대신 일부만 조회하는 것을 포기해야 했다.

결과적으로 QueryDsl을 이용해서 성능도 개선하고, N+1 문제도 해결했다.

profile
🙂 🙃 🙂 🙃
post-custom-banner

0개의 댓글