[🔨 fix/#140] 검색화면 totalPages, totalCount 데이터 부정확한 오류 수정 및 count 쿼리 성능 개선

[JungYoonShin]

📄 Work Description

• 검색화면 totalPages, totalCount 데이터 부정확한 오류 수정 및 count 쿼리 성능 최적화

⚙️ ISSUE

• closed [🔨 fix] 검색결과화면 toalPages, totalCount 오류 #140

📷 Screenshot

• postman화면

💬 To Reviewers

🔊 로컬에서는 잘 되는 것 확인했는데, 스테이징 서버에 머지하고 잘 되는지 추가로 확인은 해봐야할 것 같습니다!

1. 검색화면에서 totalPages와 totalCount 수가 정확히 전달되지 않았던 원인은 아래와 같습니다.

@onetomany에서 fetchjoin() 사용시의 데이터 중복 문제

• InternshipAnnounctment 와 scrap을 fetchjoin()으로 조회하고자 했는데, fetchjoin()이 내부적으로 innerjoin()을 사용하기 때문에 중복된 데이터가 발생하였습니다! (참고 블로그)
  • 해당 문제를 해결하기 위해 고려한 방안이 2가지가 있었는데요!
    • 1. distinct() 사용을 통한 데이터 중복제거
    • 2. fetchjoin() 제거를 통한 데이터 중복제거

위의 2가지 해결 방안 중 저는 2번을 선택했습니다! 해당 방안을 선택한 이유는 아래와 같습니다.

현재상황에서는 fetchjoin() 사용하지 않을때의 이점이 사용할 때의 이점이 더 크다고 판단

• 예를들어, 하나의 인턴공고에 대해 여러명의 유저가(100명) 스크랩을 했다고 했을 때, 100개의 중복 데이터가 생기게 되며 이는 인턴공고가 많은 저희 서비스 특성상 기하급수적으로 중복데이터가 생기게 된다고 생각하여, 성능상 좋지 않을 거라고 판단하였습니다.
• 또한 현재 상황에서 지연로딩으로 인한 N+1 문제가 발생하지 않는 것을 확인하여, fetchjoin()을 굳이 사용하지 않아도 될 것 같다는 생각입니다!

2. PageableExecutionUtils 사용을 통한 count 쿼리 성능 개선

• 기존 PageImpl을 사용하여 totalCount를 조회하던 것에서 PageableExecutionUtils를 사용하여 성능을 개선했습니다.
• 기존에는 무조건 요청이 들어올 때마다 count 쿼리가 나갔는데, 현재는 아래 두 상황에 대해서는 쿼리가 나가지 않게 됩니다!
  • 시작페이지(0)이고, 페이지 사이즈(요청들어온 size)보다 조회된 인턴공고 사이즈가 더 작을 때
  • 마지막 페이지이고, 조회된 인턴공고 사이즈가 페이지 사이즈(요청 들어온 size)보다 더 작을 때 -> count 쿼리 대신 offset() 크기와 조회된 인턴 공고 사이즈를 더해서 계산함

🔗 Reference

[Querydsl] Pagination 성능 개선 part1.PageableExecutionUtils

[junggyo1020]

fetchjoin()이 내부적으로 innerjoin()을 사용하기 때문에 생긴 중복 데이터 때문에 생긴 문제였군요..!
적당한 근거에 맞춰서 fetchjoin()을 없애는 방향으로 변경한 부분을 잘적어주셔서 읽고 이해하기에 굉장히 편했습니다!
N+1문제도 미리 고려해서 발생하지 않는 부분을 확인한 것도 좋네요:)
고생하셨습니다..!