[JPA] #17 JPQL : 중급 문법

🗺 RoadMap/Jpa

[JPA] #17 JPQL : 중급 문법

an2z 2023. 7. 4. 01:21

본 포스팅은 인프런 - 자바 ORM 표준 JPA 프로그래밍 (기본편) 을 강의를 바탕으로 공부하고 정리한 글입니다.

경로 표현식

경로 표현식은 .(점)을 찍어 객체 그래프를 탐색하는 것이다.

상태 필드(static field) : 단순히 값을 저장하기 위한 필드
연관 필드(association field) : 연관관계를 위한 필드
- 단일 값 연관 필드 : @ManyToOne, @OneToOne, 대상이 엔티티
- 컬렉션 값 연관 필드 : @OneToMany, @ManyToMany, 대상이 컬렉션

특징

상태 필드 : 경로 탐색의 끝이며, 더이상 탐색이 불가능하다.

String query = "select m.username, m.age from Member m";

단일 값 연관 필드 : 묵시적 내부 조인이 발생하며, 탐색을 더 할 수 있다.

String query = "select m.team from Member m";

이 경우 m.team.name으로 탐색이 더 가능하다.

컬렉션 값 연관 필드 : 묵시적 내부 조인이 발생하며, 더이상 탐색이 불가능하다.

String query = "select t.members from Team t";

이 경우 t.members.username으로 탐색이 불가능하다.

하지만 FROM 절에서 명시적 조인을 통해 별칭을 얻으면 별칭을 통해서 탐색이 가능하다.

String query = "select m.username from Team t join t.members m";

실무에서는 묵시적 조인은 사용하지 않는 것을 권장한다.
명시적 조인을 사용해야 쿼리 튜닝하기 쉽고, 묵시적 조인을 사용할 경우 에러사항이 많이 발생할 수 있다.

명시적 조인, 묵시적 조인

명시적 조인 : join 키워드를 직접 사용
묵시적 조인 : 경로 표현식에 의해 묵시적으로 SQL 조인이 발생 (내부 조인만 가능)

/* 명시적 조인 */
select m from Member m join m.team t
/* 묵시적 조인 */
select m.team from Member m

경로 탐색을 사용한 묵시적 조인 시 주의사항

항상 내부 조인을 사용한다.
컬렉션은 경로 탐색의 끝으로, 컬렉션을 더 탐색하려면 명시적 조인을 통해 별칭을 얻어야 한다.
경로 탐색은 주로 SELECT, WHERE 절에서 사용하지만 묵시적 조인으로 인해 SQL의 FROM (JOIN) 절에 영향을 준다.
조인은 SQL 튜닝에 중요한 포인트인데, 묵시적 조인은 조인이 일어나는 상황을 한눈에 파악하기 어렵기 때문에 튜닝이 어렵다.
따라서 실무에서는 묵시적 조인은 사용하지 말고, 명시적 조인만 사용하는 것을 권장한다.

페치 조인(fetch join)

JPQL에서 성능 최적화를 위해 제공하는 기능이다.
SQL 조인 종류 X
연관된 엔티티나 컬렉션을 SQL 한번에 함께 조회할 수 있도록 한다. (한방 쿼리)
join fetch 명령어를 사용한다.

예제를 통해 알아보자.

String qeury = "select m from Member";
List<Member> result = em.createQuery(query, Member.class)
                        .getResultList();

for (Member member : result) {
    System.out.prinln("member = " + member.getUsername() + ", " + member.getTeam().getName());
}

Member의 Team 정보는 지연로딩으로 인해 프록시로 들어온다.
따라서 member.getTeam().getName()으로 호출하는 시점마다 데이터베이스에 쿼리를 날린다.

실행 쿼리를 보면 처음에 Member 조회 쿼리가 나가고, 반복문을 돌며 Team 조회 쿼리가 나가는 것을 확인할 수 있다.

회원1, 팀A (SQL)
회원2, 팀A (1차캐시)
회원3, 팀B (SQL)

예제에서는 쿼리가 3번 나갔지만, 만약 회원의 팀이 모두 다르고 팀이 100개라면 101개의 쿼리가 나갈 수 있는 것이다. (N+1문제)

이런 경우 페치 조인을 사용해 N+1 문제를 해결할 수 있다.

엔티티 페치 조인 (ManyToOne)

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

join fetch 명령어를 사용해 Member를 조회하는 시점에 Team도 함께 끌어오도록 JPQL을 변경했다.

쿼리 1번으로, from 절에서 inner join을 사용해 member.* team.* 정보를 모두 가져오는 것을 확인할 수 있다.

이때 Team은 프록시가 아니라 실제 객체로 영속성 컨텍스트에 올라가 있기 때문에 member.getTeam().getName() 시점에 1차캐시를 사용해 추가적인 쿼리가 발생하지 않는다.

컬렉션 페치 조인 (OneToMany)

String query = "select t from Team t join fetch t.members where t.name='팀A'";
List<Team> teams = em.createQuery(query, 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);
    }
}

일대다 조인은 데이터가 뻥튀기될 수 있기 때문에 주의해야 한다.

팀A는 1개지만, 조인 시 row가 2개가 되는 것을 알 수 있다.

페치 조인과 DISTINCT

SQL의 DISTINCT는 중복된 결과를 제거하고 싶을 때 사용한다.
JPQL의 DISTINC는 2가지 기능을 제공한다.
- SQL에 DISTINCT를 추가
- 애플리케이션에서 엔티티 중복을 제거 (식별자로 확인)

앞서 본 예제에서 distinct 명령어를 추가해보자.

String query = "select distinct t from Team t join fetch t.members where t.name='팀A'";

SQL에 DISTICNT를 추가하지만 데이터가 다르므로(ID, NAME) SQL 결과에서 중복제거가 이뤄지지 않는다.

이때 JPA가 DISTINCT 추가로 애플리케이션에서 중복 제거를 시도한다.

같은 식별자를 가진 Team 엔티티 제거

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

💡 일반 조인

연관된 엔티티를 함께 조회하지 않음
ex) select t from Team t join t.members m where t.name='팀A'
지연 로딩 발생으로 N+1 주의

💡 페치 조인

연관된 엔티티를 함께 조회해옴
ex) select t from Team t join fetch t.members m where t.name='팀A'
지연 로딩 발생 X

페치 조인의 특징과 한계

페치 조인 대상에는 별칭을 줄 수 없다.
- ex) select t from Team t join fetch t.members (as) m → 불가능
- 하이버네이트는 가능하지만, 가급적 사용하지 않는 것을 권장한다.
둘 이상의 컬렉션은 페치 조인할 수 없다.
컬렉션을 페치 조인하면 페이징 API를 사용할 수 없다.
- 일대일, 다대일 같은 단일 값 연관관계 필드드들은 페치 조인해도 페이징 가능 (데이터가 뻥튀기 되지 않으므로)
- 일대다 컬렉션 페치 조인은 데이터가 뻥튀기되기 때문에 페이징할 경우 이상한 결과가 나올 수 있기 때문에 사용 불가능
- 컬렉션 페치 조인 시 하이버네이트는 경고 로그를 남기고 메모리에서 페이징 (매우 위험)
연관된 엔티티들을 SQL 한번으로 조회할 수 있다. → 성능 최적화
엔티티에 직접 적용하는 글로벌 로딩 전략보다 페치 조인이 우선시 적용된다.
- @OneToMany(fetch=FetchType.LAZY) // 글로벌 로딩 전략

페치 조인 페이징 해결방법 (BatchSize)

<name="hibernate.default_batch_fetch_size" value="100"/>

정리

실무에서는 글로벌 로딩 전략은 모두 지연 로딩으로, 최적화가 필요한 곳에만 페치 조인을 적용하면 대부분의 성능 문제가 해결된다.
하지만, 모든 것을 페치 조인으로 해결 할 수는 없다.
- 페치 조인은 객체 그래프를 유지할 때 사용하면 효과적이다.
- 여러 테이블을 조인해서 엔티티가 가진 모양이 아닌 전혀 다른 결과를 내야 하면, 페치 조인보다는 일반 조인을 사용하고 필요한 데이터들만 조회해서 DTO로 반환하는 것이 효과적이다.

Named 쿼리

미리 정의해서 이름을 부여해두고 사용하는 JPQL이다.
정적 쿼리만 가능, 동적 쿼리 불가능
애플리케이션 로딩 시점에 초기화 후에 재사용한다.
애플리케이션 로딩 시점에 쿼리를 검증한다는 장점이 있다.
- JPA가 로딩되면서 어노테이션으로 등록되어 있는 Named 쿼리를 SQL로 파싱해서 들고 있으려고 하기 때문에, 쿼리 문법이 안맞거나 문제가 있을 때 컴파일 에러를 발생시킨다.

사용 방법

Named 쿼리를 정의하는 방법에는 2가지가 있다.

어노테이션에 정의
XML 정의 (XML이 항상 우선권을 가짐)

💡 어노테이션에 정의

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

List<Member> result = em.createNamedQuery("Member.findByUsername", Member.class)
                        .setParameter("username", "이름1")
                        .getResultList();

💡 XML에 정의

📁 META-INF/persistence.xml

<persistence-unit name="jpabook" >
	<mapping-file>META-INF/ormMember.xml</mapping-file>

📁 META-INF/ormMember.xml

<?xml version="1.0" encoding="UTF-8"?>
<entity-mappings xmlns="http://xmlns.jcp.org/xml/ns/persistence/orm" version="2.1>
    <named-query name="Member.findByUsername>
        <query><![CDTA[
            select m
            form Member m
            where m.username = :username
        ]]></query>
    </named-query>

    <named-query name=Member.count>
        <query>select count(m) from Member m</query>
    </named-query>
</entity-mappins>

저작자표시 (새창열림)