hmk run dev

Redis 레디스 본문

카테고리 없음

Redis 레디스

hmk run dev 2022. 2. 19. 15:22

Remote dictionary server

원격 + HashMap(Key - Value) + 서버

 

직관적으로 풀어보면 키와 밸류 값을 이용한 원격 서버라고 할 수 있다.

 

쿠팡이 모든 물품이 품절상태로 발생한 오류가 있었다고 하고 그 이유가 Redis 때문이라고 기사에 났던 적이 있다.

그 이유는 32bit CPU에서 Int의 최대값 때문이었다.

2147483647(이십일억사천칠백사십팔만삼천육백사십칠)

 

key값이 너무 많아져서... 에러가 발생했다.

 

그래서 Redis 패치 내용을 보면 

int > long으로 패치된 것을 볼 수 있다. 2,147,483,647 > 4,294,967,295

 

그래서 Redis가 뭘까?

 

Cache

 

나중의 요청에 대한 결과를 미리 저장했다가 빠르게 사용하는 것

 

어디에 저장해야 빠를까?

메모리는 위처럼 계층 구조로 되어있고 위로 갈수록 빠르고 비싸고 밑으로 갈수록 느리고 싸다

 

쉽게 이해할 수 있도록 노트북을 예로 들어보자

맥북이 있고 이 맥북의 스펙은 아래와 같다.i7 CPU - 12MB Cache Memory  - Cache > 겁나 빠름, 비쌈, 작음 DB로 사용하기엔 작다.

 

16GB DRAM- Main Memory or RAM > 적당히 빠름, 비쌈, 큼, 휘발성 > 컴퓨터가 꺼지면 전부 날아감

 

512GB SSD- Hard Disk(Storage) > 비교적 느림, 저렴, 큼, 비휘발성 > 데이터 영원히 보관


기본적으로 데이터는 컴퓨터가 꺼지더라도 저장되어야 하기 때문에 Database (HDD, SSD)에 저장한다.

기술의 발전과 하드웨어의 발달로 인해 메인 메모리에 저장해 빠르고 쉽게 데이터에 접근이 가능해졌고

Database더 빠른 Memory에 더 자주 접근하고 덜 자주 바뀌는 데이터를 저장하기 위해

Redis가 자주 쓰인다. > In-memory Database(Cache)

 

Redis는 기본적으로 Single Threaded

자료 구는 Atomic Critical Section에 대한 동기화를 제공

서로 다른 Transacion Read/Write를 동기화를 함으로써 원치 않는 결과를 막아줌

 

Atomic Critical Section - 쉽게 말해... 여러 개의 프로세스가 동시에 접근하는 것을 방지


Redis는 어떤 경우 써야 할까?

 

운영 중인 웹 서버에서 키-값 형태의 데이터 타입을 처리해야 하고, I/O가 빈번히 발생해 다른 저장 방식을 사용하면 효율이 떨어지는 경우에 사용한다.

 

우리가 사용하는 서비스 중에 I/O가 가장 빈번한 서비스는 무엇일까?아무래도 유튜브 그중에서도 조회수 같은 데이터는 1시간에 100만 조회수를 넘길 정도로 엄청나게 빈번하게 업데이트될 것이다.

 

이때 MYSQL 같은 RDBMS를 사용한다면 순식간에 부하가 생길 수 있다.

 

이처럼 어마어마한 I/O 데이터를 처리할 땐 레디스를 이용해 데이터를 캐싱 처리하고, 일정한 주기에 따라 RDS에 업데이트를 한다면 RDS에 가해지는 부담을 크게 줄이고, 성능상 이점을 가져올 수 있습니다.

 

사용자의 세션 관리에서도 특화되어 있는데, 사용자의 세션을 유지하고, 불러오고, 여러 활동들을 추적하는데 매우 효과적입니다. 그리고 매우 빠르다는 점에서 메시지 큐잉에도 사용할 수 있습니다.


레디스의 데이터 구조

 

레디스는 RDBMS가 아님 VARCHAR, INT, DATETIME 등을 지원하지 않습니다.

리스트, 배열 형식의 데이터 처리에 특화됨 ( 리스트 형 데이터의 입력과 삭제가 MySQL보다 10배 정도 빠르다. )

value값으로 문자열, 리스트, set, sorted set, hash 등 여러 데이터 형식을 지원함.

 

1. String - 거의 대부분의 데이터를 문자열로 표현. 가령 숫자나 날짜 및 시간 등도 문자열로 저장

 

2. Hash - 해시는 필드를 가질 수 있습니다. 예를 들어 사용자 정보라는 해시가 있다면 유저 아이디, 이메일 등을 가질 수 있고 전체를 가져오거나 개별 필드를 가져올 수 있습니다.

 

3. List - Linked list로, 배열 왼쪽 or 오른쪽에 엘리먼트 추가가 가능하고 리스트 안의 데이터는 문자열만 가능

 

4. Set - 리스트와 유사하지만 고윳값만을 저장할 수 있고 Sorted Set 정렬을 통해 특정 기준 값에 들어온 데이터만 필터링하는 것이 가능합니다.


Redis의 스키마

 

레디스의 스키마는 데이터를 정규화하고, 데이터의 로우에 대해 일관된 레퍼런스를 가지게 해 줄 수 있게 해주는 용도로 존재합니다.

 

레디스는 key - value 스토리지 입니다.

 

예를 들어 사용자의 이메일, 닉네임, 최근 로그인 시간을 레디스에 저장한다고 가정해 봅시다.

 

- user:userId:email: 문자열

- user:userId:nickname: 문자열

- user:userId:lastLogin: 문자열

 

데이터를 : 로 구분해 접근이 가능한걸 유추할 수 있습니다.

이렇게 스키마를 활용하면 사용자의 userId값을 가지고 연결된 데이터 email, nickname, lastLogin도 알 수 있게 됩니다.


레디스의 키

 

RDBMS의 로우와 비슷하게 동작하지 않습니다.성능에 영향을 거의 주지 않으며 0(1)의 수행 시간을 가지고, 많은키(1,000,000,000,000개)건 단 1개의 키건 동일한 시간이 적용됩니다.


주의해야 할 점

 

Single Thread이므로 시간 복잡도를 고려해야 함in-memory 특성상 메모리 파편화, 가상 메모리 등의 이해가 필요하다.

 

한 번 생성한 키를 선택적으로 삭제하기 어려움한번 생성한 키는 영원히 쌓이는 건가?? 놀랍게도 그렇습니다. 특별한 조치 없이 레디스의 키는 삭제가 아닌 보관됩니다.

 

레디스의 키를 삭제하는 방법

 

1. 일괄삭제FLUSHDB 명령어를 통해 모든키를 파괴하며, 복구가 불가능

 

2. 일정 시간 이후 삭제 

각각의 키를 저장할 때 Set에 저장해 특정 시간이나 조건에 따라 삭제하는 방법.

실제로 삭제보단 밀어내기를 한다고 보일 수 있음

 

3. 기간만료 후 삭제

가장 많이 사용되는 방법

키를 추적할 필요도 없고, 쉽게 관리가능

이 방식을 사용할 땐 key-value 값을 SET 커맨드로 저장해 EXPIRE 커맨드로 기간 만료 시간을 정하는 방법을 주로 사용 

레디스 버전 2.0.0 이상을 사용할땐 SETEX( SET + EXPIRE) 커맨드를 사용하면 됩니다. 

 

 

 

 

출처

https://www.youtube.com/watch?v=Gimv7hroM8A 

 

출처

https://brunch.co.kr/@skykamja24/575

 

레디스(Redis)는 언제 어떻게 사용하는 게 좋을까

레디스를 사용해 본 적 없는 백엔드, 데이터베이스 개발자를 위해 | 레디스는 시스템 메모리를 사용하는 키-값 데이터 스토어입니다. 인메모리 상태에서 데이터를 처리함으로써 흔히 사용하는

brunch.co.kr

 

Comments