<aside> ❗

V1 - 엔티티 직접 노출

@GetMapping("/api/v1/orders")
    public List<Order> orderV1() {
        List<Order> all = orderRepository.findAllByString(new OrderSearch());
        for (Order order : all) {
            order.getMember().getName();
            order.getDelivery().getAddress();

            List<OrderItem> orderOrderItems = order.getOrderItems();
            for (OrderItem orderItem : orderOrderItems) {
                orderItem.getItem().getName();
            }
        }
        return all;
    }

• Hibernate5Module 모듈 등록, LAZY = null 처리
• 프록시를 강제로 초기화하면 Hibernate5Module 설정에 의해 엔티티를 JSON으로 생성
• 양방향 연관관계면 무한 루프에 걸리지 않도록 @JsonIgnore 애너테이션 추가
• 엔티티를 직접 노출하는 것은 좋은 방법이 아니다. </aside>

<aside> ❗

V2 - 엔티티를 DTO로 변환

• 특정 Dto 안에 엔티티를 모두 DTO로 바꿔야 한다.
• 임베디드 타입은 괜찮다.

@GetMapping("/api/v2/orders")
    public List<OrderDto> orderV2() {
        List<Order> orders = orderRepository.findAllByString(new OrderSearch());
        List<OrderDto> collect = orders.stream().map(o -> new OrderDto(o)).collect(Collectors.toList());
        return collect;

    }

    @Data
    static class OrderDto {

        private Long orderId;
        private String name;
        private LocalDateTime orderDate;
        private OrderStatus orderStatus;
        private Address address;
        private List<OrderItemDto> orderItems;

        public OrderDto(Order order) {
            this.orderId = order.getId();
            this.name = order.getMember().getName();
            this.orderDate = order.getOrderDate();
            this.orderStatus = order.getOrderStatus();
            this.address = order.getDelivery().getAddress();
            this.orderItems = order.getOrderItems().stream()
                    .map(orderItem -> new OrderItemDto(orderItem))
                    .collect(Collectors.toList());
        }
    }

    @Data
    static class OrderItemDto {
        private String itemName;
        private int orderPrice;
        private int count;

        public OrderItemDto(OrderItem orderItem) {
            this.itemName = orderItem.getItem().getName();
            this.orderPrice = orderItem.getItem().getPrice();
            this.count = orderItem.getCount();
        }
    }

• 지연 로딩으로 너무 많은 SQL 실행

[참고]

• 지연 로딩은 영속성 컨텍스트에 있으면 영속성 컨텍스트에 있는 엔티티를 사용하고 없으면 SQL을 실행한다.
• 따라서 같은 영속성 컨텍스트에서 이미 로딩한 회원 엔티티를 추가로 조회하면 SQL을 실행 X </aside>

<aside> ❗

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

• 쿼리가 조금만 복잡해지더라도 쿼리DSL을 사용해라
• DB 입장에서 조인을 하면, N 만큼 row 수가 뻥튀기가 된다. (데이터 뻥튀기)
• 예시) Order는 한 개 인데, Order와 관련된 OrderItems이 두 개인 경우 조인하게 되면 Order가 두 개인 조인 테이블을 반환한다.

DISTINCT 키워드

• 실제 쿼리가 나갈 때, DISTINCT 키워드가 붙어서 실행되게 된다. (DB에서 수행) 하지만, 해당 키워드는 완전히 동일한 로우의 경우만 제거됨
• 그래서 JPA가 한 가지 작업을 더 수행한다. (애플리케이션에서 수행) DISTINCT가 붙어있으면 동일한 Id를 갖는 로우를 제거해 중복 제거를 수행한다.
• !!!!!!!!!!!!! 단점 : 페이징 불가능 → 데이터가 어떻게 뻥튀기 될지 모르기 때문에 고정된 단위로 페이징 할 수 없음 → 모든 데이터를 메모리에 읽어와 메모리에서 페이징을 수행 → 데이터가 많은 경우 문제 발생 !!!! (Out Of Memory 발생 가능)

public List<Order> findAllWitehItem() {
        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", Order.class)
                .getResultList();
    }

// v2와 동일
@GetMapping("/api/v3/orders")
    public List<OrderDto> orderV3() {
        List<Order> orders = orderRepository.findAllWitehItem();

        List<OrderDto> collect = orders.stream().map(o -> new OrderDto(o)).collect(Collectors.toList());
        return collect;
    }

[참고]

• **!!!!!!!!!!!!!!컬렉션 페치 조인은 1개만 사용**할 수 있다.
• 컬렉션 둘 이상에 페치 조인을 사용하면 안 된다. (데이터 뻥튀기되면 데이터를 못 맞출 수 있음)
• 데이터가 부정합하게 조회될 수 있다. </aside>

<aside> ❗

V3.1 - 엔티티를 DTO로 변환 - 페이징 한계 돌파

• 컬렉션을 페치 조인하면 페이징 불가능
  • 컬렉션을 페치 조인하면 **일대다 조인이 발생하므로 데이터가 예측할 수 없이 증가**한다.
  • 일대다에서 일(1)을 기준으로 페이징 하는 것이 목적이다. 그런데 데이터는 다(N)를 기준으로 row가 생성된다.
  • Order를 기준으로 페이징하고 싶은데, 다(N)인 OrderItem을 조인하면 OrderItem이 기준이 되어 버린다. → 결국 OrderItem 기준으로 페이징이 된다. (우리가 원하는 것이 아님)
• 이 경우 하이버네이트는 경고 로그를 남기고 모든 DB 데이터를 읽어서 메모리에서 페이징을 시도 최악의 경우 장애로 이어질 수 있다. (OOM 문제 발생 가능)

한계 돌파

• 페이징 + 컬렉션 엔티티를 함께 조회하려면 어떻게 해야하는가 ??
• 대부분의 페이징 + 컬렉션 엔티티 조회 문제는 다음의 방법으로 해결

• xToOne(OneToOne, ManyToOne) 관계를 모두 페치모인 한다. Order → Member, Delivery A → B → C 도 가능 (A, B, C 모두 ToOne 인 경우도 가능, B는 C를 의존)
• ToOne 관계는 row 수를 증가시키지 않으므로 페이징 쿼리에 영향을 주지 않는다.
• **컬렉션은 지연 로딩으로 조회**한다. (페치 조인 하지 마라) → 페이징 가능해짐
• 지연 로딩 성능 최적화를 위해 hibername.default_batch_fetch_size, - 글로벌 설정 @BatchSize를 적용한다. → N + 1 의 경우 하나씩 Select를 수행하지만 이를 사용하면 정해진 개수 만큼 미리 가져온다.)
• bibernate.default_batch_fetch_size: 글로벌 설정

  jpa:
    properties:
      hibernate:
        default_batch_fetch_size: 

• @BatchSize: 개별 최적화 → size 개수는 IN 쿼리 개수를 몇 개로 설정한 것인지
• 이 옵션을 사용하면 컬렉션이나, 프록시 객체를 한꺼번에 설정한 size 만큼 IN 쿼리로 조회

ToMany는 해당 필드에 @BatchSize() 애너테이션을 붙이고

@BatchSize(size = 1000)
    @OneToMany(mappedBy = "order", cascade = CascadeType.ALL)
    private List<OrderItem> orderItems = new ArrayList<>();

ToOne인 경우 해당 엔티티 상단에 @BatchSize() 애너테이션을 붙여야 한다.

@BatchSize(size = 1000)
@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "dtype")
@Getter @Setter
public abstract class Item { ... }

[처리 과정]

1. Order 정보를 페치 조인을 통해서 가져온다.
2. 지연로딩으로 설정된 OrderItems 엔티티에 접근 시, Order 정보(OrderId)를 이용하여 OrderItems 100개에 대하여 IN 쿼리를 수행한다. 만약 다 가져오지 못했다면 반복 수행 (BatchSize = 100) → 가지고 와서 영속성 컨텍스트에 저장

select oi1_0.order_id,oi1_0.order_item_id,oi1_0.count,oi1_0.item_id,oi1_0.order_price 
from order_item oi1_0 
where oi1_0.order_id in (1,2)

1. OrderItems의 Item 엔티티에 접근시 OrderItems 정보(orderItemsId)를 이용하여 Items 100개에 대하여 IN 쿼리를 수행한다. 만약 가져오지 못했다면 반복 수행 → 가지고 와서 영속성 컨텍스트에 저장

select i1_0.item_id,i1_0.dtype,i1_0.name,i1_0.price,i1_0.stock_quantity,i1_0.artist,i1_0.etc,i1_0.author,i1_0.isbn,i1_0.actor,i1_0.director 
from item i1_0 
where i1_0.item_id in (1,2,3,4)

[참고]

• 일대다일 때, 페치 조인을 사용하면 한 번의 쿼리가 나가지만 중복 데이터가 많아져 DB에서 애플리케이션으로 전송되는 데이터의 크기가 커진다.
• BatchSize를 사용하면 쿼리는 더 나가지만 중복 데이터가 없음 DB에서 애플리케이션으로 전송되는 데이터의 크기가 작다.

</aside>

<aside> ❗

정리

spring:
	jpa:
		properties:
			hibernate:
				default_batch_fetch_size: 1000

• 개별로 설정하려면 @BatchSize를 적용하면 된다. (컬렉션은 컬렉션 필드에, 엔티티는 클래스에 적용)

[장점]

• 쿼리 호출 수가 1 + 1로 최적화 된다.
• 조인보다 DB 데이터 전송량이 최적화 된다. - 대부분은 페치 조인을 사용할 것 Order와 OrderItem을 조인하면 Order가 OrderItems 만큼 중복해서 조회된다. 하지만 현재 방법은 각각 조회하므로 전송해야할 중복 데이터가 없다.
• 페치 조인 방식과 비교해서 쿼리 호출 수가 약간 증가하지만, DB 데이터 전송량이 감소한다.
• ret컬렉션 페치 조인은 페이징이 불가능 하지만 **이 방법은 페이징이 가능**하다.

결론

• ToOne 관계는 페치 조인해도 페이징에 영향을 주지 않는다.
• ToOne 관계는 페치 조인으로 쿼리 수를 줄이고
• 나머지는 hibernate.default_batch_fetch_size로 최적화하자

[참고]

• default_batch_fetch_size 의 크기는 적당한 사이즈를 골라야 하는데, **100~1000 사이를 선택하는것을 권장`**한다.
• 이 전략을 SQL IN 절을 사용하는데, 데이터베이스에 따라 IN 절 파라미터를 1000으로 제한하기도 한다.
• 1000으로 잡으면 한번에 1000개를 DB에서 애플리케이션에 불러오므로 DB에 순간 부하가 증가할 수있다.
• 하지만 애플리케이션은 100이든 1000이든 결국 전체 데이터를 로딩해야 하므로 메모리 사용량이 같다. ( 일반적으로 처음부터 끝까지 순회하기 때문에 다 찰 때까지 대기해야 함 ) → OOM 발생 확률은 동일
• 1000으로 설정하는 것이 성능 상 가장 좋지만, 결국 **DB든 애플리케이션이든 순간 부하를 어디까지 견딜 수 있는지로 결정**하면 된다.

</aside>

<aside> ❗

</aside>

<aside> ❗

</aside>

<aside> ❗

</aside>

<aside> ❗

</aside>