Feature: ranking system 등락 여부 10분마다 업데이트

[JunYupK]

개요

현재 ranking system에서 response data 타입이 {keyword: string, count: number} 인데 2번째 인자인 count에 인기검색어의 10분전의 순위 변동을 보여주는 기능입니다.

작업사항

• redis에 10분마다 현재 redis의 1~100위까지의 인기검색어를 저장을 하는 Interval작업을 수행합니다.
• REDIS_PREVRANKING 환경 변수가 1~100위까지의 검색어를 저장하는 key값입니다.
• keyword-ranking api 요청을 받으면 현재 redis의 인기검색어에서 10분 전의 1 ~ 100위까지의 인기검색어와 비교하여 등수 변동을 정수로 반환합니다. (음수는 10분전보다 감소등수, 양수는 증가, 0은 유지, null 값은 1~100위 안에 없던 새로운 급등 new 검색어)
• 10분마다 10분전의 1~100위의 데이터를 삭제 후 새롭게 현재 인기검색어 데이터로 업데이트 하는 작업
• 엘라스틱서치 파이프라인 데이터 타입 set을 이용한 queue로 변경

[JunYupK]

혹시 redis에 10분 간격으로 prevRanking을 업데이트할 때는 업데이트 당시의 순위를 저장하고, 클라이언트에서 keyword-ranking api 요청이 오면 요청이 온 순간의 순위와 prevRanking에 저장된 순위를 비교해서 순위변동을 계산하는게 맞을까요?

만약 redis에 업데이트된 지 얼마 지나지 않고 클라이언트가 api 요청을 한다면 그 사이에 순위 변동이 일어났을 확률이 적기 때문에 매 10분마다 순위를 저장하는게 아니라 이전 순위와의 차이를 저장하면 어떨까 합니다. (혹시 제가 코드를 잘못 이해했다면 말씀 부탁드립니다!)

이전 순위와의 차이를 저장한다는 아이디어 자체는 매우 좋다고 생각합니다. 더 간결하게 redis에서 데이터를 가져올 수 있다는 장점이 있다고 생각합니다. 처음에 이러한 방식을 선택한 이유가, 추후에 다른 서비스의 확장 가능성을 두기 위해서 추가적으로 10분 전의 등수를 활용하기 위해서였던 것 같습니다. update의 간격을 줄이거나, 이전의 등수를 활용하는 서비스는 구체화 된 것이 없으나, (실시간 급상승 검색어 정도가 생각나네요) 이후에 혹시나 업데이트 전의 1~100위 까지의 순위 데이터가 활용될지도 모른다고 생각하고, 차이를 저장하는 것이 아니라 순위를 저장하는 방향으로 설계를 한 것 같습니다.