QueryDSL Dive

Java-Ecosystem · 2025-01-13

Spring Data JPA Dive

Java-Ecosystem · 2025-01-09

JPA 활용 팁 2

요청과 응답 관련 유의 사항 요청 및 응답은 API 스펙에 맞추어 별도의 DTO로 전달하자 (엔터티 노출 X) 엔터티를 요청과 응답에 사용하면 프레젠테이션 계층과 엔터티가 결합되어 오염됨 (@NotEmpty 등…) e.g. @RequestBody CreateMemberRequest request 롬복은 DTO에 적극적으로 사용하자 (Entity에는 getter 정도 이외에는 사용 X) CQS 개발 스타일 적용하면 유지보수성이 크게 향상됨! Update 메서드는 반환없이 끝내거나 ID 값 정도만 반환 Update가 엔터티 객체를 반환하면, 업데이트하면서 조회하는 꼴 Update 후 조회가 필요하다면, PK로 하나 조회하자 특별히 트래픽 많은 API가 아니면 큰 이슈 X e.g. memberService.update(id, request.getName()); Member findMember = memberService.findOne(id); API 응답은 처음부터 Object로 반환하자 (Array X) 추후 Count를 넣어달라는 요청 등으로 언제든 요구사항이 변할 수 있음 (확장성을 위해) 지연로딩과 조회 성능 최적화 항상 지연로딩을 기본으로 하고, 성능 최적화가 필요한 경우 페치 조인 사용하자! 즉시 로딩은 연관관계가 필요 없는 경우에도 데이터를 항상 조회해 성능 문제 유발 JPQL 실행 후 응답을 받을 때 연관 관계에 즉시 로딩이 있으면, 영속성 컨텍스트에서 지연 로딩처럼 하나하나 단건 쿼리 날려 다 조회해 가져옴 (N + 1) 참고: 지연로딩은 N + 1을 만들지만, 영속성 컨텍스트에서 조회하므로 운좋게 이미 조회된 객체는 쿼리 생략 DTO 직접 조회 방식은 후순위 선택지 DTO 직접 조회는 페치 조인 없이도 한 번에 쿼리가 나감 장점 SELECT 절에 원하는 데이터 직접 선택 -> 애플리케이션 네트워크 용량 최적화 (생각보다 미비) 최근 네트워크 대역폭이 매우 좋음 대부분 성능 문제는 join에서 걸리거나 where 문이 인덱스를 잘 안탈 때 생김 SELECT 절이 문제가 될 때는 하필 필드 데이터 사이즈가 정말로 컸을 때 e.g. 필드가 10~30개 정도 되면 트래픽이 정말 많은 API는 영향 받을 수도 있음 단점 리포지토리가 API(화면)을 의존 -> API 스펙이 바뀌면 수정 -> 물리적 계층은 나뉘었지만 논리적 계층은 깨져있음 리포지토리 재사용성 감소 컬렉션 조회 최적화 컬렉션 조회시 페치 조인의 한계 컬렉션 페치 조인은 페이징 불가능 결과값은 올바르게 페이징해줄 수도 있으나, 메모리에서 진행되므로 메모리 터질 가능성 매우 큼 1 : N : M 같은 둘 이상의 연쇄적 컬렉션 패치 조인은 사용해서는 안됨 JPA 입장에서 어떤 엔터티를 기준으로 정리할지 모르게 될 수 있음 페이징 + 컬렉션 조회 전략 (default_batch_fetch_size) 전략 ToOne(OneToOne, ManyToOne) 관계를 모두 페치 조인하기 (=쿼리수 최대한 줄이기) 컬렉션은 아래 최적화 적용하고 지연 로딩으로 조회 (=N + 1 문제 완화) hibernate.default_batch_fetch_size: 글로벌 설정 (이것만으로도 충분) @BatchSize: 개별 최적화 -> 컬렉션 및 프록시 객체를 설정한 size만큼 한꺼번에 IN 쿼리로 조회 장점 페이징 가능 페치 조인 방식 보다 쿼리 호출 수는 약간 증가하지만, DB 데이터 전송량이 감소 적절한 배치 사이즈 전략 WAS, DB가 버틸 수 있으면 1000으로 설정 WAS, DB가 걱정된다면 100으로 설정하고 점점 늘리기 애매하면 500으로 설정 (100~500 두면 큰 문제 없이 사용 가능) DB 및 애플리케이션이 순간 부하를 어느정도로 견딜 수 있는지로 결정 DB에 따라 IN 절 파라미터를 1000으로 제한하는 경우도 있음 1000으로 잡으면 DB 및 WAS의 순간 부하 증가 (CPU 및 리소스) 100이면 시간은 더 걸리겠지만 순간 부하는 덜할 것 WAS 메모리 사용량은 100이든 1000이든 동일 distinct 하이버네이트 6 버전 부터는 컬렉션 조회 시 distinct 없이도 애플리케이션 단에서 자동으로 중복을 거른다. 6 이전에는 2가지 기능을 함께 수행했다. SQL에 distinct 추가 같은 엔터티가 조회되면 애플리케이션 단에서 중복 거르기 네트워크 호출 횟수와 데이터 전송량 네트워크 호출 횟수와 데이터 전송량 사이에는 성능 트레이드 오프가 존재한다. 모두 조인해서 가져오면, 한 번의 호출로 가져오지만 데이터 양이 많을 경우 성능이 저하된다. 여러 쿼리로 나눠 가져오면, 호출 수는 많아지지만 각각 최적화된 데이터 양으로 가져올 수 있어 더 나은 성능을 보일 수도 있다. 예를 들어, 한 쿼리로 1000개 데이터를 퍼올리는 상황이라면 여러 쿼리로 나누는게 나을 수 있다. 쿼리 방식 권장 선택 순서 기본: 엔터티 조회 후 DTO 변환 방식 (대부분의 성능 이슈 해결 가능) ToOne 관계 조회 페치 조인으로 쿼리 수 최적화 OneToMany 관계 조회 (컬렉션 조회) 페이징 필요 O ToOne인 부분은 최대한 페치 조인해서 가져옴 컬렉션은 hibernate.default_batch_fetch_size, @BatchSize 로 최적화 후 지연로딩 페이징 필요 X 페치 조인 최적화 e.g. 페이징이 없는 엑셀 다운로드 같은 기능은 페치 조인으로 조회 다만, 용량이 너무 많으면 앞의 default_batch_fetch_size 방법 이용 차선책: DTO 직접 조회 방법 사용 ToOne 관계 조회 단순 조인으로 한 번에 쿼리 OneToMany 관계 조회 (컬렉션 조회) 단건 One을 조회 -> One의 식별자로 Many를 조회 -> 서로 매핑 다건 분할 쿼리 (with IN 쿼리) - 권장 One을 조회 -> 해당 One의 식별자를 모아 Many를 IN 쿼리 -> Map 활용해 매핑 플랫 쿼리 한방 쿼리로 가져온 후 매핑 (페이징이 불가해 실무 비현실성, 성능 차이도 미비) 유지보수 방법 복잡한 통계 API 용으로 QueryService, QueryRepository 파서 DTO 직접 조회 사용 일반 리포지토리는 기본 엔터티 조회용으로 사용 -> 둘 구분으로 유지보수성 향상 최후의 방법: JPA 제공 네이티브 SQL 혹은 스프링 JDBC Template으로 직접 SQL 사용 이런 경우가 거의 없지만 DB 네이티브한 복잡한 기능 필요시 사용 참고 엔터티 조회 방식(페치 조인, BatchSize)으로 해결이 안되는 수준의 상황 서비스 트래픽이 정말 많은 상황이라 DTO 조회 방식으로도 해결이 안 될 가능성이 높음 캐시(레디스, 로컬 메모리 캐시) 사용이나 다른 방식으로 해결해야 함 엔터티 조회 방식은 코드 수정 거의 없이 옵션 변경만으로 성능 최적화하는 반면, DTO 직접 조회 방식은 성능 최적화 시 코드 변경이 많음 개발자는 성능 최적화와 코드 복잡도 사이에서 줄타기를 해야 한다. OSIV (Open Session In View) 전략 유래 Open Session In View: 하이버네이트 Open EntityManager In View: JPA 관례상 OSIV라고 함 하이버네이트가 JPA보다 먼저 나왔기 때문에, 이름 차이 발생 과거 하이버네이트 Session = JPA EntityManager 사용 전략 고객 서비스의 실시간 API는 OSIV 끄기 ADMIN 처럼 커넥션을 많이 사용하지 않는 곳에서는 OSIV 켜기 ADMIN은 해봤자 20~30명이 쓰는 서비스 한 프로젝트여도 멀티 모듈 사용해 분리 -> 고객 서비스와 ADMIN 서비스는 배포 군이 다름 spring.jpa.open-in-view = true (기본값) 최초 DB 커넥션 시작 시점부터 API 응답 종료까지 영속성 컨텍스트와 DB 커넥션을 유지 과정 JPA는 @Transactional 로 트랜잭션 시작시점에 커넥션을 가져옴 API 혹은 뷰 템플릿 렌더링이 끝나고 응답이 완전히 나가면 물고 있던 커넥션 반환 영속성 컨텍스트 종료 장점 API 컨트롤러 & View Template에서도 지연 로딩을 가능하게 함 영속성 컨텍스트는 기본적으로 DB 커넥션 유지 단점 (치명적) 너무 오랜시간 동안 DB 커넥션 리소스를 사용 (e.g. 컨트롤러에서 외부 API 호출) 실시간 트래픽이 중요한 애플리케이션에서는 커넥션이 모자라 장애 유발 일반적인 애플리케이션이라면 트랜잭션 종료 시 커넥션도 반환하는게 자연스러움 spring.jpa.open-in-view = false 트랜잭션을 종료할 때, 영속성 컨텍스트를 닫고 DB 커넥션 반환 장점: 커넥션 리소스 낭비 X 단점: 모든 지연 로딩은 트랜잭션안에서 처리해야 함 부분적 해결책: OSIV 켜기 / 트랜잭션 내에서 지연로딩 모두 처리 / 페치조인 영속성 컨텍스트 종료 후 바깥에서 지연 로딩 시 다음 예외 발생 LazyInitializationException: could not initialize proxy Command와 Query를 분리(CQS)하면 OSIV 끈 상태에서도 복잡성 관리가 편리 보통 성능 이슈는 조회에서 발생 핵심 비즈니스 로직과 조회 로직은 라이프사이클이 다름 뷰는 자주 변함 한 곳에 모았는데 핵심 비즈니스 로직 4~5개, 조회 로직 30개면 유지보수성 급격히 감소 패키지 구조 service.order.OrderService: 핵심 비즈니스 로직 service.order.query.OrderQueryService: 뷰 (주로 읽기 전용 트랜잭션 사용) 쿼리 서비스 용 패키지를 따로 두는게 좋음 엔터티를 뷰 용 DTO로 변환하는 작업을 QueryService에서 처리 Reference 실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화

Java-Ecosystem · 2024-11-26

JPQL Dive

JPQL 개요 단순한 조회 방법 EntityManager.find() 객체 그래프 탐색 - a.getB(), b.getC() 검색조건이 포함된 SQL의 필요성 단순 조회는 문제 없지만 애플리케이션이 필요한 데이터만 DB에서 불러오려면 결국 검색 SQL이 필요 (모든 DB 데이터를 객체로 변환해 검색하는 것은 불가능) JPQL 엔터티 객체를 대상으로 검색하는 객체 지향 SQL (JPA 제공) 반면에, SQL은 데이터베이스 테이블을 대상으로 쿼리 SQL을 추상화해서 특정 DB SQL에 의존 X JPQL은 현재 설정 Dialect와 합쳐져 현재 DB에 맞는 적절한 SQL을 생성하고 전달 DB를 바꿔서 Dialect가 바뀌었더라도 JPQL 자체를 바꿀 필요는 없음 JPQL 빌더 - QueryDSL 권장 문자가 아닌 자바코드로 JPQL을 작성할 수 있음 Criteria JPA 공식 기능 너무 복잡하고 실용성이 없음 QueryDSL 컴파일 시점에 문법 오류를 찾을 수 있음 편리한 동적쿼리 작성 단순하고 쉬움 네이티브 쿼리 - 네이티브 쿼리가 필요할 때는 JdbcTemplate을 사용하는게 낫다 JPQL로 해결할 수 없는 특정 DB 의존적인 기능 해결 e.g. 오라클 CONNECT BY, … 네이티브 SQL JPA에서 SQL을 직접 사용하는 기능 em.createNativeQuery(sql, 클래스) JDBC, JdbcTemplate, MyBatis 사용 주의점: 영속성 컨텍스트를 적절한 시점에 강제로 플러시 필요 JPA로 Persist만 해둔 데이터는 JdbcTemplate으로 커넥션을 얻어 SQL 조회시 조회 X 조회 직전 flush() 호출 필요 기본 조회 select m from Member as m where m.age > 18 테이블 이름이 아닌 엔터티 이름 사용 (Member) 별칭은 필수 (m, as는 생략 가능) 엔터티와 속성은 대소문자 구분 O JPQL 키워드는 대소문자 구분 X em.createQuery 반환 타입 TypedQuery 반환 타입이 명확할 때 사용 보통 엔터티 클래스를 넘김 TypedQuery<Member> query = em.createQuery("SELECT m FROM Member m", Member.class); Query 반환 타입이 명확하지 않을 때 사용 Query query = em.createQuery("SELECT m.username, m.age from Member m"); 결과 조회 API query.getResultList() 결과가 하나 이상일 때, 리스트 반환 결과가 없으면 빈 리스트 반환 query.getSingleResult() 결과가 정확히 하나, 단일 객체 반환 이외의 결과는 예외 일으킴 결과가 없으면 javax.persistence.NoResultException 둘 이상이면 javax.persistence.NonUniqueResultException 파라미터 바인딩 이름 기준 SELECT m FROM Member m where m.username=:username query.setParameter("username", usernameParam); 위치 기준 - 버그나기 쉬우므로 사용하지 말 것! SELECT m FROM Member m where m.username=?1 query.setParameter(1, usernameParam); 프로젝션 SELECT 절에 조회할 대상을 지정하는 것 DISTINCT로 중복 제거 엔터티 프로젝션 SELECT m FROM Member m 조회된 엔터티는 영속성 컨텍스트가 관리 SELECT m.team FROM Member m 이 경우 조인 쿼리가 나가는데 예측이 어려우므로 이 형태로 사용하지 말 것 조인쿼리는 직접 조인 쿼리로 작성하자 임베디드 타입 프로젝션 SELECT m.address FROM Member m 스칼라 타입 프로젝션 SELECT m.username, m.age FROM Member m 위와 같이 여러 값을 조회할 시 3가지 방법 존재 Query 타입으로 조회 TypedQuery에서 Object[] 타입으로 조회 DTO로 바로 조회 SELECT new jpabook.jpql.UserDTO(m.username, m.age) FROM Member m TypedQuery에서 UserDTO 타입으로 조회 패키지 명을 포함한 전체 클래스 명 입력 (문자 SQL이라 적어줘야 함) 순서와 타입이 일치하는 생성자 필요 페이징 API 각각의 DB Dialect에 맞게 JPA가 추상화 setFirstResult(int startPosition): 조회 시작 위치 (0부터 시작) setMaxResults(int maxResult): 조회할 데이터 수 //페이징 쿼리 String jpql = "select m from Member m order by m.name desc"; List<Member> resultList = em.createQuery(jpql, Member.class) .setFirstResult(10) .setMaxResults(20) .getResultList(); 조인 내부 조인 SELECT m FROM Member m [INNER] JOIN m.team t 외부 조인 SELECT m FROM Member m LEFT [OUTER] JOIN m.team t 세타 조인 연관 관계가 없는 테이블끼리 조인 (카테시안 곱 발생) select count(m) from Member m, Team t where m.username = t.name ON 절 (JPA 2.1부터 지원) 조인 대상 필터링 JPQL SELECT m, t FROM Member m LEFT JOIN m.team t on t.name = 'A' SQL SELECT m.*, t.* FROM Member m LEFT JOIN Team t ON m.TEAM_ID=t.id and t.name='A' 연관관계 없는 엔터티 외부 조인 JPQL SELECT m, t FROM Member m LEFT JOIN Team t on m.username = t.name SQL SELECT m.*, t.* FROM Member m LEFT JOIN Team t ON m.username = t.name 서브 쿼리 JPA는 WHERE, HAVING 절에서만 서브 쿼리 사용 가능 하이버네이트는 SELECT, FROM 절에서 서브 쿼리 가능하도록 지원 (FROM은 6부터 지원) 서브 쿼리 지원 함수 EXISTS (subquery): 서브쿼리에 결과가 존재하면 참 ALL (subquery): 모두 만족하면 참 ANY, SOME (subquery): 하나라도 만족하면 참 IN (subquery): 하나라도 같은 것이 있으면 참 JPQL 타입 표현 문자: ‘HELLO’, ‘She’’s’ 숫자: 10L(Long), 10D(Double), 10F(Float) Boolean: TRUE, FALSE ENUM: jpabook.MemberType.Admin (패키지명 포함) 파라미터 바인딩으로 풀면 패키지명 안 쓸 수 있음 엔티티 타입: TYPE(m) = Member (상속 관계에서 사용) em.createQuery(“select i from Item i where type(i) = Book”, Item.class) where 절에 DTYPE = ‘Book’ 으로 쿼리가 나감 조건식 CASE 식 기본 CASE 식 select case when m.age <= 10 then '학생요금' when m.age >= 60 then '경로요금' else '일반요금' end from Member m 단순 CASE 식 select case t.name when '팀A' then '인센티브110%' when '팀B' then '인센티브120%' else '인센티브105%' end from Team t COALESCE 조건식을 하나씩 차례로 조회해서 null이 아닌 조건식 반환 select coalesce(m.username,'이름 없는 회원') from Member m NULLIF 두 값이 같으면 null 반환, 다르면 첫 번째 값 반환 select NULLIF(m.username, '관리자') from Member m JPQL 기본 함수 및 사용자 정의 함수 JPQL 기본 함수 CONCAT SUBSTRING TRIM LOWER, UPPER LENGTH LOCATE: 문자 위치 찾기 (locate('de', 'abcdegf')) ABS, SQRT, MOD SIZE (JPA 용도): 컬렉션의 크기를 리턴 (select size(t.members) from Team t) 사용자 정의 함수 호출 등록 방법 Hibernate 6는 FunctionContributer 구현체를 만들어야 함 Hibernate 6 이전에는 방언을 상속받고 사용자 정의 함수 등록했음 src/main/resources/META-INF/services/org.hibernate.boot.model.FunctionContributor 위 파일을 생성해 구현체 등록 (custom.CustomFunctionContributor) package custom; import org.hibernate.boot.model.FunctionContributions; import org.hibernate.boot.model.FunctionContributor; import org.hibernate.dialect.function.StandardSQLFunction; import org.hibernate.type.StandardBasicTypes; public class CustomFunctionContributor implements FunctionContributor { @Override public void contributeFunctions(FunctionContributions functionContributions) { functionContributions.getFunctionRegistry() .register("group_concat", new StandardSQLFunction("group_concat", StandardBasicTypes.STRING)); } } 호출 방법 select function('group_concat', i.name) from Item i 경로표현식 .을 찍어 객체 그래프를 탐색하는 것 경로표현식에 의한 묵시적 조인은 쓰지 말자 최대한 JPQL과 실제 SQL의 모양을 맞춰 예측가능하게 만들어야 함 조인은 쿼리 튜닝에 중요 포인트이기 때문 유의사항: 묵시적 조인은 항상 내부 조인 명시적 조인 사용하자! (별칭으로 상세 탐색 가능) select m.username from Team t join t.members m 용어 상태 필드 (state field) 단순히 값을 저장하기 위한 필드 경로 탐색의 끝 (탐색 X) m.username 연관 필드 (association field) 연관 관계를 위한 필드 단일 값 연관 필드 대상이 엔터티 (@ManyToOne, @OneToOne) 묵시적 내부 조인 발생 (탐색 O) select m.team from Member m (e.g.m.team) 컬렉션 값 연관 필드 대상이 컬렉션 (@OneToMany, @ManyToMany) 묵시적 내부 조인 발생 (탐색 X) select t.members from Team t (e.g. t.members) 페치 조인 (fetch join) - join fetch JPQL에서 성능 최적화를 위해 연관된 엔터티나 컬렉션을 SQL 한 번에 함께 조회하는 기능 페치 조인으로 가져온 연관 엔터티는 프록시가 아닌 실제 엔터티 지정한 엔터티를 즉시 로딩으로 가져오므로, N + 1 문제를 해결 사용 전략 글로벌 로딩 전략은 모두 지연로딩으로 가져가고 최적화가 필요한 곳에 페치 조인 적용 조인 사용 전략 페치 조인으로 가져오기 (객체 그래프를 유지할 때 사용하면 효과적) 페치 조인으로 가져오고 애플리케이션 단에서 알맞는 DTO로 전환해 사용 일반 조인으로 필요한 데이터들만 조회해 DTO로 프로젝션 반환 여러 테이블을 조인해 원래의 엔터티 모양과 전혀 다른 결과를 내야 한다면 일반조인 사용 페치 조인과 일반 조인과의 차이 페치 조인은 회원을 조회하면 연관된 팀도 함께 조회 (SELECT T.*, M.*) [JPQL] select t from Team t join fetch t.members [SQL] SELECT T.*, M.* FROM TEAM T INNER JOIN MEMBER M ON T.ID=M.TEAM_ID 일반 조인은 연관된 엔터티를 함께 조회 X (SELECT T.*) [JPQL] select t from Team t join t.members m [SQL] SELECT T.* FROM TEAM T INNER JOIN MEMBER M ON T.ID=M.TEAM_ID 컬렉션 페치 조인 일대다 관계에서 실행하는 페치 조인 하이버네이트 6 이후 JPQL DISTINCT 없이도 애플리케이션에서 자동으로 중복 제거 적용 하이버네이트 6 이전 조인 시 데이터 중복 발생 DB와 객체의 차이 때문에 같은 엔터티 중복 발생 실제 팀은 1개인데 멤버와의 조인으로 발생한 행 수에 의해 2개의 팀이 반환 teamname = 팀A, team = Team@0x100 -> username = 회원1, member = Member@0x200 -> username = 회원2, member = Member@0x300 teamname = 팀A, team = Team@0x100 -> username = 회원1, member = Member@0x200 -> username = 회원2, member = Member@0x300 JPQL DISTINCT 컬렉션 페치 조인 데이터 중복 방지를 위해 적용 JPQL DISTINCT는 2가지 기능을 제공 SQL에 DISTINCT 추가 실제 SQL에 적용되지만, SQL 결과에서는 중복 제거할 것이 없음 애플리케이션에서 엔터티 중복 제거 애플리케이션 단에서 같은 식별자를 가진 엔터티 제거 DISTINCT 적용시 결과 teamname = 팀A, team = Team@0x100 -> username = 회원1, member = Member@0x200 -> username = 회원2, member = Member@0x300 유의 사항 여러 엔터티 다중 페치 조인 시에만 대상에 별칭을 쓰자 하이버네이트에서는 페치 조인 대상에 별칭 사용 가능 (가급적 사용 X) 페치 조인은 연관된 엔터티를 몇 개 걸러서 가져와서는 안됨 (정합성 이슈) 페치 조인은 연관된 엔터티를 항상 모두 가져와야 함 e.g. 팀 조회 시, 팀에 연관된 멤버가 5명일 때 멤버 3명만 가져와서는 안됨 이는 누락을 동반하는 매우 위험한 조작 (Cascade etc…) JPA 설계 사상은 연관된 모든 것을 다 조회하는 것을 전제하므로 위반 조심 둘 이상의 컬렉션은 페치 조인하지 말자 페치 조인은 컬렉션을 딱 하나만 지정하자 예상치 못하게 데이터 중복이 늘어날 수 있음 e.g Team.members, Team.orders를 한꺼번에 페치 조인해서는 안됨 컬렉션을 페치 조인하면 페이징 API 사용 불가 (메모리 페이징 문제로 매우 위험) 페이징 API: setFIrstResult, setMaxResults 문제 데이터 중복 1:M 컬렉션 페치 조인은 단순히 DB 상 조인 쿼리를 생성 DB에서 조인된 테이블의 로우는 M개 (1 기준으로는 중복된 row가 많은 상황) 따라서, 생성된 DB 쿼리 상 1 기준 페이징이 불가능 데이터 누락 문제가 JPA의 객체 그래프 사상을 위반 e.g. 팀 A에 멤버가 2명 있을 때, 이를 페치 조인해 pageSize를 1로 페이징 페이징은 철저히 DB 중심 -> 팀 & 멤버 조인 테이블에서 1개 row를 가져옴 (멤버1) DB 결과에 따라 JPA는 팀 A에 멤버가 1명 있다고 생각해 문제 발생 (멤버2 누락) 데이터 중복 및 누락을 피하기 위해 메모리 페이징 발생 (장애 유발 가능성 높음) 하이버네이트는 경고 로그를 남기고 강제로 메모리에서 페이징 (매우 위험) 실제로 조인 쿼리만 날리고 DB에서 페이징하지 않고 메모리에서 페이징 e.g. 100만 건 데이터를 모두 메모리에 올리고 메모리에서 페이징… 해결 방법 일대다 쿼리를 다대일 쿼리로 바꿔 실행 (권장) 일대일, 다대일 같은 단일 값 연관 필드들은 페치 조인해도 당연히 페이징 가능 쿼리 한 번으로 해결되므로 일반적으로 성능이 좋음 팀과 멤버 (OneToMany)에서 멤버 테이블로 페이징 쿼리 후 팀 기준 group by batchSize 적용 페치 조인을 하지 않고 지연 로딩 활용 (팀에 페이징 쿼리하고 멤버를지연로딩) 배치 사이즈는 N + 1 쿼리를 막고 설정한 단위 기준으로 in-query 진행 기본적으로 글로벌 배치 사이즈 깔고 모든 작업 진행 1000 이하의 적절한 수 지정 (보통 DB의 in 절 개수의 한계가 1000) persistence.xml <property name="hibernate.default_batch_fetch_size" value="100" /> application.properties spring: jpa: properties: hibernate: default_batch_fetch_size: 100 e.g. 팀이 150개고 멤버가 레이지 로딩될 때, batchSize가 100개인 상황 원래는 150개의 N + 1 쿼리가 발생하지만 이를 예방 100개 & 50개 뭉치로 총 2번 in-query해 가져옴 DTO 쿼리 다형성 쿼리 상속 관계 매핑에서 사용 type 조회 대상을 특정 자식으로 한정 (=DTYPE where 절 자동 적용) e.g. 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(하이버네이트) 절에서 사용 가능 e.g. 부모인 Item과 자식 Book이 있을 때, 자식 속성으로 where절 걸고 싶은 경우 [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] select count(m.id) as cnt from Member m - JPQL 둘 다 같은 SQL 실행 연관된 엔터티를 직접 사용하면 외래키 값 사용 [JPQL] select m from Member m where m.team = :team select m from Member m where m.team.id = :teamId [SQL] select m.* from Member m where m.team_id=? - JPQL 둘 다 같은 SQL 실행 Named 쿼리 미리 정의해서 이름을 부여해두고 사용하는 JPQL (=정적 쿼리) 에노테이션, XML에 정의 XML 정의가 항상 우선권을 가짐 애플리케이션 운영 환경에 따라 다른 XML 배포 가능 애플리케이션 로딩 시점에 초기화 후 재사용 - JPQL을 SQL로 미리 파싱 후 캐싱 약간의 속도 이점 애플리케이션 로딩 시점에 미리 쿼리의 예외를 검증하는 이점 에노테이션 정의 사용 예 @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(); 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><![CDATA[ select m from 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-mappings> 벌크 연산 여러 개의 데이터에 대한 갱신 쿼리 벌크연산은 주로 JPQL로 진행 JPA 자체는 실시간 단건성 작업에 적합 JPA 변경 감지 기능으로 실행하려면 너무 많은 SQL 실행 e.g. 100건의 엔터티라면 100번의 UPDATE SQL 실행 executeUpdate() 영향 받은 엔터티 수 반환 쿼리 한 번으로 여러 테이블 로우 변경 UPDATE, DELETE 지원 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(); insert into .. select 하이버네이트가 INSERT 지원 벌크 연산 사용 전략 JPQL은 영속성 컨텍스트를 무시하고 DB에 직접 쿼리하므로 벌크 연산 사용 맥락이 중요 사용 전략 1: 벌크 연산을 먼저 실행 영속성 컨텍스트에 아무 것도 하지 않고 벌크 연산만 실행 영속성 컨텍스트가 비어 있으니 벌크 연산으로 새로 조회가 발생해도 문제 없음 DB에서 최신 데이터 가져와 1차캐시에 반영할 것이므로 사용 전략 2: 벌크 연산 수행 후 영속성 컨텍스트 초기화 (em.clear()) 어떤 엔터티가 미리 조회되어 있는 상황에서 벌크 연산을 진행 JPQL 호출로 플러시 자동 발생 벌크 연산 후 영속성 컨텍스트는 DB에 비해 Old한 상태가 됨 e.g. 처음 조회한 회원 엔터티의 연봉이 5000만원 이후 수행한 벌크 연산에서 연봉이 6000만원이 되어 DB에 플러시됨 이 경우 애플리케이션에서는 여전히 회원 연봉이 5000만원임 따라서, 영속성 컨텍스트를 비워주어 깨끗한 상태에서 다시 조회될 수 있도록 해야 함 Reference 자바 ORM 표준 JPA 프로그래밍 - 기본편

Java-Ecosystem · 2024-06-08

JPA Dive

Java-Ecosystem · 2024-06-02

JPA 활용 팁 1

JPA 테이블 설계 Tips 주문 테이블은 orders로 주로 사용 (예약어 order by 때문에) 테이블 이름은 소문자 + _ 스타일 사용 실무에서 @ManyToMany는 사용하지 말자 중간 테이블에 컬럼을 추가할 수 없고 세밀한 쿼리가 어려움 @ManyToOne, @OneToMany로 풀어내서 사용 연관 관계에서 외래 키가 있는 곳을 연관 관계의 주인으로 정하기 (One-to-Many에서는 Many가 주인) Getter, Setter는 모두 제공하지 않고, 꼭 필요한 별도 메서드만 제공하는게 가장 이상적이지만 실무는 다름 Getter는 모두 열어놓으면 실무상 편리 엔티티 변경은 Setter를 모두 열어두기 보다 비즈니스 메서드를 별도 제공해 변경 지점이 명확하도록 함 엔티티의 식별자는 id로 쓰더라도 PK 컬럼명은 테이블명_id로 사용하자 Foreign key와 이름을 맞출 수 있는 장점 DBA들도 선호 Cascade=ALL 엔티티를 persist하면 다른 연관관계 엔티티까지 persist를 전파 Delete할 때는 모두 같이 지워짐 값 타입(임베디드 타입)은 변경 불가능하게 설계 @Setter를 제거하고 생성자에서 초기화 강제 기본 생성자를 protected로 두어 안전 향상 JPA 스펙 상 엔티티 및 임베디드 타입은 기본 생성자를 public 혹은 protected로 두어야 함 JPA가 객체 생성시 리플랙션 같은 기술을 사용할 수 있도록 지원해야 하기 때문 실무에서는 검증 로직이 있어도 멀티 쓰레드 상황을 고려해 변경 컬럼에 유니크 제약 조건 추가하는 것이 안전 엔티티 설계 시 주의점 모든 연관관계는 지연로딩(Lazy)으로 설정 즉시로딩(Eager)은 예측이 어렵고 N + 1 문제가 자주 발생 연관 관계 엔티티 로딩 시 fetch join 혹은 엔티티 그래프 기능 사용 @XToOne 관계는 기본이 즉시로딩이므로 직접 지연로딩 설정을 해야 함 컬렉션은 필드에서 초기화 null 문제에서 안전 Hibernate은 엔티티 영속화 시 컬렉션을 감싸서 Hibernate이 제공하는 내장 컬렉션으로 변경 (PersistentBag) - 필드 초기화가 내부 매커니즘을 안전하게 지켜줌 테이블, 컬럼명 생성 전략 기본 전략 하이버네이트 기존 구현 엔티티의 필드명을 그대로 테이블 컬럼명으로 사용 SpringPhysicalNamingStrategy 스프링 부트 신규 설정 Camel case -> Snake case . -> _ 추가 전략 명시적으로 컬럼, 테이블명을 적으면 실제 테이블에 물리명 적용 (physical-strategy) 적지 않은 경우 논리명 적용 (implicit-strategy) 애노테이션 Tips @PersistenceContext 엔티티 매니저(EntityManger) 주입 Lombok 생성자 주입 사용시 애노테이션 생략 가능 @Transactional readOnly=true 플러시를 하지 않으므로 약간의 성능 향상 디폴트는 readOnly=false이므로, 큰 스코프에서 readOnly=true를 설정하고 커맨드성 작업에 @Transactional을 붙이는 방식으로 사용하면 편리 테스트에 붙으면, 테스트 종료 후 자동으로 트랜잭션 롤백 테스트를 환경을 위한 설정 파일 테스트 케이스에는 메모리 DB 사용이 효율적 데이터 소스나 JPA 관련 별도 추가 설정을 하지 않아도 됨 스프링 부트는 datasource 설정이 없으면 기본적으로 메모리 DB 사용 스프링 부트는 jpa 설정이 없으면 ddl-auto: create-drop 모드로 동작 설정 파일 읽기 전략 테스트에서 스프링을 실행하면, test/resources/application.yml을 읽음 해당 위치에 없을 경우, src/resources/application.yml 읽음 도메인 모델 패턴 VS 트랜잭션 스크립트 패턴 도메인 모델 패턴 엔티티가 비즈니스 로직을 가지고 객체 지향의 특성을 적극 활용하는 패턴 (서비스 계층은 단순히 엔티티에 필요한 요청을 위임하는 역할) 트랜잭션 스크립트 패턴 엔티티에는 비즈니스 로직이 거의 없고 서비스 계층에서 대부분의 비즈니스 로직을 처리하는 패턴 변경 감지(Dirty Checking) & 병합(merge) 준영속 엔티티 영속성 컨텍스트가 더이상 관리하지 않는 엔티티 이전에 DB에 한 번 저장되어서 식별자가 존재하나 JPA가 현재 추적하고 있지 않는 객체 준영속 엔티티를 수정하는 2가지 방법 변경 감지(Dirty Checking) - Recommendation 동작 식별자로 엔티티를 조회(find)한 후 데이터 수정 컨텍스트가 종료되면서 트랜잭션 커밋 시점에 변경 감지가 동작하고, 데이터베이스에 UPDATE SQL 실행 병합(merge) 동작 준영속 엔티티의 식별자 값으로 영속 엔티티를 조회 영속 엔티티의 값을 준영속 엔티티의 값으로 모두 교체 (병합) 트랜잭션 커밋 시점에 변경 감지 기능이 동작해서 데이터 베이스에 UPDATE SQL 실행 병합은 모든 필드를 변경해버리고 데이터가 없으면 null로 업데이트하므로 위험 Best Practice: 엔티티 변경시 항상 변경 감지 사용하기 컨트롤러에서 엔티티 생성하지 말기 서비스 계층에 식별자(id)와 변경할 데이터를 명확히 전달 (파라미터 or DTO) 서비스 계층에서 영속 상태의 엔티티를 조회하고, 엔티티의 데이터를 직접 변경 트랜잭션 커밋 시점에 변경 감지 자동 실행

Java-Ecosystem · 2024-03-26

Lucian Log

Contact

JPA