📄 설명
현재 '인기 피드 조회' 기능은 데이터베이스에 직접 ORDER BY like_count DESC 쿼리를 실행하여 결과를 반환하고 있습니다.
이후 피드와 '좋아요' 데이터가 증가함에 따라 DB의 정렬 연산에 대한 부하가 가중되어 성능 저하로 이어질 수 있습니다.
데이터베이스의 정렬 부하를 제거하기 위해, Redis의 In-Memory 자료구조인 Sorted Set을 도입하여 인기 피드 조회를 구현하고자 합니다.
현재 동작 및 문제점
-
현재 동작
- 인기 피드 API 요청 시, FeedRepository를 통해 like_count를 기준으로 내림차순 정렬하는 DB 쿼리가 실행됩니다.
- 모든 정렬 및 페이징 처리를 매 요청마다 실시간으로 데이터베이스가 담당합니다.
-
문제점
- 데이터베이스 부하 가중
- '인기 피드'는 조회가 매우 빈번한 핵심 기능이므로, 매 요청마다 실행되는 무거운 정렬 쿼리는 DB에 직접적인 부하를 줍니다.
- 느린 응답 속도
- 전체 피드 수가 증가할수록 ORDER BY 연산 시간은 비선형적으로 길어지며, 이는 API 평균 응답 시간 저하로 직결됩니다.
고민해볼 점
- 캐시 관리 정책
- 피드가 삭제될 때, Redis 랭킹에서도 해당 피드를 안정적으로 제거할 수 있는가?
- 랭킹 데이터의 만료 시간(TTL) 설정
📄 설명
현재 '인기 피드 조회' 기능은 데이터베이스에 직접
ORDER BY like_count DESC쿼리를 실행하여 결과를 반환하고 있습니다.이후 피드와 '좋아요' 데이터가 증가함에 따라 DB의 정렬 연산에 대한 부하가 가중되어 성능 저하로 이어질 수 있습니다.
데이터베이스의 정렬 부하를 제거하기 위해, Redis의 In-Memory 자료구조인 Sorted Set을 도입하여 인기 피드 조회를 구현하고자 합니다.
현재 동작 및 문제점
현재 동작
문제점
고민해볼 점