JPA #7 - 컬렉션 조회 최적화 1

JPA 학습

API 개발 고급 - 컬렉션 조회 최적화

주문 조회 V1: 엔티티 직접 노출

주문 조회 V2: 엔티티를 DTO로 변환

• 단순 VO는 응답으로 노출되어도 괜찮다.
• 1:N 관계로 컬렉션을 사용하게되면 쿼리양이 많이 늘어난다. 그러므로 최적화를 잘 해야 한다.

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

• JPA에서는 primary key(id)가 같으면 같은 객체이다.
• JPQL distinct는 SQL distinct보다 한 가지 기능을 더 제공한다.
  • DB의 distinct는 row - column 전체가 완전 동일해야 하나로 취급하여 중복제거가 가능하다.
  • JPQL의 distinct는 DB에서 가져온 전체 데이터를 root entity id를 이용하여 한번 더 거른다. id가 같으면 같은 객체로 인식하여 중복제거가 가능하다. (실제 DB에서는 중복제거가 안된 상태로 어플리케이션 단으로 데이터를 전송한다.)
• 치명적인 단점으로는 1:N 컬렉션 관계를 fetch join하는 순간 paging query 처리가 불가해진다.
  • DB에서는 데이터가 1:N 관계만큼 증가되므로 DB단에서 처리가 불가하여 어플리케이션 메모리 영역에서 처리하도록 경고를 낸다. (데이터 양이 많아지면 out of memory. 굉장히 위험하다.)
• 컬렉션 페치 조인은 1개만 사용할 수 있다. 컬렉션 둘 이상에 페치 조인을 사용하면 안된다. 데이터가 부정합하게 조회될 수 있다. (1 -> N -> M)