리더보드
리더보드 기능이란 실시간 랭킹을 보여주는 기능
게임이라면 점수 순위, 검색 엔진이면 실시간 검색 순위, 그리고 이커머스 분야라면 인기상품과 같은 기능들을 보여주기 위해 사용
In RDBMS
이커머스를 기준으로 생각을 해보면, 인기의 기준을 가장 많이 구매한 물품으로 생각해볼 수 있다. 가장 많이 구입된 물품을 반환하는 기능을 만든다고 가정하면, 가장 많은 주문이 있는 물품을 구하려면 복잡한 Join과 함께, SUM , COUNT 등의 집계함수가 필요
- 이를 피하기 위해 물품 테이블에 구매횟수 컬럼을 추가한다 해도, 결국 해당 칼럼을 빈번하게 수정
- 데이터를 조회하는 과정에서 정렬이 필요하기 때문에 성능 저하
Sorted Set
- 데이터를 추가하는
ZADD의 시간복잡도가O(log(N)) - M개의 데이터를 조회하기 위한
ZRANGE의 시간복잡도가O(log(N) + M)
캐싱
Redis가 많이 활용되는 또다른 주제는 캐싱(Caching)으로 자주 사용되는 데이터를 더 빠른 캐시(Cache)에 저장하는 기법
캐시
Cache는 본래 CPU 내부의 작은 영역으로, 정말 빈번히 접근하게 되는 데이터를 저장해두는 임시 기억 장치
기본적으로 영속성을 위해 파일시스템(디스크)에 저장하고, 빠른 활용을 위해 메모리(RAM)에 저장한다면, 정말 많이 사용되는 휘발성 데이터가 캐시에 저장
웹 개발자가 직접적으로 다루는 부분은 아니지만, 캐시의 목적과 방식을 웹 개발에 적용해, 빈번하게 접근하게 되는 데이터베이스의 데이터를 Redis 등의 인메모리 데이터베이스에 저장을 함으로서 데이터를 조회하는데 걸리는 시간과 자원을 감소시키는 기술을 캐싱
웹 브라우저에서는 자주 바뀌지 않는 이미지 등을 브라우저 캐시에 저장해 페이지 로드를 줄이는 것도 캐싱의 일종이며, 이는 RESTful 설계 원칙 중에서 응답이 캐싱이 가능한지 명시해야 한다는 제약사항으로도 나타
캐싱 전략
기본적으로 캐시는 본래 저장된 곳이 아닌 다른곳에 데이터를 저장하는 행위
언제든 사라질 수 있는 데이터가 있는 곳이며, 너무 크지 않게 관리
캐시를 확인했을때 자신이 필요한 데이터가 있을 수도, 없을 수도 있다는 것을 고려
캐시를 구현하고 사용할때는 해당 데이터가 얼마나 자주 사용될 것인가를 고려
- 캐시 적중(Cache Hit): 캐시에 접근했을 때 찾고 있는 데이터가 있는 경우
- 캐시 누락(Cache Miss): 캐시에 접근했을 때 찾고 있는 데이터가 없는 경우
- 삭제 정책(Eviction Policy): 캐시에 공간이 부족할때 어떻게 공간을 확보하는지에 대한 정책
전략을 잘 새워, 적중률을 높이고 누락을 최대한 줄인다.
Cache-Aside
Lazy Loading이라고도 하며, 데이터를 조회할 때 항상 캐시를 먼저 확인하는 전략
- 캐시에 데이터가 있으면 캐시에서 데이터를, 없으면 원본에서 데이터를 가져온 뒤 캐시에 저장
- 필요한 데이터만 캐시에 보관
- 최초로 조회할 때 캐시를 확인하기 때문에 최초의 요청은 상대적으로 오래 걸림
- 반드시 원본을 확인하지 않기 때문에, 데이터가 최신이라는 보장이 없다
Write-Through
데이터를 작성할때 항상 캐시에 작성하고, 원본에도 작성하는 전략
- 캐시의 데이터 상태는 항상 최신 데이터임이 보장됩니다.
- 자주 사용하지 않는 데이터도 캐시에 중복해서 작성하기 때문에, 시간이 오래 걸립니다.
Write-Behind
캐시에만 데이터를 작성하고, 일정 주기로 원본을 갱신하는 방식
- 쓰기가 잦은 상황에 데이터베이스의 부하를 줄일 수 있다.
- 캐시의 데이터가 원본에 적용되기 전 문제가 발생하면 데이터 소실의 위험성이 존재
