Tech Log 🛠️

OSIV란

OSIV(Open Session In View)를 사용하면 최초 데이터베이스 커넥션 시작 시점부터 API 응답이 끝날 때까지 영속성 컨텍스트와DB 커넥션을 유지한다. 이렇게 함으로써 뷰와 컨트롤러에서 지연 로딩을 할 수 있다. 

*트랜잭션이 시작할때 DB커넥션을 획득한다.

하지만  이 전략은 큰 단점이 있는데,  너무 오랜 시간 DB 커넥션을 유지함으로 인해  리소스 부족 장애로 이어질 수 있다는 것이다.따라서 상황에 맞는 OSIV 전략이 필요하다.

OSIV 동작 방식

jpa에서는 OSIV의 기본값을 true (사용)으로 제공하고 있다.

1. 클라이언트 요청이 들어오면 서블릿 필터나 스프링 인터셉터에서 영속성 컨텍스트를 생성한다.

2. 서비스 계층에서 미리 만들어둔 영속성 컨텍스트로 트랜잭션을 시작한다.(@Transactional 어노테이션이 있는 곳)

3. 트랜잭션을 커밋하면 영속성 컨텍스트를 플러시하지만 영속성 컨텍스트를 종료시키지는 않는다, (뷰, 컨트롤러까지 유지)

4. 요청이 돌아오면 플러시를 하지 않고 영속성 컨텍스트를 바로 종료한다.

OSIV OFF

OSIV를 끈 상태에서 트랜잭션이 끝나면 DB 커넥션을 반환하므로 리소스를 낭비하지 않는다.

하지만 영속성 컨텍스트도 종료시켜 버리기때문에 뷰와 컨트롤러에서 지연로딩을 할수없다.따라서 트랜잭션 내에서 모든 지연로딩을 처리해야한다.

이를 해결하기 위해서는 OSIV 를 다시 켠다거나 , 페치 조인을 사용하는 등 여러 방법이 있지만

가장 단순하게 관심사를 분리하는 것만으로 문제를 해결할 수 있다. (커맨드와 쿼리 분리)

커맨드와 쿼리 분리

보통 핵심 비즈니스로직은 한번 개발하면 쉽게 바뀌지 않는다.

반면 화면을 구성하는 뷰로직은 개발이 시작된 뒤에도 여러 번 바뀌므로 둘의 라이프 사이클이 다르다.

따라서 둘의 관심사를 명확하게 분리하는 것은 유지보수 관점에서 충분히 의미있다.

ex)

OrderService
OrderService: 핵심 비즈니스 로직
OrderQueryService: 화면이나 API에 맞춘 서비스 (주로 읽기 전용 트랜잭션 사용)

두 서비스 모두 트랜잭션을 유지하면서 지연로딩을 사용할 수 있다.

컬렉션 조회 최적화 - 1 에서는 엔티티를 조회한 후에 DTO로 변환시키는 방식으로 하였지만,

이번 챕터에서는 JPA 에서 DTO를 직접 조회하는 방식으로 진행한다.

JPA에서 DTO 직접 조회

DTO를 조회할 때, ToOne 관계들을 먼저 조회하고 ToMany 관계들은 별도로 처리하는 방식이 좋다.ToOne 관계를 먼저 처리하는 이유는 Row  수에 영향을 주지 않기 때문이다.하지만 ToMany 관계는 Row수를 증가시키므로(데이터 뻥튀기) 별도로 처리하는 편이 좋다.

private List<OrderQueryDto> findOrders() {return em.createQuery(
"select new
jpabook.jpashop.repository.order.query.OrderQueryDto(o.id, m.name, o.orderDate,
o.status, d.address)" +
" from Order o" +
" join o.member m" +
" join o.delivery d", OrderQueryDto.class)
.getResultList();
}

/**
* 1:N 관계인 orderItems 조회
*/

private List<OrderItemQueryDto> findOrderItems(Long orderId) {
return em.createQuery(
"select new
jpabook.jpashop.repository.order.query.OrderItemQueryDto(oi.order.id, i.name,
oi.orderPrice, oi.count)" +
" from OrderItem oi" +
" join oi.item i" +
" where oi.order.id = : orderId",
OrderItemQueryDto.class)
.setParameter("orderId", orderId)
.getResultList();
}

위의 코드에서 findOrder() 메소드를 통해 주문들을 모두 조회한다.

주문들을 모두 조회하는 이유는 엔티티와 주문은 ToOne 관계이기 때문이다.

주문 아이템들은 별도로 처리해주었는 데 이 역시 위에서 설명한대로 ToMany 관계이기 때문에 별도로 처리하였다.

public List<OrderQueryDto> findOrderQueryDtos() {
//루트 조회(toOne 코드를 모두 한번에 조회)
List<OrderQueryDto> result = findOrders();
//루프를 돌면서 컬렉션 추가(추가 쿼리 실행)
result.forEach(o -> {
List<OrderItemQueryDto> orderItems =
findOrderItems(o.getOrderId());
o.setOrderItems(orderItems);
});
ret

이렇게 조회된 결과들을 DTO에 매핑시켰다.

하지만 이렇게 하면, id 를 조회할때 쿼리 1번이 발생하고 그 뒤로 컬렉션을 조회할 때 쿼리 N번이 발생하므로 

1+N 문제가 생긴다. 

따라서 최적화가 필요하다.

JPA에서 DTO 직접 조회 - 컬렉션 조회 최적화

기존의 루프를 돌면서 조회했던 방식을 Map 자료구조를 이용함으로써 1+N 문제를 개선할 수 있다.

private Map<Long, List<OrderItemQueryDto>> findOrderItemMap(List<Long>
orderIds) {
List<OrderItemQueryDto> orderItems = em.createQuery(
"select new
jpabook.jpashop.repository.order.query.OrderItemQueryDto(oi.order.id, i.name,
oi.orderPrice, oi.count)" +
" from OrderItem oi" +
" join oi.item i" +
" where oi.order.id in :orderIds", OrderItemQueryDto.class)
.setParameter("orderIds", orderIds)
.getResultList();
return orderItems.stream()
.collect(Collectors.groupingBy(OrderItemQueryDto::getOrderId));
}

기존 코드와 다른 점은 파라미터로 주문Id (식별자) 가 담긴 리스트를 넘겨줬다는 것이다.

이렇게 함으로써 기존 루프 쿼리가 아닌 in쿼리를 통해 아이템 정보가 담긴 데이터들을 한번에 가져올 수 있다.

그리고 이렇게 불러온 데이터들을 Map 을 이용하여 메모리에 적재한다.

result.forEach(o -> o.setOrderItems(orderItemMap.get(o.getOrderId())));

마지막으로 DTO 에 매핑시킬 때, 이미 메모리에 적재되있는 상태이므로 추가 쿼리가 발생하지 않는다.

이렇게 함으로써 루트 쿼리에서 1번 , 컬렉션 조회할 때 1번만 쿼리가 발생하므로 1+N 문제를 해결할 수 있다.

JPA에서 DTO로 직접 조회, 플랫 데이터 최적화

쿼리를 한번만 날려서 필요한 데이터들을 모두 가져오는 방법으로 , 위와는 다른 접근 방식이다.

public List<OrderFlatDto> findAllByDto_flat() {
return em.createQuery(
"select new
jpabook.jpashop.repository.order.query.OrderFlatDto(o.id, m.name, o.orderDate,
o.status, d.address, i.name, oi.orderPrice, oi.count)" +
" from Order o" +
" join o.member m" +
" join o.delivery d" +
" join o.orderItems oi" +
" join oi.item i", OrderFlatDto.class)
.getResultList();
}

먼저 조회할 데이터들을 "모두" 가져온다.

public List<OrderQueryDto> ordersV6() {
List<OrderFlatDto> flats = orderQueryRepository.findAllByDto_flat();

return flats.stream()
.collect(groupingBy(o -> new OrderQueryDto(o.getOrderId(),
o.getName(), o.getOrderDate(), o.getOrderStatus(), o.getAddress()),
mapping(o -> new OrderItemQueryDto(o.getOrderId(),
o.getItemName(), o.getOrderPrice(), o.getCount()), toList())
)).entrySet().stream()
.map(e -> new OrderQueryDto(e.getKey().getOrderId(),
e.getKey().getName(), e.getKey().getOrderDate(), e.getKey().getOrderStatus(),
e.getKey().getAddress(), e.getValue()))
.collect(toList());
}

그 다음 이처럼 어플리케이션 단계에서 API 스펙에 맞게 추가 작업을 해주어야한다.

보기만 해도 어지럽다 ..

이 방법은 여러가지 단점이 있다.

1. 모든 데이터를 필터링 없이 가져오기 때문에 중복 데이터가 발생한다.     

    중복 데이터까지 함께 가져오므로 쿼리는 줄었지만 오히려 성능은 저하될 수 있다..

2. 어플리케이션 단계에서 추가 작업을 해줘야한다. 

3. 페이징이 안된다!      

    주문 하나(1)당 여러개(N)의 데이터들이 딸려오는데 여기서 페이징을 하면 (N)을 기준으로 페이징이 된다.

일대다 관계인 컬렉션을 페치 조인으로 조회할 때,

하나의 정보에 여러개의 컬렉션이 있는 경우 데이터가 늘어나기 때문에 최적화에 어려움이 있다.

때문에 하이버네이트 옵션을 줌으로써 해당 문제를 해결할 수 있다.

엔티티 직접 노출

@GetMapping("/api/v1/orders")
public List<Order> ordersV1() {
List<Order> all = orderRepository.findAllByString(new OrderSearch());
for (Order order : all) {
order.getMember().getName(); //Lazy 강제 초기화
order.getDelivery().getAddress(); //Lazy 강제 초기환
List<OrderItem> orderItems = order.getOrderItems();
orderItems.stream().forEach(o -> o.getItem().getName()); //Lazy 강제
초기화
}
return all;
}

LAZY로딩이 되어있는 프록시를 강제 초기화시켜주어야한다.

하지만 이 방법은 엔티티를 직접 노출시키기 때문에 좋은 방법이 아니다.

엔티티를 DTO로 변환

public List<OrderDto> ordersV2() {
List<Order> orders = orderRepository.findAll();
List<OrderDto> result = orders.stream()
.map(o -> new OrderDto(o))
.collect(toList());
return result;
}

Order 객체를 가져온 뒤 OrderDto 로 변환시킨다.엔티티에 대한 의존을 완전히 끊어야 하기 때문에 단순히 Order에 대한 정보만이 아닌, Item에 대한 정보도 Dto로 변환시킨다.

static class OrderItemDto {
private String itemName;//상품 명
private int orderPrice; //주문 가격
private int count;
//주문 수량
public OrderItemDto(OrderItem orderItem) {
itemName = orderItem.getItem().getName();
orderPrice = orderItem.getOrderPrice();
count = orderItem.getCount();
}
}

하지만 이렇게  되면 여러 개의 여러 번의 지연로딩이 발생할 때마다 쿼리가 발생하기 때문에 1+N 문제가 발생한다.

EX) 주문 1개 ,  주문 정보 N개 , 주문 상품 M개 ->1 + N + M 번의 쿼리 발생

엔티티를 DTO로 변환- 패치 조인 최적화

public List<Order> findAllWithItem() {
return em.createQuery(
"select distinct o from Order o" +
" join fetch o.member m" +
" join fetch o.delivery d" +
" join fetch o.orderItems oi" +
" join fetch oi.item i", Order.class)
.getResultList();
}

이처럼 페치 조인을 통해 최적화를 해주면 , 쿼리가 한번만 실행됨으로써 기존 1+N 문제를 해결할 수 있다.

JPA 쿼리문의 distinct 는 두 가지 기능을 한다.

1. SQL 에 distinct  추가

2. 같은 엔티티 중복 제거

하지만 , 이 코드에서 페이징을 하게 되면 DB가 아닌 메모리에서 페이징을 해버린다.

이것은 메모리 초과(out of memory)를 일으킬 수 있는 매우 위험한 행위임으로 하지 않는 것이 좋다.

* 컬렉션 페치 조인은 1개만 사용할 수 있다. 둘 이상 사용하면 데이터 부정합 발생

엔티티를 DTO로 변환- 페이징 적용

앞선 코드에서 페이징이 안됐던 이유는 일대다 조인에서 데이터가 예측할 수 없이 증가(N)하기 때문이다.하지만 여기서 페이징을 하게되면 페이징 기준이 N 에 맞추어진다.

따라서 JPA는 이 경우 메모리에서 페이징 처리를 하는데 이것은 매우 위험하다 !

일대다 관계에서 페이징 처리를 하려면 다음과 같이 하면 된다.

1. ToOne 관계는 ROW 수를 증가시키지 않으므로 페치 조인을 한다.

2. 컬렉션은 지연로딩으로 설정한다.

3. hibernate.default_batch_fetch_size , @BatchSize 를 적용한다. (DB에서 미리 불러올 데이터 수)

public List<Order> findAllWithMemberDelivery(int offset, int limit) {
return em.createQuery("select o from Order o" +
" join fetch o.member m" +
" join fetch o.delivery d", Order.class)
.setFirstResult(offset)
.setMaxResults(limit)
.getResultList();
}

spring:
jpa:
properties:
hibernate:
default_batch_fetch_size: 1000

ToOne 관계를 한방쿼리로 가져오고 ,  default_batch_fetch_size 를 설정해주면, 설정한 사이즈만큼 컬렉션은 in 쿼리에 담아서 반환한다.

따라서 기존 1+ N 이었던 쿼리 수가 1+1 로 줄어든다. 

사실 ToOne 관계도 굳이 페치 조인 안해도 상관 없는데 이렇게 하면 쿼리를 줄일 수 있다.

만약 조회 할 데이터 수가 2개이고 사이즈를 1로 설정했으면 , 쿼리가 두번 실행된다. (1 X 2)

만약 조회 할 데이터 수가 100개이고 사이즈를 10으로 설정했으면 , 쿼리가 열번 실행된다. (10 X 10)

이 방법은 페치 조인으로 했을 때 보다 쿼리는 약간 많이 발생했을지는 몰라도 데이터 최적화가 되어있기 때문에 성능은 더 좋다.

하지만 소규모 데이터일 경우 페치 조인으로 하는 게 더 빠를 수 있다 (상황 by 상황)

이전 강의 내용 

엔티티를 Request Body 에 직접 매핑할 경우 문제점

- 엔티티에 프레젠테이션 , API 검증을 위한 로직이 추가된다. 

  하지만 실무에서는 엔티티를 이용한 여러 API들이 만들어지는데 , 각각의 API들을 위한 모든 요청사항들을 담기는 어렵다.

  또한 엔티티가 변경되면 API 스펙이 변한다 !

- 따라서 엔티티를 Requst Body 에 직접 매핑시키는 것이 아닌 , API 를 위한 DTO를 따로 만들어서 이것을 파라미터로 받아야한다.

- DTO를 통해서 파라미터를 받으면 다음과 같은 장점이 있다.

  1. 엔티티와 프레젠테이션을 위한 로직을 분리할 수 있다.

       - 이제 더 이상 엔티티가 여러 API들을 위한 요청사항들을 담을 필요가 없다. 

  2. 엔티티와 API 스펙을 명확하게 분리할 수 있다.

       - 엔티티가 변경되도 API 스펙이 변하지 않는다.

지연로딩과 조회 성능 최적화

@GetMapping("/api/v1/simple-orders")
 public List<Order> ordersV1() {
 List<Order> all = orderRepository.findAllByString(new OrderSearch());
 for (Order order : all) {
 order.getMember().getName(); //Lazy 강제 초기화
 order.getDelivery().getAddress(); //Lazy 강제 초기환
 }
 return all;
 }

API를 개발할 때 위의 코드를 사용한다고 생각해보자 !

위의 코드는 두 가지의 문제가 있다.

1. 엔티티를 직접 노출한다.

2. 프록시 객체를 조회하므로 예외가 발생한다.

엔티티를 직접 노출하는 거는 그렇다치고 먼저 예외를 해결해야한다.

위 코드가 예외가 발생하는 이유는 엔티티를 불러오는 방식이 fetch.LAZY 인데,

JACKSON 라이브러리가 프록시 객체를 어떻게 json으로 생성할지 모르기 때문이다.

이 문제를 해결하기 위해선 하이버네이트 모듈을 설치함으로써 해결할 수 있다. 

이렇게 함으로써 초기화된 프록시 객체만 노출하고 초기화되지 않는 프록시 객체는 노출시키지 않는다.(null로 나옴)

근데 엔티티를 직접 노출시키는 것은 매우 안좋기 때문에 애초에 이렇게 하면 안된다 !

차라리 DTO를 반환시키자

주의사항

1. 엔티티를 직접 노출할 때 양방향 연관관계가 걸린 곳은 꼭 @JsonIgnore 처리를 해야한다. (안하면 무한루프 걸림)

2. 지연 로딩 문제를 해결한다고 EAGER 로 바꾸면 더 골치아파 진다.

엔티티를 DTO로 반환

@GetMapping("/api/v2/simple-orders")
public List<SimpleOrderDto> ordersV2() {
 List<Order> orders = orderRepository.findAll();
 List<SimpleOrderDto> result = orders.stream()
 .map(o -> new SimpleOrderDto(o))
 .collect(toList());
 return result;
}

@Data
static class SimpleOrderDto {

 private Long orderId;
 private String name;
 private LocalDateTime orderDate; //주문시간
 private OrderStatus orderStatus;
 private Address address;
 public SimpleOrderDto(Order order) {
 orderId = order.getId();
 name = order.getMember().getName();
 orderDate = order.getOrderDate();
 orderStatus = order.getStatus();
 address = order.getDelivery().getAddress();
 }
 
}

이제 엔티티를 직접 노출시키는 게 아닌 DTO를 반환시키는 방식으로 코드를 수정했다.

하지만 이 코드는 1+N 문제를 일으킨다.

로딩방식이 fetch.LAZY이므로 , order에서 member를 조회할때 N번

                                                order에서 Delivery를 조회할때 N번 조회된다.(1+N+N)

*지연로딩은 연속성 컨텍스트에서 조회되므로 , 이미 조회된 경우 쿼리 생략 

페치 조인 최적화

public List<Order> findAllWithMemberDelivery() {
 return em.createQuery(
 "select o from Order o" +
 " join fetch o.member m" +
 " join fetch o.delivery d", Order.class)
 .getResultList();
}

1+N 문제는 다음과 같이 페치 조인을 사용해서 해결할 수 있다.

원래는 member 와  delivery 를 따로 따로 조회했지만 이제는 한번에 조회함으로써 조회 성능을 높일 수 있다.

(지연로딩이 되지 않는다)

*페치조인(fetch join)이란? 

  - jpql에서 성능 최적화를 위해 제공하는 기능 

    연관된 엔티티나 컬렉션을 한번에 같이 조회할 수 있다.

리포지토리에서 DTO 직접 조회

public List<OrderSimpleQueryDto> findOrderDtos() {
 return em.createQuery(
 "select new
jpabook.jpashop.repository.order.simplequery.OrderSimpleQueryDto(o.id, m.name,
o.orderDate, o.status, d.address)" +
 " from Order o" +
 " join o.member m" +
 " join o.delivery d", OrderSimpleQueryDto.class)
 .getResultList();
 }

일반적인 SQL문을 사용하는 것처럼 원하는 값을 선택해서 조회하는 방법이다.

select 절에서 원하는 데이터를 직접 선택하기 때문에 네트워크 용량을 '근소하게' 최적화 할 수 있다.

하지만 결국 API 스펙에 맞춘 코드가 리포지토리에 들어간다는 점과 특정 API 만을 위한 값만을 반환해줘서 리포지토리 재사용이 떨어지는 다는 점을 감안해보면, 페치 조인보다 결코 좋다고 할 수는 없는 방식이다.

만약 이와 같은 API를 만들어야한다면 따로 패키지를 만들어서 관리해주는 것이 좋다.

(DTO를 직접 조회하는 것은 화면을 위한 로직이기 때문)

정리하자면,

먼저 엔티티를 조회하는 방식을 사용하고 페치조인으로 최적화를 한다.

여기서 대부분 문제가 해결되지만 추가로 성능 최적화를 진행해야 한다면 DTO를 직접 조회하는 방법을 선택한다.

이래도 안된다면 네이티브 SQL이나 JDBC 템플릿을 이용해서 SQL을 직접 사용한다. (촤후의 방법)

연관관계 맵핑 시 고려해야 할 3가지 

1. 다중성 

    ex) 다대일 , 일대일 

2. 단방향 , 양방향

   - 테이블은 외래키 하나로 양쪽 조인이 가능하지만 , 객체는 참조용 필드가 있는 곳으로만 참조가 가능하다.

   - 따라서 양방향 관계라는 것은 참조용 필드가 양쪽 모두 있는 경우를 말한다.

3. 연관 관계의 주인

   - 객체는 테이블과 달리 참조가 두 군데에서 만들어 양방향 관계를 설정한다.

   - 참조용 필드가 양쪽에 있는 양방향 관계에서 외래키를 관리할 "연관 관계의 주인"이 필요하다.

   a. 연관 관계의 주인

       - 외래키를 관리한다.

   b. 주인의 반대편

       - 외래키의 영향을 주지 않고 단순 조회만 가능하다 !!

연관 관계의 종류

1. 다대일 [n:1]

    - 가장 많이 사용한다.

1-1 . 다대일 양방향

    - 외래키가 있는 쪽이 연관관계의 주인이다.

2. 일대다 [1:n]

   - 일대다 관계에서는 '1' 이 연관 관계의 주인이지만 테이블에서는 n이 외래키를 가지고 있으므로 주인이 반대편 

     테이블의 외래키를 관리하는 특이한 구조가 된다. 

   - 따라서 원치않은 sql문이 발생할 수 있다. (복잡한 실무에서 운영이 매우 힘들어진다.)

   - 이러한 특성때문에 일대다보다는 객체지향 설계에 조금 손해를 보더라도 다대일 양방향 관계로 하는 것이 좋다 !

   - @JoinClumn을 사용하지 않으면 조인테이블(중간테이블) 방식을 사용한다.

2.1 일대다 양방향

   - 공식적으로 존재하지 않지만 읽기 전용 필드를 사용해서 만들 수 있다.

@JoinColumn(insertable=false, updatable=false)

    - 웬만하면 다대일 양방향 관계를 사용하자 !

3. 일대일 [1:1]

   - 일대일 관계의 반대도 일대일이다.

   - 주 테이블이나 대상 테이블에 외래키를 선택할 수 있다.

3-1. 일대일 주 테이블 외래키 단방향

   - 다대일 단방향 맵핑과 유사하다

3-2. 일대일 주 테이블 외래키 양방향

    - 외래키가 있는 곳이 연관 관계의 주인이다.

    - jpa맵핑이 편리하지만 외래키에 null을 허용해야한다.

3-3. 일대일 대상 테이블 외래키 단방향

    - jpa에서 지원하지 않는다. 
3-4. 일대일 대상 테이블 외래키 양방향

    - 3-2과 맵핑 방법이 같다.
    - 테이블 관계를 변경해도 테이블을 유지할 수 있지만 , 항상 즉시 로딩이 된다.(프록시 기능의 한계)

4. 다대다 [n:n]

     - 관계형 DB는 테이블 두개로 다대다 관계를 표현할 수 없지만 객체는 컬렉션을 사용해서 다대다 관계가 가능하다.

     - 하지만 다대다 맵핑을 사용하면 여러 부가 정보들이 연결 테이블에 들어올 수 없기 때문에 실무에선 부적합하다.

     - 중간 테이블이 숨겨져 있기 때문에 예상치 못한 쿼리가 발생한다.

     - 사용하지 말자 !!

4.1. 다대다 관계의 대안 

     - 연결 테이블을 엔티티로 승격하고 다대다를 다대일,일대다로 바꿔서 변경한다.

     - 이렇게하면 연결테이블에 여러 정보들을 넣을 수 있다.