JPA 패치조인 활용

 

패치조인 

 

위의 이미지는 주문 내역을 불러오는 컨트롤러다 . 패치 조인을 사용하지 않고 위의 코드가 실행된다면 

n+1 문제가 발생하여 쿼리가 5번 나간다 위에 코드에서 n은 주문 수를 나타내고  +1은 처음 주문을 불러오는 쿼리를 말다 주문수가 2개이고 연관된 테이블 수(회원,배송)에 따라 n번씩 추가가 되기떄문에 

총쿼리수는 n+n+1 = 5 가 된다 

 

이런 상황에서는 성능 최적화를 위해 패치조인을 사용하는 것이 좋다 .

 

-패치 조인을 통해 리스트를 불러오는 메서드-

 

 

-패치 조인을 통해 생성된 쿼리-

 

join fetch 연관된 엔티티명을 적어주면  조인을 통해 한번에 데이터를 불러오기 때문에 쿼리는 한번만 생성된다 .

패치조인은 join 으로 지정해놓은 테이블의 모든 데이터를  가져오기 때문에 selelct절이 길어진다

 

여기서 한번더 성능을 최적화 하기 위해서는 직접 쿼리를 짜는 방식을 사용하는 것이 좋다

 

 

-직접 조인 쿼리를 생성해 사용 -

-셀렉트된 데이터를 담을 DTO-

 

순서

1. Order 엔티티를 담을 DTO를 만든다 

2. 쿼리에서 select  다음에 new하여 Dto객체를 생성하고 파라미터로

   from절의 Order 엔티티를 사용하여 Dto에 넣어준다 

3. 연관관계를 갖는 테이블에 join 하여 데이터를 얻어내고 

4. 결과를 DTO로 반환 받는다

 

-Dto로 바로 반환 받는 쿼리결과-

 

위의 패치 조인보다 셀렉트절이 줄어서 성능이 더 최적화 되고 원하는 데이터만 알맞게 가져올 수 있다.

 

 

하지만

패치조인을 사용하는

직접 쿼리를 짜는 방식간에는

trade off가 있다

 

패치조인의 경우는 짜여진 것을 건드리지 않는 방식으로 가져오기 때문에 재사용성이 높다

            또 엔티티로 조회하기 때문에 더티체킹활용이 가능하다

 

직접 쿼리를 짜는 방식은 쿼리에 알맞은 상황에만  사용할 수 있기 때문에 재사용성이 낮다. 

              DTO로 받아오기 때문에 변경이 불가하다.

              물리적으로는 계층이 나눠져있지만 논리적으로는 계층이 깨져있다

              repository로 화면을 의존하게된다 API 스펙이 변경된다면 갈아엎어야한다

             

정말 성능 최적화가 필요하다면

              성능 최적화 쿼리용 repository를 따로만들어 사용하는 것도 방법이다. 

              repository는 순수 엔티티를 조회하는 용도로 사용하는 것이 좋다

 

쿼리 방식 권장 순서

 

1. 우선 엔티티를 DTO로 변환하는 방법으로 해보고

2. 성능이 구리면 패치조인으로

3. 그래도 구리면 DTO로 직접 조회하는 쿼리

4. 마지막 네이티브 SQL or 스프링 JDBC Template 로 쿼리 작성

 

조인에서 성능을 잡아먹는데 쿼리를 보면 조인문은 같다 

select 쿼리가 엄청 많거나 정말 트레픽이 많은 API가 아니면 성능 차이가 크게 나진 않는다 

맞게 말했는지 모르겠다 하여간 그렇다