추천 리스트 조회 로직의 변경

[GEISHAz]

기존 추천리스트 조회는 알다시피 RC(Recruit Condition)과 JC(Job Condition) Table에 대하여 조회가 들어갔을시 점수계산을 그때그때 수행했었습니다.

이처럼 SQL 쿼리에서 지역, 요일, 시간, 조건들의 필터링을 수행한 결과 데이터가 많아지면 많아질수록 병목이 늘어나

1000개의 JC 100개의 RC 기준

API 요청시 13 초라는 경이로운 응답속도가 확인됐습니다.

로그를 찍어본 결과 쿼리조회에서 7초, 점수계산에서 6초정도의 부하가 걸렸었습니다.

그래서 구조를 변경하기로 했습니다.

그리하여

기존 JC와 RC의 지역, 요일, 시간들의 필터링을 SQL에서 전부 수행하던 과정에서
변경되거나 삽입되는 데이터 JC/RC 1개 에 대한 지역 필터링만을 통해 SQL 연산을 대폭 줄였고

API 요청시 ScoreTable 에서 이미 계산된 점수들만 조회 되도록 변경하여 조회시간을 단축했습니다.

또, JC/RC가 변경 또는 삽입 될때
쿼리에서 조회된 지역이 일치하는 데이터들에 대해 점수계산을 진행할때
로직상
JC지역(5)과 RC지역(1)
JC시간(1)과 RC시간(N)
JC요일(1)과 RC요일(N)
을 비교하게 되어있습니다.

FetchType.Lazy로 지연로딩 설정되어있어 각 지역에 대해 지역과 시간및 요일을 계산때마다 불러와야했고 이러한 N+1문제로 인해
recruitTime과 workLocation을 FetchType.Eager로 변경했습니다.