레디스를 쓰면 좋다, 빠르다 하는 말을 수없이 들었지만 어떤 점 때문에 그런건지나 어떤 식으로 활용되는지는 알지 못했다. 왜 쓰는지는 알아두고 시용하기 위해 레디스의 이점과 활용 사례를 알아보았다.
레디스의 특징
레디스는 키-값 저장소 방식의 No-SQL 데이터베이스이다. 즉 쿼리를 사용하지 않고, 키를 기반으로 데이터를 가져온다.
- MySQL에서 데이터를 저장 :
INSERT INTO users (id, name) VALUES (1, 'Alice');
- Redis에서 데이터를 저장 :
SET key value
⇒ SET user:1 “Alice” - MySQL에서 데이터를 조회 :
SELECT name FROM users WHERE id = 1;
- Redis에서 데이터를 조회 :
GET key
⇒ GET user:1
레디스의 이점
- 레디스는 RDBMS에 비해 속도가 빠르다 데이터를 메모리(RAM)에 저장해서 조회 속도가 매우 빠르다. RDBMS는 디스크를 주로 사용하기 때문에 레디스만큼 빠르지 않다.
- 레디스는 기본 키-값 외에도 다양한 데이터 구조를 지원한다.
- String: 기본적인 텍스트나 숫자 값을 저장.예:
SET key "value"
- Hash: 필드와 값을 가진 데이터.예:
HSET user:1 name "Alice" age 25
- List: 순서가 있는 리스트.예:
LPUSH tasks "task1"
- Set: 중복 없는 집합.예:
SADD tags "tag1"
- Sorted Set: 순위와 값을 가진 집합.예:
ZADD scores 100 "Alice"
- String: 기본적인 텍스트나 숫자 값을 저장.예:
- 캐시로 사용하기 좋다 데이터가 메모리에 올라가 있기 때문에 캐시로 사용하기 좋다. 자주 조회되는 데이터를 캐싱해두면 RDBMS에서 데이터를 매번 읽어오는 비용을 줄일 수 있다.
-
만료 시간을 설정할 수 있다
데이터에 만료 시간을 설정할 수 있다. 예:
SETEX session:1234 3600 "data"
→ 3600초(1시간) 후 자동 삭제. -
분산 시스템에 유리하다
분산 환경에서 쉽게 확장이 가능해서, 대규모 트래픽을 처리할 때 유용하다. (이 부분은 아직 실제로 경험해보지 못해서 추후 프로젝트에 적용하며 확인해야 할 것 같다. ) 레
레디스 활용 사례
빠르고, 캐싱 처리도 가능해서 좋다는 건 알겠는데 주로 언제 사용하면 될 지 와닿지 않아서 활용 사례(출처 : https://meetup.nhncloud.com/posts/225 )를 찾아보았다.
- 사례 1 : 좋아요 처리하기
RDBMS에서 특정 게시물의 댓글에 사용자가 좋아요 처리를 하거나, 취소하게 구현한다고 생각해보자. 구현을 할 수는 있지만 insert와 update가 매우 빈번하게 발생하므로 규모가 큰 SNS라면 성능 저하가 발생할 수 있다.
이 때 레디스의 Set을 이용하면 간단하고 빠르게 처리가 가능하다.
⇒
Key : 댓글의 번호, Value : 좋아요를 누른 회원 ID
- 사례 2 : 일일 방문자 수 구하기
사용자가 서비스에 방문할 때, 사용자 ID에 해당하는 bit를 1로 설정한다. 1개의 bit가 1명을 의미하므로 천만 명의 유저는 천만 개의 bit로 표현 할 수 있고, 이는 곧 1.2MB 정도의 크기이다(레디스 string의 최대 길이는 512MB. 레디스 4.0.7 이후로는 최대 크기를 변경 할 수 있게 되었다).
즉, 천만 명의 회원이 있는 서비스라면 비트 천만개를 준비해놓고 각각의 회원이 방문할 때 비트를 0→1로 변경한 후, 이
문자열에서 1로 설정된 bit의 개수를 구하는 BitCount 연산
을 하면 간단하게 방문자 수를 구할 수 있다. -
사례 3 : 최근 검색한 키워드 5개 보여주기 이런 기능이 있다면, RDBMS에서는 이런 식으로 쿼리를 날려야 한다.
1
select * from KEYWORD where ID = 123 order by reg_date desc limit 5;
그리고 사용자 별로 저장된 데이터 개수를 확인하고, 중복된 데이터는 제거하고, 오래된 검색어는 삭제하고… 같은 부수적인 작업들이 필요하다. 이 때, 애초에 중복을 허용하지 않고 자동으로 정렬 되는 레디스의
sorted set
을 사용하면 간단하게 구현할 수 있다. - 사례 4 : Twitter 타임라인에서 레디스를 활용한 방식
2012년 트위터는 15만명 이상의 실시간 사용자와, 초당 30만건 이상의 타임라인 조회가 발생했다고 한다. 이 규모의 타임라인 요청을 DB에서 직접 처리하면 속도가 현저히 떨어진다. Twitter에서는 Redis Cluster를 통해 각 사용자의 타임라인에 노출될 트윗의 정보(Tweet ID, 작성자 ID)를 List 형태로 약 800개 정도 캐싱했다. 새로 발생한 타임라인 요청은 DB에 바로 접근하지 않고, Redis에 캐싱되어 있는 타임라인 정보를 먼저 가져와서 이를 토대로 DB에 접근하여 처리했다고 한다.
1 |
|