cache
1. Look aside Cache
- 웹서버는 데이터가 존재하는지 캐시를 먼저 확인
- 캐시에 데이터가 있으면 캐시에서 가져온다.
- 캐시에 데이터가 없으면 데이터베이스에서 가져온다.
- 데이터베이스에서 가져온 데이터를 캐시에 다시 저장한다.
2. Write back
- 웹서버는 모든 데이터를 캐시에만 저장
- 캐시에 특정 시간동안의 데이터가 저장한다
- 캐시에 있는 데이터를 데이터베이스에 저장한다.
- 데이터베이스에 저장된 데이터를 삭제한다.
장애가 생기면 데이터가 날라가 유실될 위험이 있다.
캐싱에 적합한 데이터
- 반복적이고 동일한 결과가 나오는 기능의 반환값
- 업데이트가 자주 발생하지 않는 데이터
- 자주 조회되는 데이터
Redis
Redis는 Remote Dictionary Server의 약자로 key-value 기반의 인메모리 데이터 저장소다. key-value 기반이기 때문에 쿼리를 처리할 필요없이 결과를 바로 가져올 수 있다. 또한, 디스크에 데이터를 쓰는 구조가 아니라 메모리에서 데이터를 처리하기 때문에 속도가 빠르다.
기본적으로 데이터를 하드디스크(SSD)에 저장한다. 하드디스크는 용량이 크고 전원이 꺼져도 데이터가 유지되지만 속도가 느리다. 기술이 발달하면서 메인 메모리에 데이터를 저장해 쉽고 빠르게 접근할 수 있지 않을까하는 생각에 생긴 개념이 Redis이다.
Database보다 더 빠른 메모리에 더 자주 접근하고 덜 자주 바뀌는 데이터를 저장하자!
사용처
Remote Data Store
- 여러 개의 서버에서 데이터를 공유하고 싶을 때
- 싱글 스레드라 Atomic을 보장해 준다 주로 많이 쓰는 곳들
- 인증 토큰 등을 저장(String 또는 hash)
- 랭킹 보드로 사용(Sorted Set)
- 유저API Limit
- 잡 큐 (list)
Redis의 데이터 구조 - collections
아래는 values에 올 수 있는 데이터 타입들이다.
1. Strings
문자열로 단순한 key-value 매핑 구조가 된다.
- Key를 어떻게 정할지 고민해야 함
- Set
- Set token 12345567
2. Lists
Linked List와 같은 형태로 Array형식이다.
3. Sets
중복과 순서가 없는 String 데이터 집합이다.
- 데이터 유무만 체크하는 용도
- SISMEMBER
- 팔로우 목록
4. Sorted Sets
set과 비슷하지만 key, value, score까지 저장하고 이 score값을 통해 정렬한다.
- ZRANGE
- score는 double타입이므로 값이 정확하지 않을 수 있다.
- 유저 랭킹보드
5. Hashes
field-value 쌍의 hash 형태로 저장한다. key의 field 개수에 제한이 없다. key-value 구조를 여러 개 가진 object 타입을 저장할 때 편리하다.
- Key 밑에 sub key가 존재
주의사항
- 하나의 컬렉션에 너무 많은 아이템을 담으면 좋지 않다 (10000개 이하로 유지하는 것을 권장)
- Expire는 컬렉션의 아이템 개별로 걸리지 않고 전체 컬렉션에 대해서만 걸림
Redis 운영
메모리 관리를 잘하자
- Physical memory 이상을 사용하면 문제가 발생한다. swap이 있다면 swap 사용으로 해당 메모리 page 접근 시마다 늦어짐
- 큰 메모리를 사용하는 인스턴스 하나보다 적은 메모리를 사용하는 인스턴스 여러개가 안전하다
O(N) 관련 명령어를 조심하자
Redis 관리
Redis는 싱글 스레드이기 때문에 한 번에 하나의 명령을 실행하는 특징이 있다. Redis의 자료구조는 Atomic Critical Section에 대한 동기화를 제공하기 때문에 여러 트랜잭션의 Read와 Write를 오류없이 실행할 수 있다. 대신 싱글 스레드 서버라 시간 복잡도를 고려해야 하고 Redis를 효율적으로 다루기 위해서 OS와 메모리에 대한 배경지식이 필요하다.
여러 서버에서 같은 데이터를 공유할 때나 Atomic 자료구조 , Cache 기능을 사용하기 위해 Redis를 선택한다.