Spring jpa의 사실과 오해
우연히.. youtube를 보던 도중 NHN에서 올린 Spring JPA의 사실과 오해라는 알고리즘이 내 유튜브에 떳고
해당 영상을 시청하고 새롭게 알게된 지식을 다시한번 기록하기위해 작성하려고 합니다.ㅎㅎ
흔히 JPA를 통해 entity설계 및 로직을 구현해본사람이면 N+1문제는 알 것이빈다.
한번의 쿼리가 나갈 것을 예상하고 쿼리를 작성했는데 연관관계의 의해 N번의 쿼리가 추가적으로 나가는 것을
N+1이라고하는데 , 이것이 EAGER Fetch 타입뿐만아니라 lazy로딩에서도 발생될 수 있고,
findAll과 같이 jpql이 먼저 수행되는 로직이 작성됐을 때도 발생할 수 있다는 이야기를 해주셨다.
위에 설명을 읽으니까 너무 이해가 잘 됐다. findAll같은 경우 단일 레코드 조회가 아닌경우,
해당 JPQL을 먼저 수행하고 반환된 하나하나에 대해 entity에 설정된 fetch전략을 적용해 연관 entity를 가져오기
때문에 findAll에서도 역시 N+1문제가 발생할 수 있다.
이것 또한 페이징처리 + fetch Join을 통해 조회로직을 작성해본 사람은 알 수 있다. 실제로 fetch join과 pagination를 같이
사용하게되면 fetch join을 통해 연관된 모든 레코드를 가져오고 메모리안에서 pagination이 이루어지기때문에 outofmemory exception이 일어나 heap 메모리에 과부하를주어 성능에 악화가된다. 그래서 저는 예전에 이것을 batch fetch size를 통해
in절로 toMany는 in절로 toone은 fetch join으로 해결하였다. 김영한님의 강의를 들어보신 사람은 누구나 알 것이다.
Embedded타입은 _ (언더스코어)를 통해 내부 속성값을 접근 할 수 있다.
JPA Repository메소드로도 Join이 가능하다... 오우..
이건 내가 예전에 정리를 해뒀었다. slice는 count쿼리가 나가지않고 pagnation은 count쿼리가 발생한다.
또한 slice는 다음페이지를 알기위해 limit가 우리가 전달한 리미트보다 하나를 더 가져온다. 그 레코드가 next가 있는지
여부를 파악하여 다음 페이지를 알 수 있다. 즉 slice는 스크롤페이징 처리할 때 유용할 것같고, pagination은 게시판처럼
1,2,3,4,5페이지처럼 명확하게 해당 페이지를 알 수 있다면 좋을 것같다.
위에껀 내가 요약하고 요약해서 내가 알아보기쉬운형태로 정리한 것이기때문에 더욱 많은 정보가 필요한 사람들을 위해
참고한 유튜브링크를 남기겠습니다