[실전 레디스] 1. 레디스의 시작

하야시 쇼고 님의 "실전 레디스" 책을 정리한 포스팅 입니다.

 

1. NoSQL

구분	내용
특징	- 빠른 속도 - 특정 데이터 모델에 최적화됨 (일부 데이터 모델은 RDBMS로 구현 시 복잡)
유형	- Key-Value Store - Column-Oriented DB - Document-Oriented DB - Graph DB

 

예시) GraphDB - 소셜 네트워크

연결 정보 저장

• 예: A는 B의 친구이고, B는 C의 친구이고, C는 A의 친구다

 

GraphDB(Neo4j)

• 각 사람을 노드, 친구 관계를 엣지로 표현 (MATCH (a)-[:FRIEND]-(b)-[:FRIEND]-(c))
• 관계 중심 모델에 최적화

 

RDBMS

• Join 반복이나 재귀 쿼리를 써야 함 → 느리고 복잡함

 

예시) Document-Oriented DB - 이용자 맞춤 설정 데이터

사용자마다 설정 정보가 다름

• 예: A는 알림 설정만, B는 테마 설정만, C는 둘 다 + 프로필 설정까지

 

Document DB(MongoDB)

• 각 사용자의 설정을 JSON 문서처럼 저장
• → 구조가 자유롭고 사용자가 다르게 설정해도 문제 없음

 

RDBMS

• 미리 모든 컬럼을 만들어야 함
• 대부분의 칼럼이 NULL일 수 있음 → 메모리 비효율적

 

2. Redis

구분	내용
라이선스	BSD 라이선스
작성 언어	ANSI C
유형	- NoSQL Database - In-Memory Data Storage

 

특징

특징	설명	특징
인메모리 데이터베이스	데이터를 메모리에 저장	빠른 처리 속도
메모리 사용량 최소화	자료구조 단순화 및 최적화	적은 메모리로 많은 데이터를 처리할 수 있음
빠른 응답 속도	지연 시간 짧음	실시간 통신 애플리케이션에 적합 (게임, 채팅, 알림 등)
다양한 자료형 지원	String, List, Hash, Set, Sorted Set 등	구조화된 데이터 관리 쉬움
낮은 의존성	외부 라이브러리 없이 독립적으로 동작함	외부 버그 발생 위험 없음

 

기능

기능	설명	특징
Pub/Sub	Publish-Subscribe 메시지 모델 지원	- 메시지 브로커 역할 담당 - 채널을 통해 메시지 통신
Lua Script	여러 Redis 명령을 하나의 원자적 작업으로 실행	- 복잡한 로직을 서버에서 직접 처리 - RDBMS의 스토어드 프로시저와 유사한 기능
Transaction	여러 Redis 명령을 하나의 트랜잭션으로 묶어 실행	- MULTI, EXEC, WATCH 명령 사용 - 명령은 순차적으로 실행됨 - 중간 실패 시 전체 롤백 불가
TTL(Time-To-Live)	키에 만료 시간을 설정하면, 만료 시 자동으로 삭제됨	- EXPIRE, TTL 명령 사용 - 캐시 데이터 관리에 유용
Replication & Cluster	복제 및 수평 확장을 위한 클러스터 기능	대규모 서비스에서도 안정적인 운영 가능

 

예제) Transaction

하나의 명령어처럼 묶어 실행

MULTI
INCR user:1000:balance
DECR user:1000:points
EXEC

 

한계

제약 사항	설명
롤백 불가	트랜잭션(MULTI/EXEC) 중 일부 명령이 실패하더라도 전체 롤백되지 않음
예외 처리 불가	트랜잭션 내부에서 예외 발생 시 해당 명령만 실패하며, 전체 트랜잭션은 중단되지 않음
일관성 약함	복제 지연 또는 클러스터 환경에서의 분산 처리로 인해 데이터 일시 불일치 가능

 

싱글스레드

• 동시성 문제 방지

기능	설명	특징
이벤트 기반 처리	클라이언트 요청을 하나의 이벤트로 인식
이벤트 루프 형성	- 내부적으로 이벤트 루프라는 반복 구조를 가짐 - 이벤트 감지 및 순차 처리	간단하고 빠르게 동작함
고유 이벤트 라이브러리	ae(Async Event) 라이브러리를 사용하여 이벤트 관리
CPU 병목 방지	- 부분적 멀티스레드 지원 - 비동기 처리 지원	- 일부 명령어에서 멀티스레딩을 활용 (RDB 저장 등) - ASYNC 옵션 제공 (UNLINK, FLUSHDB 등)

 

영속성

특징	설명
RDB 스냅샷	일정 시간 간격으로 메모리 데이터를 디스크에 저장	백업 기능
AOF (Append-Only File)	모든 변경 사항을 로그 형태로 저장	장애 복구 가능

 

3. vs RDBMS

비교 항목	RDBMS	Redis
스키마	테이블을 만들 때 스키마 정의 필요	- key-value 형태 - 스키마 없이 유연한 데이터 저장 가능
데이터 일관성	✅ 트랜잭션, 제약 조건을 통해 유지	❌ 트랜잭션 미흡. 제약 조건 없음
데이터 변경	❌ 데이터 모델 변경이 어렵고 비용이 큼	✅ 데이터 모델 변경이 자유로움
트랜잭션 (ACID)	✅ ACID 보장	❌ Atomic 미흡: Rollback 불가 ❌ Isolation 미흡: 다른 클라이언트와 간섭 가능 ❌ Durability 미보장: 디스크 기록 전에 장애 나면 유실
일관성 요구사항	엄격한 일관성이 필요한 경우 적합	일시적인 불일치 허용 가능한 시스템에 적합
주요 사용 사례	금융 시스템, ERP, CRM 등 (정확한 데이터 관리)	캐싱, 실시간 분석, 메시지 큐 등 (빠른 응답)

 

RDBMS와 조합

• RDBMS에서 보관하는 데이터양이 많아지면 여러 문제가 발생할 수 있음
  • 성능이 떨어짐 → 인덱스 설정 및 쿼리 튜닝
  • 용량이 부족함 → 클러스터링으로 서버 대수 늘리기
  • → 문제 해결을 위해 여러 설계 및 관리 비용이 부과됨
• 레디스를 캐시로 활용하여 서비스 성능을 높일 수 있음
  
  • 특히 조인한 결과가 여러번 사용되는 경우 유용함

 

예제) 서비스 흐름

Cache - Aside 패턴

1. 클라이언트: 웹 페이지 열람
2. 서버: 레디스에 질의
   • 레디스에 데이터 있으면 → 클라이언트에 바로 응답
   • 레디스에 데이터 없으면 → RDBMS에 데이터 질의 → 조회 결과를 Redis에 캐싱 → 응답

 

4. vs Memcached

비교 항목	Redis	Memcached
주 용도	데이터베이스, 캐시, 메시지 브로커 등	캐시 전용 (DB 보완)
데이터 유형	String, List, Set, Sorted Set, Hash 등 다양한 자료형 지원	String 자료형만 지원
데이터 영속성	데이터 저장 가능 (AOF, RDB 방식 지원)	휘발성 (데이터 저장 불가)
스냅샷 기능	RDB 스냅샷, Append Only File(AOF) 지원	없음
분산 처리	클러스터링 및 복제 기능 제공	기본적으로 단일 인스턴스
메모리 효율	메모리 최적화 가능 (LRU, LFU 정책 지원)	단순한 키-값 저장 방식으로 빠르지만 최적화 기능 부족
주요 사용 사례	세션 관리, 실시간 데이터 처리, 랭킹 시스템, 큐 시스템	DB 조회 결과 캐싱, 웹 페이지 캐싱