@Query(value = "select m from Member m left join m.team t",
countQuery = "select count(m) from Member m")
Page<Member> findByAge(int age, Pageable pagealbe);
이전에 만들었던 interface Repository에 username으로 조회하는 기능을 추가하고 싶을 때는 어떻게해야 될까??
interface이기 때문에 새로운 기능을 추가 하기 어렵다. 그렇다고 하나의 기능을 추가하기 위해 새로운 클래스를 만들고 interface를 상속받으면 아래와 같이 모든 메소드를 Override 해야하고 기능을 구현해야 한다. (이렇게 되는 경우 Spring Data JPA를 사용하는 의미가 없어진다.)
위와같은 문제를 해결 하기 위한 것이 쿼리 메소드 기능이다.
쿼리 메소드 기능
메소드 이름으로 쿼리 생성
public List<Member> findByUsernameAndAgeGreaterThan(String username, int age){
return em.createQuery("select m from Member m where m.username = :username " +
"and m.age > :age")
.setParameter("username", username)
.setParameter("age", age)
.getResultList();
}
위와 같이 파라미터로 넘어온 username이 같고, age보다 높은 컬럼들을 반환하는 기능을 JPA로 구현한 코드입니다.
이를 Spring Data JPA에 추가하려면 아래와 같이 하면됩니다.
List<Member> findByUsernameAndAgeGreaterThan(String username, int age);
메소드 이름으로 쿼리를 작성해주는 Spring Data JPA의 강력한 기능 때문에 위의 코드 한줄로 같은 기능을 제공해줍니다.
username뒤에는 아무런 기능이 없기 때문에 equal(=). And 후 age뒤에는 GreaterThan이 있습니다. 즉, 파라미터인 age보다 크면 (>) 반환해주는 쿼리문을 Spring Data JPA에서 작성해줍니다. 주의 메소드로 쿼리문을 작성하기 때문에 오타가 나면 안됩니다!!
엔티티의 필드명이 변경되는 경우 메서드 이름도 함께 변경해야한다. 즉, 유지보수성이 뛰어나지는 않다.
@Query, 리포지토리 메소드에 쿼리 정의하기
메소드 위에 @Query("쿼리문")을 통해 사용할 수 있다.
@Query("select m from Member m where m.username = :username and m.age > :age")
List<Member> findUser(@Param("username") String username, @Param("age") int age);
이전에 사용했던
List<Member> findByUsernameAndAgeGreaterThan(String username, int age);
메소드 이름으로 작성했던 쿼리문이랑 같은 기능을 한다.
@Query 정리
장점
애플리케이션 로딩 시점에 정적 쿼리이기때문에 SQL로 파싱을 해놓는다고 합니다. 그렇기때문에 애플리케이션 로딩시점에 문법 오류를 알 수 있습니다.
DTO로 반환을 할 수 있다.
단점
간단한 쿼리문인 경우 메소드 이름으로 작성하는 것보다 많은 코드를 써야 한다. (간단한 쿼리는 메소드 이름 사용하면 편리할듯? 합니다.)
동적 쿼리를 작성할 수 없다. 동적 쿼리는 QueryDSL가 좋다고 한다.
@Query, 값, DTO 조회하기
기존 JPQL에서 dto로 반환했을 때처럼 사용하면됩니다.
MemberRepository 코드 추가
@Query("select new study.datajpa.dto.MemberDto(m.id, m.username, t.name) from Member m join m.team t")
List<MemberDto> findMemberDto();
위와 같이 코드를 작성하면 @Query를 통해 Dto로 반환할 수 있습니다.
파라미터 바인딩
위치 기반, 이름 기반 파라미터 바인딩은 지금까지 해왔던 바인딩이다. 파라미터 바인딩에는컬렉션 파라미터 바인딩이라는 것도 있다.
컬렉션 파라미터 바인딩
Collection 타입으로 in절 지원
@Query("select m from Member m where m.username in :names")
List<Member> findByNames(@Param("names") Collection<String> names);
위처럼 in 절을 사용해서 컬렉션 파라미터 바인딩을 지원해줍니다.
반환 타입
단일 건의 조회일 때, null 값이 넘어올 가능성이 있다면 Optional을 사용하자! (NullPointException 방지!)
Total count 쿼리문이 나가기때문에 성능상 좋지 않다. (컬럼 수가 많을 때 특히 비효율적)
Page<T>로 반환 할 때, join을 하는경우 count 쿼리문도 조인을 하기 때문에 countQuery문을 따로 작성하는 것이 성능에 좋다. (최선)
CountQuery X
@Query(value = "select m from Member m left join m.team t")
Page<Member> findByAge(int age, Pageable pagealbe);
발생한 쿼리문
CountQuery O
@Query(value = "select m from Member m left join m.team t",
countQuery = "select count(m) from Member m")
Page<Member> findByAge(int age, Pageable pagealbe);
발생한 쿼리문
조인을하며 쿼리가 복잡해지는 경우 성능을 높이기 위해 CountQuery문을 따로 작성하는 방법도 좋을 것 같다.
벌크성 수정 쿼리를 사용할 때는 한 번에 많은 컬럼을 수정해야 하는 경우 사용한다. (예를들면, 물가 상승에 따른 모든 물건 값이 10%씩 올랐을 때 한번에 모든 물건의 가격을 10%올리는 쿼리문을 보내야할 때)
순수 JPA
public int bulkAgePlus(int age){
return em.createQuery("update Member m set m.age = m.age+1 where m.age >= : age")
.setParameter("age", age)
.executeUpdate();
}
파라미터 보다 이상이면 age를 +1하는 쿼리문을 순수한 JPA로 작성했다. 이를 Spring Data JPA로 변형해보자.
Spring Data JPA
@Modifying //executeUpdate() 와 같다고 보면 됌
@Query("update Member m set m.age = m.age + 1 where m.age >= :age")
int bulkAgePlus(@Param("age") int age);
하지만, 벌크 연산에는 문제점이 있다. 벌크 연산하는 경우 영속성 컨텍스트를 거쳐서 update를 하는 것이 아닌 바로 DB에 쿼리문을 날린다고 한다.
여기서 발생하는 문제점은 하나의 트랜잭션에서 insert한 엔티티를 벌크연산을 해버린 뒤, insert한 엔티티를 select하여 조회하면 벌크연산이 되지 않는다는 것이다.
설명을 하자면, Insert하면 영속성 컨텍스트와 DB에 저장이 된다. 벌크 연산하면 DB에만 저장이 된다. select하면 DB를 조회하기 전에 영속성 컨텍스트에 찾고자하는 엔티티가 있는지 확인한다. 이때, 있으면 영속성 컨텍스트에서 가져오고 없다면 DB를 조회해서 갖고온다. 하지만 현재 영속성 컨텍스트에 있기때문에 DB를 거치지 않고 반환을 하게 된다. 이렇게 되는 경우 벌크연산이 되지 않은 엔티티가 반환이 되버리고 만다. 이것이 문제가 되는 것이다. (이해가 되지 않는다면, 영속성 컨텍스트에 대한 내용을 공부하는 것을 권장)
해결 방법은 벌크 연산 후, em.clear()를 하면 된다. 영속성 컨텍스트가 비어지기때문에 DB에 접근해서 데이터를 갖고오기때문에 위와 같은 문제가 일어나지 않게 된다. 혹은, @Modifying(clearAutomatically = true) 옵션을 추가하면 된다. 쿼리가 나고 바로 영속성 컨텍스트를 clear 시켜주는 옵션이다.
@EntityGraph
Spring Data JPA에서 fetch join을 사용하는 방법
//공통 메서드 오버라이드
@Override
@EntityGraph(attributePaths = {"team"})
List<Member> findAll();
//JPQL + 엔티티 그래프
@EntityGraph(attributePaths = {"team"})
@Query("select m from Member m")
List<Member> findMemberEntityGraph();
//메서드 이름으로 쿼리에서 특히 편리하다.
@EntityGraph(attributePaths = {"team"})
List<Member> findByUsername(String username)
@EntityGraph를 통해 fetch join을 사용할 수 있다.
EntityGraph 정리
fetch join의 간편 버전이다.
left outer join 사용
보통은 JPQL로 사용한다. 간단간단한 경우 EntityGraph를 사용
JPA Hint & Lock
JPA Hint
JPA 쿼리 힌트 (SQL 힌트가 아니라 JPA 구현체에게 제공하는 힌트이다.)
쿼리 힌트 사용
@QueryHints(value = @QueryHint(name = "org.hibernate.readOnly", value = "true"))
Member findReadOnlyByUsername(String username);
일반 select를 하게되면, 더티 체킹을 하기위해 1차캐시에 엔티티의 정보를 저장해놓는다. 이것이 성능상 크지는 않지만 작게나마 영향을 줄 수 있다. 그때 QueryHint를 통해 readOnly를 사용하면 1차캐시에 저장하지 않기 때문에 조회만 할때 성능이 좋아질 수 있다. (단, 정말 조회만 할 때 사용해야 한다. 더티체킹을 통한 update 쿼리문이 날라가지 않기 때문이다.)
위의 설계대로 구현을 스프링 데이터 JPA를 사용하며 스프링 데이터 JPA에 대해 배워봅시다.
Member
package study.datajpa.entity;
import lombok.*;
import javax.persistence.*;
@Entity
@Getter
@Setter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@ToString(of = {"id", "username", "age"})
public class Member {
@Id
@GeneratedValue
private Long id;
private String username;
private int age;
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "team_id")
private Team team;
public void changeTeam(Team team){
this.team = team;
team.getMembers().add(this);
}
public Member(String username, int age, Team team) {
this.username = username;
this.age = age;
changeTeam(team);
}
}
Team
package study.datajpa.entity;
import lombok.*;
import javax.persistence.*;
import java.util.*;
@Entity
@Getter
@Setter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@ToString(of = {"id", "name"})
public class Team {
@Id @GeneratedValue
@Column(name = "team_id")
private Long id;
private String name;
@OneToMany(mappedBy = "team")
private List<Member> members = new ArrayList<>();
public Team(String name){
this.name = name;
}
}
위의 Entity에 해당하는 Repository의 CRUD 기능을 JPA를 통해 만들어 보도록 하겠습니다.
MemberJpaRepository
package study.datajpa.repository;
import org.springframework.stereotype.Repository;
import study.datajpa.entity.Member;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
import java.util.*;
@Repository
public class MemberJpaRepository {
@PersistenceContext //스프링 컨테이너가 엔티티 매니저를 가져다 줌
private EntityManager em;
public Member save(Member member){
em.persist(member);
return member;
}
public void delete(Member member){
em.remove(member);
}
public List<Member> findAll() {
//JPQL
return em.createQuery("select m from Member m", Member.class)
.getResultList();
}
public Optional<Member> findById(Long id){
Member member = em.find(Member.class, id);
return Optional.ofNullable(member);
}
public long count() {
return em.createQuery("select count(m) from Member m", Long.class)
.getSingleResult();
}
public Member find(Long id){
return em.find(Member.class ,id);
}
}
TeamJpaRepository
package study.datajpa.repository;
import org.springframework.stereotype.Repository;
import study.datajpa.entity.Member;
import study.datajpa.entity.Team;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
import java.util.*;
@Repository
public class TeamJpaRepository {
@PersistenceContext
private EntityManager em;
public Team save(Team team){
em.persist(team);
return team;
}
public void delete(Team team){
em.remove(team);
}
public List<Team> findAll() {
return em.createQuery("select t from Team t", Team.class)
.getResultList();
}
public Optional<Team> findById(Long id){
Team team = em.find(Team.class, id);
return Optional.ofNullable(team);
}
public long count() {
return em.createQuery("select count(t) from Team t", Long.class)
.getSingleResult();
}
public Team find(Long id){
return em.find(Team.class ,id);
}
}
Team과 Member에 대한 CRUD 기능을 갖춘 Repository를 만들었습니다. 위의 코드를 직접 쳐보시면 기본적인 CRUD 같은경우 클래스명과 관련된 것을 제외하고는 같은 코드인 것을 볼 수 있습니다. 즉, 반복적인 코드가 엔티티마다 발생하게 됩니다. 미리 결론부터 말하자면 이런 반복적인 코드를 줄여주는 기능을 하는 것이 바로 Spring Data JPA입니다.
공통 인터페이스 설정
Srping Data JPA가 제공하는 공통 인터페이스 기능을 쓰기 위한 준비 단계로 공통 인터페이스를 어떻게 설정하는 지 알아보자.
이전 JpaRepository를 상속받는 Spring Data JPA를 사용해 본 적이 있다. 해당 클래스는 interface이고 구현체가 없지만 기능이 정상적으로 작동한다. 이유는 무엇일까?
실제 @Autowired한 Spring Data JPA를 사용한 interface를 출력해보면 아래와 같이 뜬다. interface에 Spring Data JPA가 구현클래스를 만들어서 대입했다고 보면 좋을 것 같다.
그렇기 때문에 구현체를 Spring Data JPA가 만들어서 injection을 해준 것이다.
그림으로 봐보자
Spring Data JPA가 애플리케이션 로딩 시점에 Spring Data JPA와 관련된 interface를 가지고 있으면 구현 클래스를 내부에서 만들어 냅니다. 즉, 애플리케이션 로딩 시점에 Spring Data JPA와 관련된 구현 클래스를 만들고 필요할 때 내부에서 injection을 해주는 것 입니다.
참고로 Spring Data JPA를 상속받은 interface는 @Repository를 하지 않아도 됩니다.
공통 인터페이스 분석
공통 인터페이스 구성
getOne(ID)
엔티티를 프록시로 조회하는 기능. 레퍼런스를 가져올 때 쿼리문이 나가지 않고, 실제 엔티티에 접근할 때 쿼리문이 나간다.
Lazy.Loading을 생각하면 될 것 같다.
findAll(...)
모든 엔티티를 조회한다. 정렬('Sort') 이나 페이징('Pageable') 조건을 파라미터로 제공할 수 있다.
읽어보면 open-in-view와 관련된 경고문인 것을 확인할 수 있습니다. 기본값을 뿌리면서 애플리케이션 시작 시점에 waning로그를 남기는 것은 이유가 있습니다. OSIV 전략은 트랜잭션 시작처럼 최소 데이터베이스 커넥션 시작 시점부터 API 응답이 끝날 때(Html 랜더링이 전부 다 안료하고, 더이상 DB가 필요없을 때) 까지 영속성 컨텍스트와 데이터베이스 커넥션을 유지합니다. 그래서 지금까지 View Template나 API 컨트롤러에서 지연 로딩이 가능했던 것입니다.
지연 로딩은 영속성 컨텍스트가 살아있어야 가능하고, 영속성 컨텍스트는 기본적으로 데이터베이스 커넥션을 유지한다. 이것 자체가 큰 장점이다!!
그런데 이 전략은 너무 오랜시간동안 데이터베이스 커넥션 리소스를 사용하기 때문에, 실시간 트래픽이 중요한 애플리케이션에서는 커넥션이 모자를 수 있다. 이것은 결국 장애로 이어진다. (치명적)
예를들어, 컨트롤러에서 외부 API를 호출하면 외부 API 대기 시간만큼 커넥션 리소스를 반환하지 못하고, 유지해야 한다. (외부 API DB가 blocking된 경우 매우 치명적일 수 있다.)
OSIV OFF
spring.jpa.open-in-view : false (OSIV 종료)
OSIV를 끄면 트랜잭션을 종료할 때 영속성 컨텍스트를 닫고, 데이터베이스 커넥션도 반환한다. 따라서 커넥션 리소스를 낭비하지 않는다.
OSIV를 끄면 모든 지연로딩을 트랜잭션 안에서 처리해야 한다. 따라서 지금까지 작성한 많은 지연 로딩 코드를 트랜잭션 안으로 넣어야 하는 단점이 있다. 그리고 view template에서 지연 로딩이 동작하지 않는다. 결론적으로 트랜잭션이 끝나기 전에 지연 로딩을 강제로 호출해 두어야 한다.
우리가 지금까지 작성했던 코드들은 Controller에서 지연로딩 하는 코드들도 많이 있습니다. 만약 OSIV를 종료한다면, 에러가 발생할 것입니다. 이유는 Controller에서 영속성 컨텍스트가 생존하고 있지않기 때문입니다. 그렇기때문에 OSIV를 false로 두는 경우는 지연 로딩 코드들을 모두 Transaction안에서 처리하기 위해 Service나 Respository 계층에서 사용해야 합니다. 예) fetch join
커맨드와 쿼리 분리
실무에서 OSIV를 끈 상태로 복잡성을 관리하는 좋은 방법이 있다. 바로 Command와 Query를 분리하는 것이다.
OrderService 추가 코드는 Repository 메소드만 return하기때문에 추가하지 않았습니다.
테스트
조인을 잘 아시는분들은 2개의 order와 4개의 아이템을 join하면 4개의 컬럼이 나온다는 것을 알 수 있을 겁니다. 여기서 문제는 데이터가 뻥튀기가 된다는 것 입니다. (뻥튀기란 중복된 데이터인 필요하지 않은 데이터가 여러개가 생긴다는 것 입니다.) 지금은 1개씩 뻥튀기 됐지만, 이런 엔티티가 많이 연관되어 있을 경우 몇개가 뻥튀기가 될지 알 수 없을 것 입니다.
Order의 참조값을 확인해보면 같은 참조값이 2번씩 나오는 걸 확인할 수 있습니다. 해당 문제는 distinct를 썼던 걸 기억했다면 해결할 수 있습니다. 실제로 dinstinct를 써보면 중복된 데이터가 사라지는 걸 확인할 수 있습니다. 여기서 데이터가 사라지는 이유는 JPA에서 distinct가 있고, 갖고온 데이터가 같은 id 값이면 제거해주는 기능을 했기때문에 postman에서는 중복된 데이터가 사라지는 것 입니다.
DB는 확인해보면 여전히 컬럼이 4개 있습니다. (참고로, DB에서 distinct는 모든 데이터가 같아야 합니다.)
해당 방법은 어마어마한 단점이 있습니다. 바로, 페이징이 불가능하다는 점 입니다. (DB는 중복된 데이터가 그대로있지만, 애플리케이션에서 중복을 제거해주었기때문에 제대로된 페이징을 할 수 없기 때문입니다.) (이전 distinct 설명에서도 말했듯 중요하기때문에 이해합시다!)
참고 컬렉션 페치 조인을 사용하면 페이징이 불가능하다. 하이버네이트는 경고 로그를 남기면서 모든 데이터를 DB에서 읽어오고, 메모리에서 페이징 해버린다. (매우 위험하다) 자세한 내용은 자바 ORM 표준 JPA 프로그래밍의 페치 조인 부분을 참고.
참고 컬렉션 페치 조인은 1개만 사용할 수 있다. 컬렉션 둘 이상에 페치 조인을 사용하면 안된다. 데이터가 부정합하게 조회될 수 있다. 자세한 내용은 자바 ORM 표준 JPA 프로그래밍 참고.
주문 조회 V3.1 : 엔티티를 DTO로 변환 - 페이징과 한계 돌파
페이징과 한계 돌파
컬렉션을 페치 조인하면 페이징이 불가능하다.
컬렉션을 페치 조인하면 일대다 조인이 발생하므로 데이터가 예측할 수 없이 증가한다.
일대다에서 일(1)을 기준으로 페이징을 하는 것이 목적이다. 하지만, 데이터는 다(N)를 기준으로 row가 생성된다.
Order를 기준으로 페이징하고 싶은데, 다(N)인 OrderItem을 조인하면 OrderItem이 기준이 되어버린다.
이 경우 하이버네이트는 경고 로그를 남기고 모든 DB 데이터를 읽어서 메모리에서 페이징을 시도한다. 최악의 경우 장애로 이어질 수 있다.
한계 돌파
그렇다면 페이징 + 컬렉션 엔티티를 함께 조회하려면 어떻게 해야 될까? 지금부터 코드도 단순하고, 성능 최적화도 보장하는 매우 강력한 방법을 소개하겠다. 대부분의 페이징 + 컬렉션 엔티티 조회 문제는 해당 방법으로 해결할 수 있다.
먼저 ToOne(OneToOne, ManyToOne) 관계를 모두 페치 조인 한다. ToOne 관계는 row수를 증가시키지 않으므로 페이징 쿼리에 영향을 주지 않는다.
컬렉션은 지연 로딩으로 조회한다.
지연 로딩 성능 최적화를 위해 hibernate.default_batch_fetch_size, @Batch를 사용한.
hibernate.default_batch_fetch_size : 글로벌 설정
@BatchSize : 개별 최적화
이 옵션을 사용하면 컬렉션이나, 프록시 객체를 한꺼번에 설정한 size만큼 IN 쿼리로 조회한다.
application.yml에 hibernate 하위에 아래 설정을 추가해줍니다.
default_batch_fetch_size: 100
후 findAllWithMemberDelivery를 조회한 후 orderItem을 지연로딩으로 해주면 100개의 데이터를 한번에 갖고 옵니다.
장점
쿼리 호출 수가 1+N -> 1+1로 최적화 됩니다. (데이터가 많은 경우에는 더 많이 나가긴합니다.)
조인보다 DB 데이터 전송량이 최적화된다. (Order와 OrderItem을 조인하면 Order가 OrderItem 만큼 중복해서 조회된다. 해당 방법은 각각 조회하므로 전송해야할 중복 데이터가 없다.)
페치 조인 방식과 비교해서 쿼리 호출 수가 약간 증가하지만, DB 데이터 전송량이 감소한다.
컬렉션 페치 조인은 페이징이 불가능 하지만 해당 방법은 페이징이 가능하다.
결론
ToOne 관계는 페치 조인해도 페이징에 영향을 주지 않는다. 따라서, ToOne관계는 페치조인으로 쿼리 수를 줄이고 해결하고, 나머지는 batch_fetch_size로 최적화하자.
참고 default_batch_fetch_size의 크기는 적당한 사이즈를 골라야 하는데, 100~1000 사이를 선택하는 것을 권장한다. 이 전략을 SQL IN 절을 사용하는데, 데이터 베이스에 따라 IN 절 파라미터를 1000으로 제한하기도 한다. 1000으로 잡으면 한번에 1000개를 DB에서 애플리케이션에 불러오므로 DB에 순간 부하가 증가할 수 있다. 하지만 애플리케이션은 100이든 1000이든 결국 전체 데이터를 로딩해야하므로 메모리 사용량이 같다. 1000으로 설정하는 것이 성능상 가장 좋지만, 결국 DB든 애플리케이션이든 순간 부하를 어디까지 견딜 수 있는지로 결정하면 된다.
해당 result를 받는 Service와 Controller에 코드 추가만 해주면 작동합니다. 실제로 1번의 쿼리문으로 모든 데이터를 갖고오는 것을 볼 수 있습니다. 페이징도 가능합니다. 하지만, OrderId를 기준으로 페이징을 하고싶은 경우에는 페이징이 불가능합니다.
orderid 기준으로 페이징이 불가능한 이유는 아래 get 요청에 나온 응답을 보시면 쉽게 알 수 있습니다. orderId 기준으로 index가 증가하는 것이아닌 orderItem 기준으로 Index가 증가하기 때문입니다.
위를 보시면 orderId, member name, address 등 중복된 결과가 많습니다. 이렇게 중복된 결과를 지워낼 수 있는 코드는 아래와 같습니다.
쿼리는 1번이지만 조인으로 인해 DB에서 애플리케이션에 전달하는 데이터에 중복 데이터가 추가되므로 상황에 따라 V5 보다 더 느릴 수 있다.
애플리케이션에 추가 작업이 크다.
페이징 불가능 (orderItem 기준으로는 페이징 가능)
컬렉션 조회 최적화 정리
엔티티 조회
엔티티를 조회해서 그대로 반환 : V1
엔티티 조회 후 DTO로 반환 : V2
페치 조인으로 쿼리 수 최적화 : V3
컬렉션 페이징과 한계 돌파 : V3.1
컬렉션은 페치 조인 시 페이징이 불가능
ToOne 관계는 페치 조인으로 쿼리 수 최적화
컬렉션은 페치 조인 대신에 지연 로딩을 유지하고, hibernate.deault_batch_fetch_size, @BatchSize로 최적화
DTO 직접 조회
JPA에서 DTO를 직접 조회 : V4
컬렉션 조회 최적화 - 일대다 관계인 컬렉션은 IN 절을 활용해서 메모리에 미리 조회해서 최적화 : V5
플랫 데이터 최적화 - JOIN 결과를 그대로 조회 후 애플리케이션에서 원하는 모양으로 직접 변환 : V6
권장 순서
엔티티 조회 방식으로 우선 접근
페치 조인으로 쿼리 수를 최적화
컬렉션 최적화
페이징 필요 - hibernate.deault_batch_fetch_size, @BatchSize로 최적화
페이징 필요 X -> 페치 조인 사용
엔티티 조회 방식으로 해결이 안되면 DTO 조회 방식 사용
DTO 조회 방식으로 해결이 안되면 NativeSQL or 스프링 JdbcTemplate
참고 엔티티 조회 방식은 페치 조인이나, hibernate.default_batch_fetch_size, @BatchSize 같이 코드를 거의 수정하지 않고, 옵션만 약간 병경해서, 다양한 성능 최적화를 시도할 수 있다. 반면에 DTO를 직접 조회하는 방식은 성능을 최적화 하거나 성능 최적화 방식을 변경할 때 많은 코드를 변경해야 한다.
캐시를 사용하는 경우 Entity를 캐시하지않고 Entity -> Dto로 바꾸고 Dto를 캐시해야 한다.
참고 개발자는 성능 최적화와 코드 복잡도 사이에서 줄타기를 해야한다. 하상 그런 것은 아니지만, 보통 성능 최적화는 단순한 코드를 복잡한 코드로 몰고간다. 엔티티 조회 방식은 JPA가 많은 부분을 최적화 해주기 때문에, 단순한 코드를 유지하면서, 성능을 최적화 할 수 있다. 반면 DTO 조회 방식은 SQL을 직접 다루는 것과 유사하기 때문에, 둘 사이에 줄타기를 해야 한다.
DTO 조회 방식의 선택지
DTO로 조회하는 방법도 각각 장단이 있다. V4, V5, V6에서 단순하게 쿼리가 1번 실행된다고 V6가 항상 좋은 방법인 것은 아니다.
V4는 코드가 단순하다. 특정 주문 한건만 조회하면 이 방식을 사용해도 성능이 잘 나온다. 예를 들어서 조회한 Order 데이터가 1건이면 OrderItem을 찾기 위한 쿼리도 1번만 실행하면 된다.
V5는 코드가 복잡하다. 여러 주문을 한꺼번에 조회하는 경우에는 V4 대신에 이것을 최적화한 V5 방식을 사용해야 한다. 예를 들어서 조회한 Order 데이터가 1000건인데, V4 방식을 그대로 사용하면, 쿼리가 총 1+1000번 실행된다. 여기서 1은 Order를 조회한 쿼리고, 1000은 조회된 Order의 row 수다. 하지만, V5 방식으로 최적화 하면 쿼리가 총 1+1 번만 실행된다. 상황에 따라 다르겟지만 운영 환경에서 100배 이상의 성능 차이가 날 수 있다.
V6는 완전히 다른 접근 방식이다. 쿼리 한번으로 최적화 되어서 상당히 좋아보이지만, Order를 기준으로 페이징이 불가능하다. 실무에서는 이정도 데이터면 수백이나 ,수천건의 단위로 페이징 처리가 꼭 필요하므로, 이 경우 선택하기 어려운 방법이다. 그리고 데이터가 많으면 중복 전송이 증가해서 V5와 비교해서 성능 차이도 미비하다.
실무에서 JPA를 사용하려면 100% 이해해야 할 정도로 중요한 내용입니다. 시간을 날리고 싶지않다면 제대로 이해하라고 하십니다. (정신차리자)
간단한 주문 조회 V1 : 엔티티를 직접 노출
api.OrderSimpleApiController 생성
package jpabook.jpashop.api;
import jpabook.jpashop.domain.Order;
import jpabook.jpashop.repository.OrderSearch;
import jpabook.jpashop.service.MemberService;
import jpabook.jpashop.service.OrderService;
import lombok.RequiredArgsConstructor;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import java.util.*;
/**
* XToOne (ManyToOne, OneToOne) 에서의 성능 최적화
* Order
* Order -> Member
* Order -> Delivery
*/
@RestController
@RequiredArgsConstructor
public class OrderSimpleApiController {
private final OrderService orderService;
private final MemberService memberService;
@GetMapping("/api/v1/simple-orders")
public List<Order> ordersV1() {
List<Order> orders = orderService.findOrders(new OrderSearch());
return orders;
}
}
현재 주문 내역을 조회하는 api를 생성했습니다. 돌려보면 결과가 어떨까요?? 감이 온다면 좋겠지만 전 감이 오지 않았습니다... 결론은 무한루프에 빠지게 됩니다. Member -> Order (ManyToOne)이고 Order -> Member (OneToMany)로 계속 무한루프에 빠지게 되는 것 입니다.
테스트
Entity를 직접 노출시키는 프로젝트라면, 해결책은 JsonIgnore를 해줘야 합니다.
Order와 연관된 엔티티에서 다시 Order로 오는 필드를 JsonIgnore한 뒤 돌려보면
500 에러와 함께 org.hibernate.proxy.pojo.bytebuddy.ByteBuddyInterceptor란 에러가 뜹니다. ByteBuddyInterceptor 클래스는 LAZY.Loading으로 했기때문에 진짜 객체가아닌 프록시 객체를 주는데, 실제로 프록시 객체가 ByteBuddy로 되어있다고 합니다. (프록시는 김영한님 강의 중 기본편에 있는 내용인데, 아래 링크에 정리했으니 잘 모르면 보도록합시다.)
쿼리 문자열을 보면 new jpabook.....하며 객체 루트를 다 적어주었습니다. 이유는 엔티티, 임베디드가 아니면 어떤 객체인지 spring에서 알지 못하기 때문입니다. OrderSimpleQueryDto의 경우 @Data로 만들었기 때문에 루트를 다 적어야합니다.
이렇게 DTO로 조회하면 아래 테스트와 같이 컬럼명이 딱 필요한 만큼 가져올 수 있습니다. 하지만, 재사용성이 zero에 가깝기때문에 상황에 맞게 V3와 V4를 잘 조율해가며 사용해야 합니다.
테스트
이전 V3에서 생성된 쿼리문보다 훨씬 줄어든 컬럼양을 확인할 수 있습니다!
그렇다면 V3와 V4의 성능 차이가 많이 날까요??
그렇지 않다고 합니다. 성능을 좌우하는 것은 from절 다음부터입니다. 즉, select 절에 컬럼이 몇개 추가된다고 성능에는 영향이 없다고 봐도 좋습니다. 물론, 데이터 사이즈가 정말 큰 경우에는 문제가 되지만 그렇지 않은경우 V3를 사용하는 것도 좋다고 합니다.
또한, 현재 OrderRepository에는 V4를 제외하면 Order 엔티티와 관련된 DB 조회만 있습니다. (엔티티명)+repository의 경우 해당 엔티티와 관련된 조회만 있어야합니다. 즉, 현재 V4를 실행하기 위해 OrderSimpleQueryDto를 조회하며 계층이 무너졌습니다. 리팩토링해줍시다.
repository 팩토리 안에 order.simplequery 파일을 만들어 쿼리 최적화를 위한 코드들은 해당 팩토리안에서 관리해줍시다! 이를통해 얻을 수 있는 장점은 유지보수가 편해집니다. 또한, 용도를 보다 명확하게 할 수 있습니다!
