[DB] Redis vs MySQL

Redis를 공부할 때 ChatGPT와 한 대화를 정리한 글입니다.

 

 

Redis vs MySQL

1. 데이터 저장 방식

Redis

• 메모리(RAM)를 사용하여 데이터를 저장한다.
• 키-값(Key-Value) 형태의 데이터 구조를 주로 사용하며, Has, List, Set 등 다양한 자료구조를 지원한다.
• 휘발성(Volatile) 데이터베이스로, 서버가 재시작되면 데이터가 날아갈 수 있다. 하지만 지속성을 위해 디스크에 백업할 수 있다.
• 빠른 읽기/쓰기를 제공하지만, 메모리 용량에 한계가 있다.

 

MySQL

• 데이터를 디스크(파일 시스템)에 저장한다.
• 관계형 데이터베이스로, 테이블을 사용해 데이터를 체계적으로 저장하고 관리한다.
• 비휘발성(Non-Volatile) 데이터베이스로, 서버가 재시작되어도 데이터가 유지된다.
• 디스크 I/O로 인해 Redis보다는 읽기/쓰기 속도가 상대적으로 느리다.

 

 

2. 속도

Redis

• 메모리에서 작동하기 때문에 응답 속도가 매우 빠르다.
• 초당 수만 번 이상의 읽기/쓰기 작업이 가능하다.
• 데이터 접근이 빈번하고, 캐싱 또는 세션 관리처럼 빠른 성능이 필요한 경우에 유리하다.

 

MySQL

• 디스크 기반이기 때문에 Redis보다 속도가 느리다.
• 트랜잭션, 복잡한 쿼리, 대량의 데이터 처리가 필요할 때 적합하다.
• 인덱싱과 최적화로 성능을 높일 수 있지만, Redis만큼의 속도는 보장하지 않는다.

 

 

3. 데이터 구조와 활용

Redis

키-값 형태의 데이터 외에도 다양한 자료구조(Hash, List, Set, Sorted Set 등)를 지원한다.

 

활용 예시:

• 캐시: 자주 사용되는 데이터를 빠르게 제공
• 세션 저장소: 웹 애플리케이션의 사용자 세션 관리
• 순위표/리더보드: Sorted Set을 이용해 순위를 빠르게 처리
• 메시지 큐: 데이터 스트림이나 Pub/Sub 기능을 활용

 

MySQL

SQL을 이용하여 테이블 간의 관계를 정의하고 복잡한 쿼리를 수행할 수 있다.

 

활용 예시:

• 데이터 영구 저장소: 사용자 정보, 주문 기록, 게시물 관리
• 트랜잭션: 금융 서비스나 주문 처리에서 데이터 일관성을 유지
• 대량 데이터 분석: 복잡한 조인(Join)과 집계(Aggregation) 수행

 

 

4. 데이터 일관성

Redis

• 데이터 일관성보다는 속도와 유연성에 중점을 둔다.
• 특정 경우(데이터 손실 허용 범위)에서 성능을 우선시할 수 있다.

 

MySQL

• ACID 트랜잭션을 지원하며, 데이터의 일관성 및 무결성을 보장한다.
• 금융, 의료 등 데이터 정확성이 중요한 시스템에서 많이 사용된다.

 

 

5. 비용과 용량

Redis

• 데이터를 메모리에 저장하므로 비용이 높을 수 있다.
• 메모리(RAM) 용량에 따라 저장할 수 있는 데이터의 양이 제한된다.

 

MySQL

• 디스크에 데이터를 저장하기 때문에 대량의 데이터를 저장하는 데 비용이 저렴하다.
• 데이터를 많이 저장할 수 있으며 확장성이 뛰어나다.

 

 

6. 요약

항목	Redis	MySQL
저장소	메모리 (휘발성)	디스크 (비휘발성)
속도	매우 빠름	상대적으로 느림
데이터 구조	키-값, 다양한 자료구조	테이블과 관계형 데이터
활용 예시	캐시, 세션 관리, 메시지 큐 등	사용자 데이터, 트랜잭션, 분석
일관성	느슨한 일관성	강한 일관성 (ACID 지원)
비용	RAM 비용이 높음	저장 비용이 저렴

 

 

 

Redis는 메모리 기반으로 빠른 속도가 필요할 때 사용하고, MySQL은 영구 저장과 데이터 무결성이 중요한 경우에 사용한다. 두 시스템을 함께 사용하면 MySQL에서 데이터를 영구 저장하고, Redis에서 캐싱과 빠른 접근을 지원하는 하이브리드 아키텍처를 구성할 수도 있다.

 

MySQL과 Redis를 같이 사용하는 것은 매우 일반적이고 효율적인 아키텍처이다. 두 데이터베이스의 장점을 조합해서 시스템의 성능과 확장성을 크게 개선할 수 있다.

 

 

MySQL과 Redis를 같이 사용하는 이유

MySQL

• 데이터를 영구 저장하고 복잡한 관계형 쿼리를 처리한다.
• 데이터 무결성과 일관성을 보장한다.

 

Redis

• 캐시 역할을 하며, 자주 사용되는 데이터를 빠르게 읽고 쓴다.
• MySQL의 부하를 줄여서 성능을 최적화한다.

 

 

함께 사용하는 대표적인 방법

1. 캐싱 계층으로 Redis 사용

• 자주 사용되는 데이터를 Redis에 캐싱한다.
• 데이터 요청 시 다음과 같은 흐름으로 처리한다.
  1. Redis에서 데이터를 먼저 확인 (캐시 조회)
  2. Redis에 데이터가 없으면 MySQL에서 가져와서 Redis에 저장 (캐시 갱신)
  3. 이후 동일한 데이터 요청은 Redis에서 바로 반환

예시

• 사용자가 자주 보는 게시물 정보
• 로그인 세션 정보
• 인기 검색어, 순위표 등

 

2. 세션 관리

• 웹 애플리케이션에서 로그인 세션을 Redis에 저장하고 관리한다.
• Redis는 메모리 기반이기 때문에 세션 데이터를 빠르게 읽고 쓸 수 있다.

예시 흐름

• 사용자가 로그인하면 세션 정보를 Redis에 저장한다.
• 다음 요청에서는 Redis에서 세션 정보를 가져온다.
• 만약 세션이 만료되면 Redis에서 데이터를 삭제한다.

 

3. 실시간 데이터 처리

• Redis는 Pub/Sub 기능과 Sorted Set 같은 자료구조를 제공하기 때문에, 실시간 데이터나 이벤트 처리에 유리하다.
• MySQL은 여전히 데이터의 영구 저장을 담당한다.

예시

• 실시간 채팅: 메시지를 Redis를 통해 처리
• 리더보드: 점수를 Redis의 Sorted Set에 저장해서 순위를 빠르게 계산
• 알림 시스템: 이벤트를 Redis Pub/Sub으로 처리

 

4. 읽기 부하 분산

읽기 요청이 많은 서비스에서 Redis를 읽기 전용 캐시로 사용하면 MySQL의 부하를줄일 수 있다.

 

예시

• 쇼핑몰의 상품 조회 기능: 상품 정보는 MySQL에 저장되지만, 자주 조회되는 상품은 Redis에 캐시해 빠르게 제공

 

 

사용 예시 흐름 (Cache Aside 패턴)

아래는 MySQL과 Redis를 함께 사용하는 대표적인 캐시 패턴 중 하나인 Cache Aside 패턴의 흐름이다

1. 클라이언트 요청 -> Redis에 데이터 요청
2. Redis에 데이터가 있으면 -> Redis에서 바로 반환 (캐시 히트)
3. Redis에 데이터가 없으면 -> MySQL에서 데이터 조회 (캐시 미스)
4. MySQL에서 가져온 데이터를 Redis에 저장 (캐시 업데이트)
5. 이후 동일한 요청은 Redis에서 처리 

 

---

 

Redis는 휘발성(Volatile) 데이터베이스지만 데이터 지속성(Persistence)을 위해 디스크에 데이터를 백업하는 기능을 제공한다. Redis에서는 다음 두 가지 주요 방법을 통해 데이터를 백업하고 저장할 수 있다.

 

RDB vs AOF

1. RDB (Redis Database File) - 스냅샷 방식

RDB는 특정 시점의 데이터를 스냅샷(Snapshot)으로 저장하는 방식이다. Redis는 데이터를 주기적으로 디스크에 덤프하여 .rdb 파일로 저장한다.

 

작동 방식

• Redis는 메모리의 데이터를 바이너리 형태로 디스크에 저장한다.
• 설정된 주기 또는 조건에 따라 자동으로 스냅샷이 생성된다.
• 스냅샷 파일(dump.rdb)은 Redis 재시작 시 데이터를 복구하는 데 사용된다.

 

장점

• 빠른 백업과 복원: RDB 파일은 바이너리 형태라서 저장과 읽기가 빠르다
• 데이터 용량이 작다.
• 전체 백업이 가능하므로, 복구 시점을 특정 시점으로 고정할 수 있다.

 

단점

• 실시간 데이터 손실 가능성: 백업 주기 사이에 발생한 데이터는 저장되지 않을 수 있다.
• 데이터 변경이 빈번하면 RDB 파일을 자주 생성해야 하므로 시스템 리소스를 많이 소모할 수 있다.

 

 

2. AOF (Append-Only File) - 명령어 로그 방식

AOF는 Redis에서 수행된 모든 명령어를 로그 파일에 기록하여 백업하는 방식이다.

 

작동 방식

• 클라이언트가 Redis에 수행한 모든 쓰기 명령어(예: SET, HEST 등)를 순차적으로 파일에 기록한다.
• Redis가 재시작될 때 이 명령어를 다시 실행해서 데이터를 복구한다.

 

장점

• 데이터 손실 최소화: 설정에 따라 실시간으로 데이터를 백업할 수 있다.
• 더 높은 지속성: 모든 명령이 기록되기 때문에 RDB 방식보다 손실이 적다.

 

단점

• 파일 크기: 명령어가 계속 쌓이기 때문에 파일이 매우 커질 수 있다.
• 복구 속도: RDB보다 느리다. 파일에 기록된 명령어를 다시 실행해야 하기 때문이다.
• 성능 오버헤드: 실시간으로 모든 명령어를 기록하면 시스템 리소스가 소모된다.

 

 

RDB와 AOF 비교

특징	RDB	AOF
백업 방식	스냅샷 (전체 데이터 저장)	명령어 로그 (모든 변경 기록)
백업 주기	주기적으로 백업	실시간 또는 설정된 주기마다 백업
데이터 손실 가능성	있음 (백업 주기 사이 데이터 손실)	거의 없음 (실시간 설정 시 최소화)
복구 속도	빠름	느림 (명령어 재실행 필요)
파일 크기	작음	큼 (모든 명령이 기록됨)
성능 오버헤드	낮음	높음 (명령어 기록으로 인한 부하)

 

 

 

RDB와 AOF를 함께 사용하기

Redis는 RDB와 AOF를 동시에 사용할 수 있다.

• RDB: 주기적인 스냅샷으로 빠르게 복구 가능
• AOF: 실시간으로 명령어를 기록해 데이터 손실 최소화

 

Redis가 재시작될 때는 AOF 파일을 우선으로 복구한다. AOF 파일이 없으면 RDB 파일을 사용한다.