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)'은 식별자가 가리키는 레코드를 ..

https://lordofkangs.tistory.com/406 [Spring] 의존성 주입이란? ( Dependency Injection ) Spring의 핵심개념은 의존성 주입(DI)이다. 의존이란,A의 기능이 동작하려면 객체B가 존재해야 함을 의미한다. 예를들어, Controller는 웹화면을 구성하는 역할을 한다. 화면을 구성하려면 서비스에 lordofkangs.tistory.com 지난 포스팅에서 의존성 주입에 대해서 알아보았다. 의존성 주입(DI)은 세가지 방식으로 이루어진다. 1) 생성자 주입방식 ( final ) 2) 필드 주입방식 ( @Autowired ) 3) 수정자 주입방식 ( Setter ) 세가지 방식 중 '필드주입방식'은 권고되지 않는다. 권고되지 않는 이유를 생성자,수정자 주입..

Spring의 핵심개념은 의존성 주입(DI)이다. 의존이란,A의 기능이 동작하려면 객체B가 존재해야 함을 의미한다. 예를들어, Controller는 웹화면을 구성하는 역할을 한다. 화면을 구성하려면 서비스에 맞는 데이터를 전달 받아야 한다. 그러므로 Controller는 데이터를 서비스에 맞게 처리하는 로직을 가지고 있는 Service에 의존한다. Service는 데이터가 필요하므로 데이터를 가져오는 기능을 갖는 Repository에 의존한다. 이처럼, 객체지향구조는 서로 '의존'하고 있는 구조이다. 그러나 의존을 주입하는 코드를 개발자가 직접 구현하면 객체를 직접 관리해야 하고 객체간 결합도가 증가시킬 수 있다. Spring 프레임워크 존재 이유는 여기에 있다. Spring은 컨테이너라는 공간이 있다...

[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..