TIL_221021_자바 ORM 표준 JPA 프로그래밍_09 정리 (끝)

창고·2022년 10월 21일
0

12. 객체 지향 쿼리 언어 (2)

(1) 경로 표현식

  • .(점)을 찍어 객체 그래프를 탐색하는 것
select m.username // 상태 필드
from Member m
join m.team t // 단일 값 연관 필드
join m.orders o // 컬렉션 값 연관 필드
where t.name = '팀A'
  • 경로 표현식 용어 정리
    • 상태 필드 (state field) : 단순히 값을 저장하기 위한 필드 (m.username)
    • 연관 필드 (association field) : 연관관계를 위한 필드
      • 단일값 연관 필드 : @ManyToOne, @OneToOne, 대상이 엔티티 (m.team)
      • 컬렉션 값 연관 필드 : @OneToMany, @ManyToMany, 대상이 컬렉션 (m.orders)
  • 경로 표현식 특징
    • 상태 필드 : 경로 탐색의 끝, 탐색 X
    • 단일 값 연관 경로 : 묵시적 내부 조인(INNER JOIN) 발생, 탐색 O -> 성능 저하 이슈 발생 가능
    JPQL : select o.member from Order o
    SQL : select m.* from Orders o INNER JOIN Member m on o.member_id = m.id
    • 컬렉션 값 연관 경로 : 묵시적 내부 조인 발생 탐색 X
      • FROM 절에서 명시적 조인을 통해 별칭을 얻으면 별칭을 통해 탐색 가능
    • 묵시적 조인 가급적 사용하지 마시오
  • 명시적 조인 : JOIN 키워드 직접 사용
select m from Member m join m.team t
  • 묵시적 조인 : 경로 표현식에 의해 묵시적으로 SQL 조인 발생 (내부 조인만 가능)
select m.team from Member m
  • 경로 표현식 예제
select t.members.username from Team t // 실패, 탐색 불가
select m.username from Team t join t.members m // 성공, Member를 별칭으로 가져왔으므로
  • 경로 탐색을 사용한 묵시적 조인 시 주의 사항
    • 항상 내부 조인
    • 컬렉션은 경로 탐색의 끝, 명시적 조인을 통해 별칭을 얻어야 함
    • 경로 탐색은 주로 SELECT, WHERE 절에서 사용하지만 묵시적 조인으로 인해 SQL의 FROM (JOIN) 절에 영향을 줌
  • 실무 조언
    • 가급적 묵시적 조인 대신에 명시적 조인 사용
    • 조인은 SQL 튜닝에 중요 포인트
    • 묵시적 조인은 조인이 일어나는 상황을 한눈에 파악하기 어려움

(2) 페치 조인 기본*** (정말 정말 중요)

  • SQL 조인 종류 X
  • JPQL에서 성능 최적화를 위해 제공하는 기능
  • 연관된 엔티티나 컬렉션을 SQL 한 번에 함께 조회하는 기능
  • join fetch 명령어 사용
  • 페치 조인 :: = [LEFT [OUTER] | INNER] JOIN FETCH 조인 경로
  • 엔티티 페치 조인
    • 회원을 조회하면서 연관된 팀도 함께 조회 (SQL 한 번에)
    • SQL을 보면 회원 뿐만 아니라 팀(T)도 함께 SELECT
    [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
  • 예제 시나리오
String jpql = "select m from Member m join fetch m.team";
List<Member> members = em.createQuery(jpql, Member.class)
						.getResultList(); 
// 이 시점에서 이미 즉시 로딩이 끝나 프록시가 아닌 진짜 엔티티가 결과에 담김

for (Member member : members) {
// 페치 조인으로 회원과 팀을 함께 조회해서 지연 로딩X
// 이미 즉시 로딩을 한 것이기 때문에 추가로 쿼리가 날아갈 일이 없음

	System.out.println("username = " + member.getUsername() + ", " +
	"teamName = " + member.getTeam().name());
} 
  • 컬렉션 페치 조인
    • 일대다 관계, 컬렉션 페치 조인
    [JPQL] select t from Team t join fetch t.members where t.name='팀A'`
     [SQL] SELECT T.*, M.* FROM TEAM T INNER JOIN M ON T.ID=M.TEAM_ID WHERE T.NAME = '팀A'
  • 예제 시나리오
String jpql = "select t from Team t join fetch t.members where t.name = '팀A'"
List<Team> teams = em.createQuery(jpql, Team.class).getResultList();

for(Team team : teams) {

	System.out.println("teamname = " + team.getName() + ", team = " + team);
	for (Member member : team.getMembers()) {
 
		//페치 조인으로 팀과 회원을 함께 조회해서 지연 로딩 발생 안함
		System.out.println(-> username = " + member.getUsername()+ ", member = " + member);
	}
}
  • 페치 조인과 DISTINCT
    • SQL의 DISTINCT는 중복된 결과를 제거하는 명령
    • JPQL의 DISTINCT는 2가지 기능 제공
      • SQL에 DISTINCT를 추가
      • 애플리케이션에서 엔티티 중복 제거
  • select distinct t from Team t join fetch t.members where t.name = '팀A'
  • SQL에 DISTINCT를 추가하지만 데이터가 다르므로 SQL 결과에서 중복 제거 실패
  • DISTINCT가 추가로 애플리케이션에서 중복 제거 시도 (동일 엔티티)
  • 페치 조인과 일반 조인의 차이
    • 일반 조인 실행 시 연관된 엔티티를 함께 조회하지 않음
    • JPQL은 결과를 반환할 때 연관관계 고려 X
    • 단지 SELECT 절에 지정한 엔티티만 조회
    • 여기서는 팀 엔티티만 조회하고 회원 엔티티는 조회 X
    • 페치 조인을 사용할 때에는 연관된 엔티티도 함께 조회 (즉시 로딩)
    • 페치 조인은 객체 그래프를 SQL 한번에 조회하는 개념 -> 대부분의 N+1 문제를 해결

(3) 페치 조인 한계

  • 페치 조인의 특징과 한계
    • 페치 조인 대상에게는 별칭을 줄 수 없음 (Hibernate는 가능하나 가급적 사용 X)
    • 둘 이상의 컬렉션은 페치 조인 할 수 없음
    • 컬렉션을 페치 조인하면 페이징 API(setFirstResult, setMaxResults) 사용 불가
      • 일대일, 다대일 같은 단일 값 연관 필드들은 페치 조인해도 페이징 가능
      • Hibernate는 경고 로그를 남기고 메모리에서 페이징 (매우 위험)
    • 모든 것을 페치 조인으로 해결할 수는 없음
    • 페치 조인은 객체 그래프를 유지할 때 사용하면 효과적
    • 여러 테이블을 조인해서 엔티티가 가진 모양이 아닌 전혀 다른 결과를 내야 하면 페치 조인보다는 일반 조인을 사용하고 필요한 데이터들만 조회해서 DTO로 반환하는 것이 효과적

(4) 엔티티 직접 사용

  • JPQL에서 엔티티를 직접 사용하면 SQL에서 해당 엔티티의 기본 키 값을 사용
[JPQL]
select count(m.id) form Member m // 엔티티의 아이디를 사용
select count(m) from Member m // 엔티티를 직접 사용

[SQL] (JPQL 둘 다 다음 SQL 실행)
select count(m.id) as cnt from Member m
  • 엔티티 직접 사용 - 기본 키 값
// 엔티티를 파라미터로 전달하는 방법
String jpql = “select m from Member m where m = :member”;
List resultList = em.createQuery(jpql)
	.setParameter("member", member)
	.getResultList(); 
 
// 식별자를 직접 전달하는 방법
String jpql = “select m from Member m where m.id = :memberId”;
List resultList = em.createQuery(jpql)
	.setParameter("memberId", memberId)
	.getResultList(); 
select m.* from Member m where m.id=?
  • 엔티티 직접 사용 - 외래 키 값
Team team = em.find(Team.class, 1L);
String qlString = “select m from Member m where m.team = :team”;
List resultList = em.createQuery(qlString)
	.setParameter("team", team)
	.getResultList(); 
    
String qlString = “select m from Member m where m.team.id = :teamId”;
List resultList = em.createQuery(qlString)
	.setParameter("teamId", teamId)
	.getResultList();     
select m.* from Member m where m.team_id=?

(6) Named 쿼리

  • 미리 정의해서 이름을 부여해두고 사용하는 JPQL
  • 정적 쿼리
  • 어노테이션, xml에 정의
  • 애플리케이션 로딩 시점에 초기화 후 재사용
  • 애플리케이션 로딩 시점에 쿼리를 검증
@Entity
@NamedQuery(
			name = "Member.findByUsername",	
            query="select m from Member m where m.username = :username")
public class Member {
 ...
}

List<Member> resultList =
	em.createNamedQuery("Member.findByUsername", Member.class)
		.setParameter("username","회원1")
		.getResultList();

(7) 벌크 연산

  • JPA 변경 감지 기능으로 실행하려면 너무 많은 SQL 실행
    (변경 데이터가 100건일 경우 100번의 UPDATE SQL 실행)
  • 벌크 연산 예제
    • 쿼리 한 번으로 여러 테이블 로우 변경 (엔티티)
    • executeUpdate()의 결과는 영향 받은 엔티티 수 반환
    • UPDATE, DELETE 지원
    • INSERT(insert into .. select, Hibernate 지원)
String qlString = "update Product p " +
				  "set p.price = p.price * 1.1 " +
				  "where p.stockAmount < :stockAmount";
int resultCount = em.createQuery(qlString)
	.setParameter("stockAmount", 10)
	.executeUpdate(); 
  • 벌크 연산 주의
    • 벌크 연산은 영속성 컨텍스트를 무시하고 데이터베이스에 직접 쿼리
      • 벌크 연산을 먼저 실행하거나
      • 벌크 연산 수행 후 영속성 컨텍스트 초기화
profile
공부했던 내용들을 모아둔 창고입니다.

0개의 댓글