L.O.K

[JPA] 조회 API 성능 최적화하기 ( XToMany ) (1) [JPA] 조회 API 성능 최적화하기 ( XToOne ) JPA에서 조회(SELECT)는 성능최적화가 반드시 고려되어야 한다. 엔티티는 다른 엔티티와 연관관계를 맺고 있기에 엔티티를 조회하는 과정에서 예상치 못한 lordofkangs.tistory.com 지난 포스팅에서는 JOIN FETCH로 조회API 성능최적화를 해보았다. JOIN FETCH의 문제는 일대다 관계에서 컬렉션을 페이징하지 못함에 있다. 페이징이 필요없다면 상관없지만 페이징이 필요하다면 다른 방법이 필요하다. 4. default_batch_fetch_size로 최적화하기 JOIN FETCH로 일대다 연관관계의 페이징이 안되면 깔끔히 포기하자. 대신 Lazy 페치전략을 ..

[JPA] 조회 API 성능 최적화하기 ( XToOne ) JPA에서 조회(SELECT)는 성능최적화가 반드시 고려되어야 한다. 엔티티는 다른 엔티티와 연관관계를 맺고 있기에 엔티티를 조회하는 과정에서 예상치 못한 쿼리가 다량으로 발생할 수 있다.( N+1 문 lordofkangs.tistory.com 조회(SELECT)는 성능 최적화가 반드시 고려되어야 한다. 엔티티는 다른 엔티티와 연관관계를 맺고 있어, 엔티티를 메모리에 로딩하는 과정에서 연관된 엔티티 로딩하는 전략을 생각해야 한다. 지난 포스팅에서는 일대일,다대일 관계(XToOne)에서 조회 API를 성능최적화를 해보았다. 이번 포스팅에서는 컬렉션 개념이 등장하는 일대다, 다대다 관계( XToMany )에서 조회 API의 성능을 최적화 해보겠다. ..

JPA에서 조회(SELECT)는 성능최적화가 반드시 고려되어야 한다. 엔티티는 다른 엔티티와 연관관계를 맺고 있기에 엔티티를 조회하는 과정에서 예상치 못한 쿼리가 다량으로 발생할 수 있다.( N+1 문제 ) 이번 포스팅에서는 일대일,대대일 관계(XToOne)에서의 조회API 코드를 단계별로 최적화해보겠다. 일대다관계( XToMany )는 컬렉션 개념이 추가되므로 다음 포스팅에서 다루어 보겠다. 1. 엔티티가 외부로 노출되는 코드 @GetMapping("api/v1/simple-orders") public List orderV1(){ List all = orderRepository.findAll(new OrderSearch()); return all; // 엔티티를 외부로 반환 } 위 Controller ..

스프링은 3계층으로 나뉜다. 프레젠테이션 계층은 Client(화면)과 네트워크 통신을 하며 화면구현을 담당한다. 서비스 계층은 데이터를 처리하는 비즈니스 로직을 가지고 있다. 데이터 엑세스 계층은 DB와 통신하여 데이터를 CRUD하는 역할을 담당한다. JPA의 엔티티(Entity)는 관계형DB의 테이블과 매핑되는 개념으로 데이터 엑세스 계층에서 사용하는 기본단위이다. 엔티티는 테이블 정보가 담긴 클래스로 매우 민감한 정보를 가지고 있다. 그러므로 엔티티가 외부로 노출되는 위험은 없어야 한다. 엔티티의 외부노출을 막기 위해 엔티티를 정제한 클래스를 하나 생성하는데, 그것이 DTO(Data Transfer Object)이다. DTO(Data Transfer Object) DTO는 프레젠테이션 계층에서 화면과..

준영속 엔티티를 수정하는 방법은 두 가지가 있다. 1. merge ( 병합 ) 2. DirtyChecking ( 변경감지 ) 준영속 엔티티 수정은 merge보다는 DirtyChecking이 권고된다. 왜 그럴까? 준영속 엔티티란? 준영속엔티티란 영속성 엔티티의 관리를 받고 있지 않은 엔티티를 의미한다. 예를들어, DB에서 조회한 Book 엔티티 리스트를 추출하여 만든 화면이다. '조회' 작업이 끝나면 트랜잭션이 종료되어 영속성컨텍스트도 종료된다. 여기서 수정 버튼을 클릭해보자. 데이터를 수정하고 Submit 버튼을 누르면, 새로운 Book 엔티티가 생성된다. 근데 다른 점이 하나 있다. 동일한 식별자가 이미 DB에 있다. '생성(create)'이 아닌 '수정(update)'은 식별자가 가리키는 레코드를 ..

[JPA] 영속성 컨텍스트의 이점 [JPA] JPA 동작원리 ( 영속성 컨텍스트 ) [JPA] 패러다임의 불일치 어플리케이션 개발은 주로 객체지향언어로 이루어진다. 객체지향언어는 현실의 많은 문제를 코드로 구현하지만 문제가 있다. 데이 lordofkangs.tistory.com 지난 포스팅에서 영속성컨텍스트의 이점에서 변경감지(DirtyChecking)를 다루어보았다. 엔티티에 변경사항이 감지되면 영속성컨텍스트는 자동으로 UPDATE,DELETE문을 생성하였다. 그러나 이 방법은 변경감지 한 건당 하나의 쿼리문을 생성한다. 만약 100개의 변경감지가 만들어졌다면 100개의 쿼리가 생성되어 실행된다. 이는 성능에 좋지 못하다. 그래서 UPDATE문,DELETE문을 JPQL로 만들어 여러 건의 변경및삭제를 ..

Named쿼리란, 쿼리에 이름을 부여한 쿼리이다. @Entity @NamedQueries({ @NamedQuery(name = "Person.findAll", query = "SELECT p FROM Person p"), @NamedQuery(name = "Person.findByAge", query = "SELECT p FROM Person p WHERE p.age = :age") }) public class Person { @Id private Long id; private String name; private int age; } 엔티티와 관련된 NamedQuery를 사용하면 '이름'으로 편하게 JPQL을 재활용할 수 있다. public class PersonRepository { @Persisten..

https://lordofkangs.tistory.com/390. [JPA] JOIN 과 JOIN FETCH의 차이 JOIN과 JOIN FETCH를 헷갈릴 수 있다. FROM 엔티티A JOIN FETCH 엔티티B FROM 엔티티A JOIN 엔티티B JOIN FETCH를 사용하면 엔티티A,엔티티B 둘 다 영속화 된다. JOIN을 사용하면 엔티티A만 영속화 된다. JOIN은 엔티 lordofkangs.tistory.com 연관관계있는 엔티티는 JOIN을 활용하여 다른 엔티티에 접근한다. 그렇다면 상속관계에 있는 엔티티들은 어떻게 접근할까? JPA는 상속구조에 유용한 함수를 제공한다. 함수를 이용하면 JOIN문을 사용하지 않아도 부모가 자식에 접근할 수 있다. TYPE SELECT i FROM Item i W..

엔티티의 연관 엔티티를 로드하는 전략은 두 가지가 있다. 1. 지연로딩 ( Lazy ) 2. 즉시로딩 ( Eager ) 그러나 두 가지 전략은 문제가 있다. 즉시로딩은 연관된 엔티티를 로드하려고 SELECT문이 자동으로 하나 생성되어 실행된다. 지연로딩은 연관된 엔티티에 무언가가 접근하면 SELECT문이 자동으로 생성되어 실행된다. 이를 N+1문제라 한다. 개발자는 한 개의 쿼리를 만들었는데, 자동으로 N개의 쿼리가 생성되어 실행되는 것이다. 이처럼 N개의 쿼리문이 추가로 실행된다면 반복적으로 DB와 I/O가 발생하여 성능에 좋지 못한 영향을 준다. JOIN FETCH 페치 조인의 목적은 하나의 쿼리로 연관된 엔티티를 모두 로드하는 것이다. 이는 특정 로직에 필요한 '데이터'를 추출하려는 목적이 아니다...

JPA는 JPA Parser가 JPQL을 파싱하면서 연관된 엔티티를 참조하는 경우, JOIN이 없어도 JOIN절을 생성하는 묵시적 조인을 지원한다. Member 엔티티는 Team 엔티티와 연관된다. JPQL에서는 연관된 엔티티를 '.'으로 접근할 수 있다. String jpql1 = "SELECT distinct m.team FROM Member m "; TypedQuery typedQuery1 = entityManager.createQuery(jpql1,Team.class); List results1 = typedQuery1.getResultList(); JPQL은 JOIN문은 없고 '.'으로 연관 엔티티에 접근하였다. 그럼 정말 JPA(하이버네이트)가 자동으로 JOIN문을 만드는지 확인해보자. INN..