[Redis] Redis 란

가장 좋은건 원문을 보는 것이다. 

https://redis.io/topics/introduction

Introduction to Redis – Redis

 

Redis의 핵심

 

1. In-Memory data structure store : 메모리에서 데이터 구조(자료구조)를 저장하는 소프트웨어

2. 주로 데이터베이스, 캐시, 메시지 브로커로 사용된다. 

3. BSD 라이센스의 오픈 소스이다. ( *참고 : https://ko.wikipedia.org/wiki/BSD_%ED%97%88%EA%B0%80%EC%84%9C )

 

지원하는 자료 구조 

 

1. String

2. Set

3. Hash

4. Sorted Set (Range 쿼리 포함)

5. List

6. Bitmap

7. Hyerloglogs ( 정의 : 매우 적은 메모리로 집합의 원소 개수를 추정할 수 있는 방법, *참고 : https://d2.naver.com/helloworld/711301 , 잘 모르겠다.)

8. Geospatial indexes with radius queries and streams 

  -  8번의 경우, 4번의 Range 쿼리와는 개념은 같지만 성질이 다르다. 반경 쿼리(radius query)라는 말은 데이터 군집을 조회한다는 개념일 것이다. 완전히 이해하고 사용하려면 군집 조회의 바탕이 되는 N 차원 데이터 분포를 이해해야 할 필요가 있어보인다. 학부생이었을 때 볼 수 있는 가장 유사한 구현 로직으로는 알고리즘 수업이나 데이터 마이닝 수업에서 자주 나오는 K-means, K-mid(맞나?) 알고리즘과 같은 데이터 군집 및 센트로이드(기준점) 생성을 하는 알고리즘들이 있을 것이다. 근데 정작 캐시, 메시지 브로커로 사용될 때는 쓸모없어 보인다. (그리고 그런 거 공부할 거면 대학원 갔어야지...)

 

기능

1. Persistence

DataSet을 Disk로 Dumping하거나, 각 command를 log로 저장하여 데이터가 유지될 수 있도록 한다. 

In-memory의 데이터 휘발성(기기의 물리적 종료 시 데이터가 사라지는 현상)을 막아준다.

 

Snapshot : Dumping 방식이다. DB 파일 자체의 복사본을 만들어 Disk에 저장하는 방식이다. 

  -  save 명령 : Blocking 방식. 실행 시, Redis를 블록시켜 데이터 관리를 못하게 막은 후 실행된다. 

  -  [Redis 권고 명령어] bgsave 명령 : background save의 줄임말. Non-Blocking 방식. 자식 프로세스를 생성 후 백그라운드에서 스냅샷을 생성한다. 

  -  Snapshot은 재실행 시 그대로 불러와서 저장하면 되지만, 저장된 시점만의 데이터가 복구되기 때문에 저장 시점 이후의 데이터는 복구하지 못한다.

 

AOF : Append Only File의 줄임말. 간단하게 말하면 RDB의 Transaction log를 저장하는 방식. Redis의 write/update command log를 기록한다. 서버가 재시작될 때, 순차적으로 재실행하여 데이터를 복구한다. 

  -  AOF의 경우 모든 시점에 대한 데이터를 복구할 수 있지만, 재실행할 때 마다 데이터 입력/수정 로그를 실행하여 복구하기 때문에 복구 시간이 느려진다. 

 

Redis의 Persistence 규격은 [주기적인 Snapshot 생성(default 15분) + Snapshot 생성 시점 이후의 발생 데이터는 AOF로 저장]이다. 

2. Master-Slave Asyncronous replication

(주) 데이터 베이스 - (부) 데이터 베이스로 비동기 복제가 가능하다. 

HA(High Availability - 장기간동안 지속적 운영이 가능함을 의미)를 가능하게 한다. 

3. Transaction

RDB를 공부하다보면 Transaction log의 commit 시점을 따라 과거 시점으로 복구시킬 수 있다는 것을 알 것이다. 1번의 command를 log로 저장한다는 것이 transaction log와 동일한 역할을 하는 log를 저장한다는 의미이다. 

4. pub/sub

Publish/Subscript 구독형 사용이 가능하다. Messaging 구조가 가능하다는 의미로, 메시지 브로커로서 사용될 때 사용하는 기능으로 보인다. 

5. Lua scripting

루아 스크립트를 사용하여 Redis의 직접 디버깅이 가능하다.

6. Keys with a limited time-to-live

만료 시간을 설정할 수 있다. 캐시로 사용할 때, 시간이 지나면 의미가 없어지는 데이터의 경우 만료시간을 설정하여 최신화를 시켜줄 수 있다. 실무에서도 자주 사용하는 방법이다. 

7. LRU eviction of keys

캐시로 사용할 때 신규 데이터의 유입을 위해 과거 데이터 삭제 방법을 기본 설정으로 두게 되면, LRU(Least Frequently Used 가장 적게 사용된 데이터를 축출하는 알고리즘) 방식으로 삭제한다. 이런식으로 쓸 거 아니면 서버 로직에서 주기적으로 갱신을 시켜주든지 하면 되는거라 딱히 쓸모는 없어보인다. 되려 캐시 데이터는 의도적으로 갱신/수정하는 경우가 대부분이라서 그런가보다 하면 될 것 같다. 

8. Automatic failover

Redis의 Clustering을 사용한 기능 중 하나이다. 분산 Redis 서버 하나가 죽으면, 하위이 Slave를 Master로 승격시켜 기능이 정지하는 것을 방지한다. 

Redis Cluster HA에 더하여 Sharding을 지원한다. (Sentinel과는 완전히 다른 형태의 솔루션이라고 한다.)

DataSet을 여러 node에 나누어 저장을 시키고(Sharding), 자체적인 프로토콜(protocol)을 통해 node to node로 통신을 한다.

ex) RDB로 예를 들면, 하나의 테이블을 index를 기준으로 A인덱스 구간과 B인덱스 구간을 따로 저장하고 각 구간을 node로 연결한다.

각 node는 N대의 인스턴스로 구성이 가능하며, 1대의 Master와 N-1대의 Slave로 구성된다. 

참고 

* Redis의 개발단계에서 Linux와 OS X를 주 대상으로 테스트가 진행되고, 권장 실행 환경은 Linux이다. 

* 웹 서버 개발시에는 Redis를 성능 향상을 위한 캐싱으로 사용하는 경우가 많다. 

* 웹 서버의 경우에 그렇다는 것이지, 채팅 서버와 같은 실시간 서버의 경우 메인 DB로 사용할 수도 있다. Disk 조회 시간보다 메모리 조회 시간이 훨씬 빠르면서, 데이터 영속성(Persistence)가 보장되기 때문에 가능하다.