[자바 ORM 표준 JPA 프로그래밍 - 기본편] 객체지향쿼리언어2 - 중급문법

인프런 - 자바 ORM 표준 JPA 프로그래밍 (김영한님) 

 

JPQL - 경로 표현식

• 점을 찍어 객체 그래프를 탐색하는 것
  • m.username : 상태 필드
  • m.team : 단일 값 연관 필드
  • m.orders : 컬렉션 값 연관 필드

• 상태 필드 (state field)
  • 단순히 값을 저장하기 위한 필드
  • 경로 탐색의 끝, 탐색 X
• 연관 필드 (association field)
  • 단일 값 연관 필드
    • @ManyToOne, @OneToOne, 대상이 엔티티
    • 묵시적 내부 조인 (INNER JOIN) 발생, 탐색 O
    • 실무에서는 묵시적 내부 조인이 발생하도록 쿼리를 짜면 안됨 !!
  • 컬렉션 값 연관 필드
    • @OneToMany, @ManyToMany, 대상이 컬렉션
    • 묵시적 내부 조인 (INNER JOIN) 발생, 탐색 X
    • FROM 절에서 명시적 조인을 통해 별칭을 얻으면 별칭을 통해 탐색 가능

 

SELECT m.username FROM Team t JOIN t.members m

 

 

 

명시적 조인, 묵시적 조인

• 명시적 조인: JOIN 키워드 직접 사용
• 묵시적 조인 : 경로 표현식에 의해 묵시적으로 SQL 조인 발생 (INNER JOIN만 발생함)

 

 

 

JPQL - 패치 조인 (Fetch Join)

• 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
• 패치조인을 사용하지 않으면 N+1이 발생할 수 있음

 

N+1 이슈

Team teamA = new Team();
teamA.setName("Team A");
entityManager.persist(teamA);

Team teamB = new Team();
teamA.setName("Team B");
entityManager.persist(teamB);

Member member1 = new Member();
member1.setUsername("member1");
member1.setTeam(teamA);
entityManager.persist(member1);

Member member2 = new Member();
member2.setUsername("member2");
member2.setTeam(teamA);
entityManager.persist(member2);

Member member3 = new Member();
member3.setUsername("member3");
member3.setTeam(teamB);
entityManager.persist(member3);

String sql = "select m from Member m";
List<Member> members = entityManager.createQuery(sql, Member.class)
    .getResultList();

for(Member member : members) {
    System.out.println(member.getUsername() + " : " + member.getTeam().getName());
}

transaction.commit();

• sql에서 fetch join을 사용하지 않고 Member만 조회한 후 member.getTeam().getName()을 조회할 경우
• 회원에 팀이 존재하면 팀마다 Team 엔티티를 조회하는 쿼리가 계속 나감
• ex)
  • member1, Team A (SQL 쿼리)
  • member2, Team A (1차 캐시에서 조회)
  • member3, Team B (SQL 쿼리)
  • member4, Team C (SQL 쿼리)
  • 회원이 100명이고, Team이 모두 달라 100개의 팀이 존재하면 쿼리가 회원 조회 쿼리 (1) + 팀 조회 쿼리 (100)번 나감 -> N+1

 

 

Fetch Join

String sql = "select m from Member m join fetch m.team";

// 조회 쿼리 
Hibernate: 
    /* select
        m 
    from
        Member m 
    join
        fetch m.team */ 
select
            member0_.id as id1_0_0_,
            team1_.id as id1_3_1_,
            member0_.age as age2_0_0_,
            member0_.TEAM_ID as TEAM_ID4_0_0_,
            member0_.username as username3_0_0_,
            team1_.name as name2_3_1_ 
        from
            Member member0_ 
        inner join
            Team team1_ 
                on member0_.TEAM_ID=team1_.id
member1 : Team A
member2 : Team A
member3 : Team B

 

• sql문만 join fetch를 추가하면 쿼리 한번에 팀까지 모두 조회 가능
• Team은 여기서 프록시가 아니라 실제 엔티티를 조회함
• 지연 로딩으로 세팅하지만 fetch join이 우선임

 

 

 

컬렉션 패치 조인

• 일대다 관계
• JPQL
  • SELECT t FROM Team t JOIN FETCH t.members WHERE t.name = 'Team A'
• SQL
  • SELECT T.*, M.* FROM TEAM T INNER JOIN MEMBER M ON T.ID = M.TEAM_ID WHERE T.NAME = 'Team A'

 

 

 

컬렉션 패치 조인 예제

String sql = "select t from Team t join fetch t.members";
List<Team> teams = entityManager.createQuery(sql, Team.class)
					.getResultList();

for(Team team : teams) {
	System.out.println(team.getName() + " : " + team.getMembers().size());
}

// 조회 쿼리 
Hibernate: 
    /* select
        t 
    from
        Team t 
    join
        fetch t.members */ select
            team0_.id as id1_3_0_,
            members1_.id as id1_0_1_,
            team0_.name as name2_3_0_,
            members1_.age as age2_0_1_,
            members1_.TEAM_ID as TEAM_ID4_0_1_,
            members1_.username as username3_0_1_,
            members1_.TEAM_ID as TEAM_ID4_0_0__,
            members1_.id as id1_0_0__ 
        from
            Team team0_ 
        inner join
            Member members1_ 
                on team0_.id=members1_.TEAM_ID
                
Team A : 2
Team A : 2
Team B : 1

 

• 데이터 뻥튀기 .. Team A 를 2번 출력함

 

 

패치조인과 DISTINCT

• SQL의 DISTINCT는 중복된 결과를 제거하는 명령
• JPQL의 DISTINCT
  • SLQ에 DISTINCT를 추가
  • 애플리케이션에서 엔티티 중복 제거

String sql = "select distinct t from Team t join fetch t.members"

• SQL에서는 DISTINCT를 추가하지만 데이터가 다르므로 SQL 결과에서 중복 제거 실패
  • 완전히 똑같아야 한줄이 나옴 Member의 ID, TEAM_ID, NAME이 모두 같아야 함 (그럴 수 없겠지..?)
• JPQL의 DISTINCT가 추가로 애플리케이션에서 중복 제거를 시도함
  • 같은 식별자를 가진 Team 엔티티를 제거

• 결론!!!
  • 일대다 관계에서 join fetch를 쓸 때 DISTINCT를 사용하자

 

 

패치조인과 일반조인의 차이

• 일반 조인 실행시 연관된 엔티티를 함께 조회하지 않음
  • SQL은 join 쿼리가 나가지만 t.members를 가져올 때 Member 조회 쿼리가 추가로 실행됨
• 패치 조인을 사용할 때만 연관된 엔티티도 함께 조회 (즉시 로딩이 일어난다 보면 됨)
  • 객체 그래프를 SQL 한번에 조회하는 개념

 

 

 

패치조인의 특징과 한계

• 패치 조인 대상에는 별칭을 줄 수 없다
  • 하이버네이트는 가능하지만 가급적 사용하지 말기
• 둘 이상의 컬렉션은 패치 조인 할 수 없다
  • t.members, t.orders > 곱하기 곱하기가 됨 > 데이터 정합성 문제가 발생
• 컬렉션을 패치조인하면 페이징 API를 사용할 수 없다
  • 일대일, 다대일 같은 단일 값 연관 필드들은 패치 조인해도 페이징 가능
  • 일대다는 데이터 뻥튀기가 되기 때문에 페이징 X
  • 하이버네이트는 경고 로그를 남기고 메모리에서 페이징(매우 위험)
    • WARN : firstResult/maxResults specified with collection fetch; applying in memory
  • 일대다면 그냥 다대일로 가져오는 게 제일 좋음
  • @BatchSize로 가져올 수도 있음
    • IN 쿼리로 가져옴
    • global setting도 가능, 실무에선 주로 이렇게 하는 듯
      • persistence.xml

      <property name="hibernate.default_batch_fetch_size" value="100"

      • 사이즈는 보통 1000 이하

• 연관된 엔티티들을 SQL 한번으로 조회해 성능 최적화
• 엔티티에 직접 적용하는 글로벌 로딩 전략보다 우선
  • @OneToMany(fetch = FetchType.LAZY) : 글로벌 로딩 전략
• 최적화가 필요한 곳은 패치 조인 적용

 

 

 

패치 조인 정리

• 모든 것을 패치 조인으로 해결할 순 없음
• 패치 조인은 객체 그래프를 유지할 때 사용하면 효과적
• 여러 테이블을 조인해서 엔티티가 가진 모양이 아닌 전혀 다른 결과를 내야 하면, 패치 조인보다는 일반 조인을 사용하고 필요한 데이터들만 조회해서 DTO로 반환하는 것이 효과적

 

 

 

다형성 쿼리

• JPQL
• SELECT i FROM Item i WHERE type(i) IN (Book, Moview)

 

 

TREAT

• 자바의 타입 캐스팅과 유사
• 상속 구조에서 부모 타입을 특정 자식 타입으로 다룰 때 사용
• FROM, WHERE, SELECT 사용

• JPQL (부모인 ITEM과 자식인 BOOK)

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

// 위의 두 쿼리 모두 동일한 SQL 실행됨
SELECT COUNT(m.id) as cnt FROM Member m

 

• 엔티티를 파라미터로 전달

String sql = "SELECT m FROM Member m WHERE m = :member";
List results = em.createQuery(sql)
					.setParameter("member", member)
					.getResultList();

 

• 식별자를 직접 전달

String sql = "SELECT m FROM Member m WHERE m.id = :memberId";
List results = em.createQuery(sql)
					.setParameter("memberId", memberId)
					.getResultList();

 

• 실행된 SQL

SELECT m.* FROM Member m WHERE m.id=?

 

 

 

외래 키 값

• 엔티티를 파라미터로 전달

Team team = em.find(Team.class, 1L);

String sql = "SELECT m FROM Member m WHERE m.team = :team";
List results = em.createQuery(sql)
					.setParameter("team", team)
					.getResultList();

 

• 식별자를 직접 전달

Team team = em.find(Team.class, 1L);

String sql = "SELECT m FROM Member m WHERE m.team.id = :teamId";
List results = em.createQuery(sql)
					.setParameter("teamId", teamId)
					.getResultList();

 

• 실행된 SQL

SELECT m.* FROM Member m WHERE m.team_id=?

 

 

 

Named 쿼리

정적 쿼리

• 미리 정의해서 이름을 부여해두고 사용하는 JPQL
• 정적 쿼리
• 어노테이션, XML에 정의
• 애플리케이션 로딩 시점에 초기화 후 재사용
• 애플리케이션 로딩 시점에 쿼리를 검증

 

 

어노테이션

• name은 보통 관례적으로 엔티티명.기능

@Entity
@NamedQuery(
	name = "Member.findByUsername",
	query = "select m from Member m where m.username = :username")
public class Member {
	...
}

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

 

• XML에 정의할 수도 있음
• <named-query> </named-query>
• xml이 우선권을 가짐

• Spring Data JPA의 @Query 어노테이션을 인터페이스 메소드 위에 바로 선언 가능
  • 이게 @NamedQuery임
  • 얘도 애플리케이션 로딩 시점에 쿼리를 검증 가능
• 실무에서는 Spring Data Jpa를 섞어 쓰게 됨

 

 

 

벌크 연산

• SQL의 update, delete 문
• ex) 재고가 10개 미만인 모든 상품의 가격을 10% 상승하려면?
  • JPQ 변경 감지 기능으로 실행하려면 너무 많은 SQL을 실행
  • 재고가 10개 미만인 상품 리스트를 다 조회해 for를 돌리며 증가시켜야 함
  • 100건이면 100번의 update sql이 실행됨

 

 

예제

• 쿼리 한번으로 여러 테이블 로우 변경
• executeUpdate()의 결과는 영향받은 엔티티 수 반환
• UPDATE, DELETE 지원
• INSERT 지원 (하이버네이트)
• executeUpdate() 하기 전 FLUSH 자동 호출됨

String sql = "update Product p " + 
			"set p.price = p.price * 1.1 " + 
			"where p.stockAmount < :stockAmount";

int resultCount = em.createQuery(sql)
					.setParameter("stockAmount", 10)
					.executeUpdate();

em.clear();
Member member = em.find(Member.class, member1.getId());

 

 

 

벌크 연산 주의

• 영속성 컨텍스트를 무시하고 DB에 직접 쿼리를 날림
  • 벌크 연산을 먼저 실행
    • 벌크 연산을 먼저 실행하면 영속성 컨텍스트에 아무것도 없는 상태니까
  • 벌크 연산 수행 후 영속성 컨텍스트 초기화
    • 영속성 컨텍스트에 데이터가 남아있으면 벌크 연산한 작업은 영속성 컨텍스트에 안남으니까