[도전 기술!] JPA와 Querydsl

안녕하세요? 주니하랑 입니다.

본 내용은 주니하랑이 Web 개발 프로젝트를 하면서 도전했던 기술들에 대한 내용을 정리하는 곳 입니다!

이 글은 함께 프로젝트 했던 Back End 꿈나무 Crew가 작성한 것이에요.

주니하랑도 Back End 개발을 맡았었답니다!

 

 

[에이콘출판]스프링과 JPA를 활용한 자바 엔터프라이즈 애플리케이션 개발 세트 - 전3권

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."

 

---

 

 

❓ 이번 프로젝트에서 우리는 JPA를 왜 사용했는가?

• sql 중심적인 개발에서 객체 중심적인 개발이 가능
• 생산성이 증가하고 간단한 메서드로 CRUD가 가능
• 유지보수가 쉽다JPA: 필드만 추가, SQL은 JPA가 처리
• 기존: 필드 변경 시 모든 SQL을 수정
• Object와 RDB 간의 패러다임 불일치 해

 

👉 JPA 영속성

JPA의 핵심은 엔티티가 영속성 컨텍스트에 포함되어 있는지 없는지로 나뉩니다. JPA의 엔티티 매니저가 활성화된 상태로 트랜잭션(@Transactional) 안에서 DB에서 데이터를 가져오면 이 데이터는 영속성 컨텍스트가 유지된 상태입니다. 이 상태에서 해당 데이터 값을 변경하면 트랜잭션이 끝나는 시점에 해당 테이블에 변경 내용을 반영하게 됩니다.

우리는 엔티티 객체의 필드 값만 변경해주면 별도로 update()쿼리를 날릴 필요가 없게 됩니다! 이 개념을 더티 체킹이라고 합니다.

영속성 컨테스트란?

엔티티를 담고 있는 집합.

JPA는 영속 컨텍스트에 속한 엔티티를 DB에 반영한다. 엔티티를 검색, 삭제, 추가

하게 되면 영속 컨텍스트의 내용이 DB에 반영된다. 영속 컨텍스트는 직접 접근이 불가능하고 Entity Manager를 통해서만 접근이 가능하다.

JPA 성능 최적화

1. 1차 캐시와 동일성보장
   • 같은 트렌젝션 안에서 같은 Entity를 반환
   • SQL를 한번만 실행
2.  지연로딩
   • 객체가 실제로 사용될 때 로딩하는 전략
   • Find 예시

Optional<DiscussionBoard> findById(@Param("id") Long id);

예시처럼 작성을 하게 되면 id에 대한 값을 FindById 메소드를 통해서 값을 조회 할 수 있습니다.즉, 값이 실제로 필요한 시점에 JPA가User에 대한 SELECT 쿼리를 날린다.DiscussionBoard 를 사용하는 경우에 대부분 User도 같이 필요하다면 즉시 로딩을 사용한다.아래 사진은 상세 조회를 했을 때 N + 1 입니다. 하지만 조회를 할 때 연관 관계가 있으면 N + 1 현상이 발견이 되었습니다. 한개의 Query문만 필요하지만 JPA에서는 연관관계에 있는 테이블까지 같이 조회해서 조회가 2번이 되는 현상이 있었습니다. DiscussionBoard 와 User객체 각각 따로 조회하기 때문에 네트워크를 2번 타게 된다. Optional<DiscussionBoard> findById(@Param("id") Long id) 에서는 DiscussionBoard 객체에 대한 SELECT 쿼리만 날립니다.

즉, 값이 실제로 필요한 시점에 JPA가User에 대한 SELECT 쿼리를 날립니다.

DiscussionBoard 와 User객체 각각 따로 조회하기 때문에 네트워크를 2번 타게 됩니다.

DiscussionBoard 를 사용하는 경우에 대부분 User도 같이 필요하다면 즉시 로딩을 사용합니다.

하지만 조회를 할 때 연관 관계가 있으면 N + 1 현상이 발견이 되었습니다. 한개의 Query문만 필요하지만 JPA에서는 연관관계에 있는 테이블까지 같이 조회해서 조회가 2번이 되는 현상이 있었습니다.

아래 사진은 상세 조회를 했을 때 N + 1 입니다.

 

N+1이란

연관 관계에서 발생하는 이슈로 연관 관계가 설정된 엔티티를 조회할 경우에 조회된 데이터 갯수(n) 만큼 연관관계의 조회 쿼리가 추가로 발생하여 데이터를 읽어오게 된다.

게시판 상세보기 FindById 메소드를 사용 시 게시판에 대한 Query문과 유저에 대한 Query문이 같이 나오게 되었습니다. 이를 해결하기 위해서 FetchJoin을 사용했습니다.

FetchJoin 은 연관관계가 있는 Entity를 한번에 조회 할 수 있는 기능이 있다는 것을 듣고 적용을 시켰습니다.

 

Update 예시

queryRepository.updateBoard(update, board.getId(), board.getUser().getId());

 

수정을 할 시에도 Update 메소드를 사용해 쉽게 데이터를 수정할 수 있었습니다.

Update 메소드를 사용했을 때 쿼리문입니다.

 

Delete 예시

queryRepository.deleteBoard(board.getId(), board.getUser().getId());

728x90

삭제를 할 시에도 Delete 메소드를 사용해서 데이터를 삭제 할 수 있었습니다.

 

 

Delete메소드를 사용했을 때 쿼리문입니다.

 

Querydsl이란?

• JPQL의 빌더 역할을 하는 오픈
• Query를 자바코드로 작성
• 타입 세이프

Querydsl를 사용하면 JPA를 사용했을 때보다 쿼리문을 직관적으로 볼 수 있었습니다.

Querydsl를 사용하기 위해서는 JPAQueryFactory클래스의 인스턴스를 생성해야 합니다.

Q-Type을 이용해서 Querydsl를 빌드 합니다.

• Find Querydsl 예시

• public Optional<DiscussionDetailResponse> findByDiscussionId(Long id){
  
          DiscussionDetailResponse board =
                  queryFactory
                          .select(Projections.constructor(DiscussionDetailResponse.class,
                                  discussionBoard.id,
                                  user.id,
                                  user.nickName,
                                  discussionBoard.title,
                                  discussionBoard.content,
                                  discussionBoard.createAt,
                                  discussionBoardReadhit.count))
                          .from(discussionBoard)
                          .innerJoin(discussionBoard.user, user)
                          .join(discussionBoardReadhit).on(discussionBoardReadhit.discussionBoard.id.eq(discussionBoard.id))
                          .where(discussionBoard.id.eq(id))
                          .fetchOne();
  
          return Optional.ofNullable(board);
  
      }

 

 

게시판 번호를 조회하는 쿼리문입니다. User와 DiscussionBoardReadhit의 정보도 조회를 해야 합니다. 여기서 연관관계가 있는 Entity는 inner join()을 사용하고 연관관계가 없는 Entity는 join().on()을 사용해서 N+1 현상을 막으면서 조회를 할 수 있었습니다.

 

Querydsl로 연관관계인 User는 innerjoin()을 연관관계가 없는 discussionReadhit은 join().on()을 이용해서 조회한 쿼리문입니다.

 

 

Update Querydsl 예시

public void updateBoard(DiscussionEditRequest update, Long id, Long userId) {

        JPAUpdateClause updateClause = new JPAUpdateClause(em, discussionBoard);

        updateClause
                .where(discussionBoard.id.eq(id), discussionBoard.user.id.eq(userId))
                .set(discussionBoard.title, update.getTitle())
                .set(discussionBoard.content, update.getContent())
                .set(discussionBoard.createAt, update.getCreateAt())
                .execute();
    }

Update시에는 JPAUpdateClaus를 사용해서 where 절과 set을 통해서 데이터를 수정할 수 있었습니다.

 

 

Update시에는 JPAUpdateClaus를 사용해서 where 절과 set을 통해서 데이터를 수정할 수 있었습니다.

 

Delete Querydsl 예시

public void deleteBoard(Long id, Long userId) {

        JPADeleteClause deleteClause = new JPADeleteClause(em, discussionBoard);

        deleteClause
                .where(discussionBoard.id.eq(id), discussionBoard.user.id.eq(userId))
                .execute();
    }

 

Delete시에는 JPADeleteClaus를 사용해서 where절을 통해서 데이터를 삭제 할 수 있었습니다.

 

Querydsl를 사용해서 Delete시 쿼리문입니다.

 

 

[에이콘출판]스프링과 JPA를 활용한 자바 엔터프라이즈 애플리케이션 개발 세트 - 전3권

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."

 

 

 

결론

JPA에 대해 공부를 하면서 단순 메소드명으로 JPA가 알아서 DB에 데이터를 등록, 조회, 업데이트, 삭제를 해주는 것에 편리하다겠다라는 생각을 하게 되었지만, 직접 JPA를 사용하면서 Insert 구문은 사용자가 임의로 쿼리문을 작성해서 실행 시킬 수 없다는 것을 알게 되었습니다.

Entity에서 연관관계인 객체를 지연로딩으로 지정하면 N+1를 방지 할 수 있을 줄 알았지만 DiscussionBoard에서 User 와 연관관계에 있으니 쿼리문이 2개 발생하였습니다. N+1 현상이 발생하게 된 것을 알게 되었고, 이를 해결하기 위해서 FetchJoin을 이용해서 DiscussionBoard와 User 객체를 1개의 쿼리문으로 조회를 하는 것을 확인 할 수 있었습니다.

Querydsl은 Entity Class 를 wrapping 한 Qxxx class 를 사용하기 때문에 Entity Annotation이 있는 클래스들을 Qxxx class 로 자동 생성하도록 설정해주게되면 자바코드를 이용해서 Entity와 Qxxx type-safe를 통해서 DB의 값을 조회, 저장, 삭제를 할 수 있었습니다.

Querydsl에서 N+1현상은 연관관계인 경우에는 innerjoin(), 연관관계가 없는 경우에는 join().on()을 통해서 방지 할 수 있었습니다.

이번 프로젝트에서 JPA와 Querydsl를 이용해서 DB에 값을 저장했습니다.