-
[Redis] Redis에 대하여Backend 2024. 1. 3. 00:49
🤔 Redis 란?
- Remote dictionary server (외부에 있는 dictionary라는 자료구조를 사용하는 서버)
- RDBMS와 같이 쿼리 연산을 지원하지 않음
- 인메모리 데이터베이스
- 빠른 속도
- Key-Value 타입의 저장소
- NoSQL로 분류됨
- Remote Data Storage로 여러 서버에서 같은 데이터를 공유하고 보고 싶을 때 사용할 수 있음
- 쓰기 성능 증대를 위한 클라이언트 측 샤딩을 지원함
- Sharding이란?
- 같은 테이블 스키마를 가진 데이터를 다수의 데이터베이스에 분산하여 저장하는 방법
- Sharding이란?
- 스냅샷 기능을 제공하여 메모리 내용을 *.rdb 파일로 저장하여 해당 시점으로 복구 가능
- 다양한 자료구조를 가지고 있음
- Hash
- List
- Set
- String
- Bitmap
- etc..
🪡 Redis에 저장해야 하는 데이터
많이 접근하고 비교적 자주 바뀌지 않는 데이터를 저장해야 한다.
👔 하나의 서버에서 Redis를 사용하면 좋은 경우
- 캐싱
- 세션 관리
🐡 캐시란?
- 데이터나 정보를 빠르게 액세스하고 처리하기 위해 저장하는 임시 메모리
- 주로 빈번하게 사용되는 데이터나 프로그램을 저장해 두어 해당 데이터에 접근할 때 더 빠르게 사용할 수 있게 해줌
Look aside Cache 패턴
- 일반적인 캐시 구현 패턴
- 쿼리 순서
- 클라이언트에서 데이터 요청
- 서버에서 캐시에 데이터 존재 유무 확인
- 데이터가 있다면 캐시의 데이터 사용
- 데이터가 없다면 실제 DB 데이터에 접근
- 그리고 DB에서 가져 온 데이터를 캐시에 저장하고 클라이언트에 반환
Write Back 패턴
- 쓰기 작업이 굉장히 많아서, INSERT 쿼리를 일일이 날리지 않고, 한꺼번에 배치 처리하기 위해 사용
- 한꺼번에 많은 INSERT 가 필요한 요청이 들어옴 -> 캐시 메모리에 데이터 저장 -> 이후 DB 디스크에 업데이트
- DB에 저장하기 전에 캐시 서버가 죽으면 데이터 유실된다는 문제점이 존재
- 사용 예
- 로그 저장 (로그를 캐시에 저장 -> 특정 시점에 DB에 한 번에 저장)
- 쿼리 순서
- 모든 데이터를 캐시에 저장
- 캐시의 데이터를 일정 주기마다 DB에 한꺼번에 저장
- 저장한 데이터는 캐시에서 제거
🐙 주의해야 할 점
Single Thread 서버이므로 시간 복잡도를 고려해야 함
- 빠르게 처리해야 하므로 O(N)인 연산은 주의해야 함
- keys, flush, getAll 등
메모리 파편화
- 메모리를 할당 받고 해제하는 과정에서 사이사이에 빈 공간이 발생하게 됨
- 이때, 4 크기의 프로세스를 할당하고 싶은데 사이사이의 빈 공간들의 크기가 4보다 작을 경우, 마지막 부분에 프로세스가 할당되어야 함
- 이러한 현상이 지속된다면 프로세스가 할당될 공간이 없어져 프로세스가 죽는 현상이 발생할 수 있음
- 메모리를 여유있게 사용하는 것이 좋음
트위터에서 초당 30만 건 이상의 타임라인 요청을 처리하기 위해 Redis를 사용했다는 점이 놀라웠다. 특히나 기존 방식의 쿼리는 누가 보아도 복잡했지만, Redis를 사용했을 경우, 사용자의 타임라인 데이터를 Redis에 저장해 두었다가 사용자의 아이디를 통해 데이터를 가져옴으로써 훨씬 단순한 쿼리를 만들었다는 점에서 아직 배워야 할 것이 많다고 느껴졌다..
- 참고
http://redisgate.kr/redis/configuration/redis_conf_list.php (해당 사이트의 모든 내용을 읽어봐야 겠다..)
https://www.youtube.com/watch?v=Gimv7hroM8A
https://inpa.tistory.com/category/DBMS/Redis
'Backend' 카테고리의 다른 글
[Redis] Redis 이용하기 (0) 2024.01.15