출처 : https://www.inflearn.com/course/ORM-JPA-Basic
자바 ORM 표준 JPA 프로그래밍 - 기본편 강의 - 인프런
회사땜에 매일 바쁜 와중에 학원이라도 다닐까 생각했는데 마침 JPA 강의가 생겨서 꿀 타이밍이네요. 저는 이 전에 JPA 책을 보고 공부 했었는데요 궁금했던 점, 업무에 적용하며 고민하고 해결하
www.inflearn.com
경로 표현식
.(점)을 찍어 객체 그래프를 탐색하는 것
- 상태 필드(state field): 단순히 값을 저장하기 위한 필드
- 연관 필드(association filed): 연관관계를 위한 필드
- 단일 값 연관 필드 : @ManyToOne, @OneToMany, 대상이 엔티티
- 컬렉션 값 연관 필드 : @OneToMany, @ManyToMany, 대상이 컬렉션
경로 표현식 특징
- 상태 필드 : 경로 탐색의 끝, 탐색X
- 단일 값 연관 경로 : 묵시적 내부 조인(inner join) 발생, 탐색O (m.team)
- 컬렉션 값 연관 경로 : 묵시적 내부 조인 발생, 탐색X
FROM절에서 명시적 조인을 통해 별칭을 얻으면 별칭을 통해 탐색 가능
Team을 가져와야할 때 DB입장에서는 Member 테이블 안에 Team_id라는 컬럼만 있고 Team과 연관관계로 이어져 있기 때문에 Team 전체를 찾아오기 위해 내부 조인이 발생할 수 밖에 없다.
실무에서 묵시적 조인 사용 X (쿼리 튜닝 어려움)
명시적 조인, 묵시적 조인
- 명시적 조인, 묵시적 조인
select m from Member m join m.team t - 묵시적 조인 : 경로 표현식에 의해 묵시적으로 SQL 조인 발생 (내부 조인만 가능)
select m.team from Member m
경로 탐색을 사용한 묵시적 조인 시 주의사항
- 항상 내부 조인
- 컬렉션은 경로 탐색의 끝, 명시적 조인을 통해 벼링 얻어야 함.
- 경로 탐색은 주로 SELECT, WHERE 절에서 사용하지만 묵시적 조인으로 인해 SQL의 FROM (JOIN)절에 영향을 줌
페치 조인(FETCH JOIN) 1 - 기본
- SQL 조인 종류X
- JPQL에서 성능 최적화를 위해 제공하는 기능
- 연관된 에티티나 컬렉션을 SQL 한 번에 함께 조회하는 기능
- join fetch 명령어 사용
- 페치 조인 ::= [LEFT [OUTER] | INNER ] JOIN FETCH 조인 경로
회원을 조회할 때 연관된 팀도 함께 조회하고 싶어요 (SQL 한 번에)
[JPQL]
select m from Member m join fetch m.team
[SQL]
SELECT M.*, T.* FROM MEMBER M
INNER JOIN TEAM T ON M.TEAM_ID = T.ID
JPA 클래스
Team teamA = new Team();
teamA.setName("팀A");
em.persist(teamA);
Team teamB = new Team();
teamB.setName("teamB");
em.persist(teamB);
Member member1 = new Member();
member1.setUsername("회원1");
member1.setTeam(teamA);
em.persist(member1);
Member member2 = new Member();
member2.setUsername("회원2");
member2.setTeam(teamA);
em.persist(member2);
Member member3 = new Member();
member3.setUsername("회원3");
member3.setTeam(teamB);
em.persist(member3);
// 영속성 컨텍스트 제거
em.flush();
em.clear();
// Member와 Team을 조인해서 가져옴
String query = "select m From Member m join fetch m.team";
List<Member> result = em.createQuery(query, Member.class)
.getResultList();
for (Member m : result) {
System.out.println("member = " + m.username + ", " + m.getTeam().name);
// member = 회원1, 팀A
// member = 회원2, 팀A
// member = 회원3, 팀B
}
tx.commit();
실행되는 쿼리 : SELECT m.*, t.* FROM member m inner join team t on m.team_id = t.id
컬렉션 페치 조인
- 일대다 관계, 컬렉션 페치 조인
- [JPQL]
select t
from Team t join fetch t.members
where t.name = '팀A' - [SQL]
SELECT T.*, M.*
FROM TEAM T - INNER JOIN MEMBER M ON T.ID=M.TEAM_ID
WHERE T.NAME
String query = "select t From Team t join fetch t.members";
List<Team> result = em.createQuery(query, Team.class)
.getResultList();
for (Team t : result) {
System.out.println("team =" + t.getName() + ", " + teamA.getMembers().size());
// team = 팀A, 2
// team = 팀A, 2
// team = 팀B, 1
}
팀A에 회원이 여러명 있으면 팀이 중복된 row가 여러개 뽑힘.
페치 조인을 실행했을 때 팀A가 중복되기 때문에 영속성 컨텍스트에 있는 팀A가 나오고 2개의 팀A는 같은 주소값을 갖는다.
페치 조인과 DISTINCT
- SQL의 DISTINCT는 중복된 결과를 제거하는 명령
- JPQL의 DISTINCT 2가지 기능 제공
- 1. SQL에 DISTINCT를 추가
- 2. 애플리케이션에서 엔티티 중복 제거
- select distinct t
from Team t join fetch t.members
where t.name = '팀A' - SQL에서 DISTINCT를 추가하지만 데이터가 완전히 똑같지 않으므로 SQL 결과에서는 중복제거 실패함
String query = "select distinct t From Team t join fetch t.members";
List<Team> result = em.createQuery(query, Team.class)
.getResultList();
- DISTINCT가 추가로 애플리케이션에서 중복 제거 시도
- 같은 식별자를 가진 Team 엔티티 제거
[DISTINCT 추가시 결과]
teamname = 팀A, team = Team@0x100
-> username = 회원1, member = Member@0x200
-> username = 회원2, member = Member@0x300
= 회원의 주소는 같지만 멤버의 주소는 다름!
페치 조인과 일반 조인의 차이
- 일반 조인 실행시 연관된 데이터를 함께 조회하지 않음
- [JPQL]
select t
from Team t join t.members m
where t.name = '팀A' - [SQL]
- SELECT T.*
FROM TEAM T
INNER JOIN MEMBER M ON T.ID=M.TEAM_ID
WHERE T.NAME = '팀A' - JPQL은 결과를 반환할 때 연관관계 고려X
- 단지 SELECT 절에 지정한 엔티티만 조회할 뿐
- 여기서는 팀 엔티티만 조회하고, 회원 엔티티는 조회X
- 페치 조인을 사용할 때만 연관된 엔티티도 함께 조회 (즉시 로딩)
- 페치 조인은 객체 그래프를 SQL 한 번에 조회하는 개념
- 페치 조인은 연관된 엔티티를 함께 조회함
- [JPQL]
select t
from Team t join fetch t.members
where t.name = '팀A' - [SQL]
SELECT T.*, M.*
FROM TEAM T
INNER JOIN MEMBER M ON T.ID=M.TEAM_ID
WHERE T.NAME = '팀A'
페치 조인 2 - 한계
- 페치 조인 대상에는 별칭을 줄 수 없다.
(하이버네이트는 가능, 가급적 사용x) - 둘 이상의 컬렉션은 페치 조인 할 수 없다.
- 컬렉션을 페치 조인하면 페이징 API(setFirstResult, setMaxResults)를 사용할 수 없다.
- 일대다 페치 조인으로 데이터를 가져왔을 때 같은 컬렉션인 데이터가 2건이고 페이징 사이즈를 1로 지정했다면 데이터가 1개만 가져와짐.
- 일대일, 다대일 같은 단일 값 연관 필드들은 페치 조인해도 페이징 가능
- 하이버네이트는 경고 로그를 남기고 DB에서 모든 데이터를 가져온 후 메모리에서 페이징(매우 위험, 사용 X)
1. 다대일로 데이터를 가져오는 것을 일대다로 변경
2. 페치 조인을 하지않고 모든 컬렉션 데이터를 가져온 후 지연 로딩으로 나머지 데이터를 가져오는데 @BatchSize() 어노테이션을 사용하거나 배치 사이즈를 글로벌 세팅하면 조회한 컬렉션의 id를 fk로 가진 나머지 데이터들을 한 번에 조회함.
3. DTO 사용
배치 사이즈 어노테이션
Team 클래스
@Entity
public class Team {
@Id @GeneratedValue
private Long id;
private String name;
@BatchSize(size = 100)
@OneToMany(mappedBy = "team")
private List<Member> members = new ArrayList<>();
...
JPA 클래스
String query = "select t from team t";
List<Team> result = em.createQuery(query, Team.class)
.setFirstResult(0)
.setMaxResults(2)
.getResultList();
글로벌 세팅(이거 쓰기)
Persistence.xml
<!-- batch_size : 쿼리를 value만큼 모아뒀다가 전송하는 것, 버퍼링 같은 기능 value는 1000이하로 -->
<property name="hibernate.default_batch_fetch_size" value="100"/>
페치 조인의 특징과 한계
- 연관된 엔티티들을 SQL 한 번으로 조회 - 성능 최적화
- 엔티티에 직접 적용하는 글로벌 로딩 전략보다 우선함
@OneToMany(fetch = FetchType.LAZY) // 글로벌 로딩 전략 - 실무에서 글로벌 로딩 전략은 모두 지연 로딩
- 최적화가 필요한 곳은 페치 조인 적용
페치 조인 - 정리
- 모든 것을 페치 조인으로 해결할 수는 없음
- 페치 조인은 객체 그래프를 유지할 때 사용하면 효과적 (member.team.name)
- 여러 테이블을 조인해서 엔티티가 가진 모양이 아닌 전혀 다른 결과를 내야 하면 페치 조인보다는 일반 조인을 사용하고 필요한 데이터들만 조회해서 DTO로 반환하는 것이 일반적
다형성 쿼리
TYPE
- 조회 대상을 특정 자식으로 한정
- 예) Item 중에 Book, Movie를 조회해라
- [JPQL]
select i from Item i
where type(i) IN (Book, Movie) - [SQL]
select i from i
where i.DTYPE in ('B', 'M')
TREAT(JPA 2.1)
- 자바 타입 캐스팅과 유사
- 상속 구조에서 부모 타입을 특정 자식 타입으로 다룰 때 사용
- FROM, WHERE, SELECT(하이버네이트 지원) 사용
- 예) 부모인 Item과 자식 Book이 있다.
- [JPQL]
select i from Item i
where treat(i as Book).author = 'kim' - [SQL]
select i.* from Item i
where i.DTYPE = 'B' and i.author = 'kim'
엔티티 직접 사용
기본 키 값
- JPQL에서 엔티티를 직접 사용하면 SQL에서 해당 엔티티의 기본 키 값을 사용
- [JPQL]
select count(m.id) from Member m // 엔티티의 아이디를 사용
select count(m) from Member m // 엔티티를 직접 사용 - [SQL] (JPQL 둘 다 같은 sql문 실행됨)
select count(m.id) as cnt from Member m - 엔티티를 파라미터로 전달하거나 식별자를 전달하는 것도 기본 키 값이 사용 됨.
외래 키 값
String query = "select m from Member m where m.team = :team";
List<Member> result = em.createQuery(query, Member.class)
.setParameter("team", team)
.getResultList();
String query = "select m from Member m where m.team.id = :teamId";
List<Member> result = em.createQuery(query, Member.class)
.setParameter("teamId", teamId)
.getResultList();
실행된 SQL
select m.* from Member m where m.team_id = ?
Named 쿼리
정적 쿼리
- 미리 정의해서 이름을 부여해두고 사용하는 JPQL
- 정적 쿼리 (동적으로 사용X)
- 어노테이션, XML에 정의
- 애플리케이션 로딩 시점에 초기화 후 재사용
- 애플리케이션 로딩 시점에 쿼리를 검증 (쿼리에 오류가 있으면 QuerySyntax Exception 발생)
Member 클래스
@Entity
@NamedQuery(
name = "Member.findByUsername",
query = "select m from Member m where m.username = :username"
)
public class Member {
...
JPA 클래스
List<Member> resultList = em.createNamedQuery("Member.findByUsername", Member.class)
.setParameter("username","회원1")
.getResultList();
Named 쿼리 환경에 따른 설정
- XML이 항상 우선권을 가진다.
- 애플리케이션 운영 환경에 따라 다른 XML을 배포할 수 있다.
벌크 연산
- 재고가 0개 미만인 모든 상품의 가격을 10% 상승하려면?
- JPA 변경 감지 기능으로 실행하기에는 너무 많은 SQL이 실행됨.
- 1. 재고가 10개 미만인 상품을 리스트로 조회한다.
- 2. 상품 엔티티의 가격을 10% 증가한다.
- 3. 트랜잭션 커밋 시점에 변경감지가 동작한다.
- 변경된 데이터가 100건이라면 100번의 UPDATE SQL 실행됨.
- 쿼리 한 번으로 여러 테이블 로우 변경(엔티티)
- executeUpdate()의 결과는 영향받은 엔티티 수 반환
- UPDATE, DELETE 지원
- INSERT(inser into .. select, 하이버네이트 지원)
int resultCount = em.createQuery("update Member m set m.age = 20")
.executeUpdate();
System.out.println(resultCount);
벌크 연산 주의
- 벌크 연산은 영속성 컨텍스트를 무시하고 데이터베이스에 직접 쿼리
- 벌크 연산을 먼저 실행
- 벌크 연산 수행 후 영속성 컨텍스트 초기화
'코딩 > JPA' 카테고리의 다른 글
[JPA] 객체지향 쿼리 언어(JPQL) - 기본 문법(2) (0) | 2024.02.05 |
---|---|
[JPA] 객체지향 쿼리 언어(JPQL) - 기본 문법(1) (0) | 2024.02.05 |
[JPA] 값 타입 (0) | 2023.12.07 |
[JPA] 프록시와 연관관계 관리 (0) | 2023.12.07 |
[JPA] 상속관계 매핑 (0) | 2023.12.04 |