[스마일게이트 인턴] 추천 피드

#1 추천 피드

캐싱을 쓰는 이유는?

-> 유동적인 값을 커서로 사용할 수 없는 페이징 방식 때문이다. 그래서 캐싱된 데이터만 api 호출 시 pull 하는 방식으로 변경

< 생각한 방식들 >

1. 10분 단위로 카테고리 별 좋아요 기준으로 내림차순 정렬된 게시글들을 캐싱 // 채택 !!
   1. 정렬된 데이터를 캐싱 해 놓으면 유저들에게 해당하는 카테고리의 데이터를 바로 줄 수 있으며, Redis에서 Sorted Set 자료구조를 통해 데이터를 효율적으로 관리 가능하기 때문이다. 
2. 카테고리 별로 전체 content 중 범위를 나누어 n개의 content를 캐싱하고, 캐싱된 contents 범위 안에서 pull(read)할때 마다 유동적으로 바뀐 좋아요 수를 기준으로 정렬해서 read 시켜준다.

* batch vs cache

배치를 선택하지 않고 캐싱을 선택한 이유

• 배치는 10분 단위를 주기로 모든 content node마다 like score값을 update 시켜줘야 한다.
• 캐싱은 ORDER BY 좋아요 하나로 정렬시킨 값으로 캐시메모리에 바로 넣어주면 된다.

 

따라서 배치보단 캐싱이 부담이 더 적다. 좋아요를 커서 값에 반영할 수 없으므로, 유동적인 좋아요 값을 정렬 기준으로 사용하기 위해서는 캐싱 방식을 사용하는 방법이 있다.

의문: Sorted Set을 사용해서 데이터를 보관하면 정렬이 되어있는 고정 값을 사용하기 때문에 이를 활용해 페이징을 해도 되는 것이 아닌가 의문이 들었음.

(즉, api 호출이 있을 때마다 좋아요를 기준으로 새로 정렬하는 것이 아니기 때문에, 매번 새로운 데이터를 한꺼번에 줄 필요가 없습니다.)

-> 10분마다 캐싱된 데이터가 바뀌기 때문에 페이징을 사용할 수 없음.

결론

• 10분마다 node-schedule을 이용 

1. score == 0 : "all"을 key 값으로 해서 전체 게시글 중 좋아요가 많은 top 150개를 Redis에 Sorted Set 자료구조로 저장.
2. score != 0 : 전체 category를 각각 key 값으로 해서 해당 카테고리의 게시글들 중 좋아요가 많은 top 150개를 Redis에 Sorted Set 자료구조로 저장.

      자료구조 : 

// key: category
// member: {contentId, photoCount, url}
// score: likeCount

 

• 추천 게시물 api가 호출되면

1. score == 0 : "all" 의 member 전달하기
2. score != 0 : 해당 카테고리의 member 전달하기