JPA 관련 주의 사항 정리

👉 Fetch Join의 한계

페치 조인을 쓰면 연관된 전체 데이터를 다 가져와야 한다!

만약에 조건에 만족하는 연관된 데이터만 가져올 경우 Collection에 전체 데이터가 담기지 않고 선택된 데이터만 담긴 다음 영속화 되어버린다. 이 때 다른 곳에서 해당 Collection을 호출 할 경우 정상적으로 데이터를 반환하지 못하게 된다. JPA의 Fetch Join 목적 자체는 전체 데이터를 가져오려고 설계 된 것임을 유의하자.

둘 이상의 Collection을 Fetch Join 하면 안된다!

데이터가 뻥튀기 된다. 곱하기 곱하기가 되어서 데이터가 예상치 못하게 늘어날 수 있다.

Collection을 Fetch Join하면 페이지 기능을 사용할 수 없다.

일대일, 다대일은 페이징을 쓸 수 있다. (데이터 뻥튀기가 안되기 때문에) 그런데 일대다는 페이징 기능을 쓸 수 없다.

위와 같은 경우 TeamId가 1인데이터가 2건이 나오는데 만약 페이지 사이즈가 1이면 2개가 아닌 1개의 데이터만 가져오게 된다. 그럼 Team1 은 회원이 1명 밖에 없는 결과가 나온다. 때문에 일대다에선 페이징을 쓰면 안된다.

만악 페이징을 진행하게 될 경우 메모리에서 페이징을 처리하게 되는데, 이를 다시 말하자면 DB에서 페이지 단위로 잘라 가져오는게 아닌 전체 데이터를 가져오게 되는 것이다. (장애 나기 딱 쉬운 유형)

페이징을 사용하려면

• 방향을 뒤집어서 팀이 아닌 멤버를 기준으로 조회

• 배치 사이즈 활용! (글로벌 셋팅으로 활용도 가능)

👉 Fetch Join의 특징

---

엔티티에 직접 적용하는 (Lazy Loading 같은 설정보다 우선시 되는게 페치 조인!

JPA의 성능 문제는 N+1에서 비롯되는데 거의 모든 경우 Fetch Join으로 해결 가능

페치 조인은 객체 그래프를 유지할 떄 사용하면 효과적이다.

만약! 여러 테이블의 데이터를 조회해서 엔티티가 가진 모양이 아닌 전혀 다른 결과를 내야 한다면 페치 조인 보다는 일반 조인을 사용하고 필요한 데이터들만 조회해서 DTO로 반환하는게 효과적이다.

👉 Named 쿼리의 장점 (실무에서는 Spring Data JPA를 쓴다)

---

무슨 장점이 있을까?

• 어플리케이션 로딩 시점에 초기화 한다음 재사용한다.

이게 무슨 얘기냐면 어플리케이션 로딩 시점에 JPA 또는 하이버네이트가 SQL로 파싱을 해서 캐시하고 있는다. JPQL는 SQL로 파싱이 되어야 되는데 변환하는 Cost가 있다. 하지만 Named 쿼리는 로딩 시점에 파싱이 되기 때문에 해당 Cost가 없다!

• 어플리케이션 로딩 시점에 쿼리를 검증할 수 있다.

Querydsl과 다르게 JPQL은 컴파일 시점에 작성한 JPQL의 오류를 검증할 수 없다. 하지만 Named쿼리는 어플리케이션 로딩 시점에 이것을 잡아 줄 수 있다.

❓ 컴파일과 어플리케이션 로딩 시점의 차이는?

컴파일은 소스 코드를 실행 가능한 형태로 변환하는 것을 의미

어플리케이션 로딩은 실행 가능한 코드를 메모리에 로드하고 초기화 하는 작업을 의미

즉 정리하자면 컴파일 → 어플리케이션 로딩 → 런타임 순으로 이루어진다.

👉 벌크성 수정 쿼리

---

순수 JPA에서 ExecuteUpdate()를 활용한 벌크 수정 (변경 감지 기능 사용 시 쿼리 무지막지 하게 나가는 현상 방지)

Spring Data JPA에서는 어떻게 할까?

이런식으로 Query에 Modifying 어노테이션을 붙여주면 ExecuteUpdate() 가 적용된다!

그런데 만약 Modifying을 빼면 어떻게 될까?

요런 에러 메세지가 뜨게 된다.

그런데 JPA에서는 벌크성 연산은 조심해야 한다. 왜?

벌크 연산은 영속성 컨텍스트를 무시하고 바로 DB에 SQL을 때려버리는 로직이다. 이를 다시 말하자면, 벌크 연산을 떄리고 난 뒤에 영속성 컨텍스트에 있는 요소를 하나 조회한다면? 업데이트 결과가 반영되지 않는 경우가 생길 수 있다는 말이다.

member 나이는 1살 추가하고 조회한다면? 어떻게 될까? 잘보면 중간에 벌크 연산을 날리는 것을 알 수 있다. 저거 조회해보면 40살 그대로 나온다. 왜? db에는 나이가 업데이트 되었지만, 영속성 컨텍스트는 아직 반영이 안되었기 때문이다.

그럼 어떻게 해야해?

벌크 연산을 날린 뒤 영속성 컨텍스트를 다음과 같이 날려줘야 한다. 그러면 영속성 컨텍스트에 엔티티가 다 비워지게 되겠지? 그럼 다시 member를 조회하게 되면 db에 접근하여 업데이트 된 데이터를 가져오기 때문에 위와 같은 문제가 발생하지 않는다!

벌크 연산시 em.flush / em.clear 꼭 해주자!

근데 Spring Data Jpa는 이 처리를 대신해서 할 수 있다! Modifying에 옵션을 주면 된다.

ClearAutomatically = true 옵션을 주면 em.flush와 같은 작업을 안해줘도 된다!

👉 페이징 한계 돌파

---

일 대 다 관계는 Fetch Join 을 할 경우 페이징 처리가 되지 않는다. 이를 어떻게 해결 할까?

해결 방법

1. 먼저 ToOne 관계를 모두 페치조인 한다. (row수가 똑같 → 페이징 쿼리에 영향을 주지 않으므로)

2. 컬렉션은 지연 로딩으로 조회한다.

3. 지연 로딩 성능 최적화를 위해 BatchSize를 적용한다

BathSize는 100 ~ 1000 사이를 추천

👉 엔티티 조회가 권장 되는 이유

페치 조인을 쓸 수 있다. 코드를 거의 수정하지 않고 옵션만 변경하여 다양한 성능 최적화를 시도할 수 잇다. DTO 조회 방식은 쿼리 값을 찍어서 가져오는 방식 (엔티티 사용하는 것이 아님) 성능 변경할 시 많은 코드를 수정해야 한다.