Brain465. 키-값 DB (Key-Value) - Redis 인메모리
⚠️ 이 문서는 복잡한 테이블 구조나 SQL 쿼리를 과감히 버리고, **오직 '이름표(Key)'와 '내용물(Value)'이라는 가장 단순한 구조를 통해 디스크가 아닌 메모리(RAM) 위에서 빛의 속도로 데이터를 읽고 쓰는 '키-값 기반 NoSQL'**을 다룹니다.
핵심 인사이트 (3줄 요약)
- 본질: 데이터베이스 세상의 딕셔너리(Dictionary)다. 복잡한 관계(JOIN)나 스키마 없이, 오직 하나의 유일한 키(Key)로만 데이터를 찾고 저장하는 가장 원초적인 NoSQL이다.
- 가치: 데이터 구조가 단순한 만큼 검색 속도가 $O(1)$로 압도적으로 빠르다. 특히 하드디스크가 아닌 메모리(In-Memory)에서 돌아갈 때 그 진가가 100% 발휘된다.
- 기술 체계: **Redis(레디스)**가 사실상 업계 표준이며, 웹 서버의 세션(Session) 저장소, 실시간 랭킹 보드, RDBMS 앞단의 캐시(Cache) 서버 용도로 모든 IT 기업에서 필수적으로 사용된다.
Ⅰ. 개요: 1억 번의 출석 부르기 (Context & Necessity)
"지금 접속 중인 유저의 세션(로그인 상태) 정보 가져와!"
RDBMS(MySQL)에게 이 심부름을 시키면 꽤 느리다.
- 디스크를 긁어야 하고, 테이블 락(Lock)을 검사해야 하고, SQL 문법을 파싱해야 한다.
- 한 명이면 괜찮지만, 1초에 10만 명이 동시에 로그인 상태를 확인하면 서버가 뻗어버린다.
이런 **'단순하고, 엄청 자주 찾고, 0.001초 만에 나와야 하는 데이터'**를 위해 탄생한 것이 Key-Value DB다.
그냥 메모리에 [Key: "user:123", Value: "로그인 됨"] 이라고 덜렁 던져두는 것이다. 복잡한 문법 없이, 키만 알면 빛의 속도로 값을 꺼내올 수 있다.
📢 섹션 요약 비유: RDBMS가 도서관 사서에게 "과학 코너 3번째 줄에 있는 파란색 표지의 책을 찾아주세요(SQL 쿼리)"라고 부탁하는 것이라면, Key-Value DB는 **'목욕탕 사물함'**과 같습니다. "15번 열쇠(Key)로 15번 사물함을 연다(Value)." 이 직관적이고 단순한 동작 하나로 모든 게 끝납니다.
Ⅱ. Key-Value DB의 왕: Redis (레디스) ★
Key-Value DB 종류는 많지만(Memcached, Riak 등), 면접과 실무의 99%는 Redis다.
1. In-Memory (인메모리) 속도
- 하드디스크가 아니라 컴퓨터의 주기억장치(RAM) 위에서 동작한다. (디스크보다 수천 배 빠름)
- 정전 시 데이터가 날아가는 걸 막기 위해 스냅샷과 AOF 로그를 몰래 디스크에 남겨둔다. (381번 문서 참조)
2. 다양한 Value 자료구조 (Collections)
- 흔한 Key-Value DB는 Value 자리에 '단순한 글자(String)' 하나만 넣을 수 있다.
- 하지만 Redis는 Value 자리에 List(배열), Set(집합), Hash(딕셔너리), Sorted Set(정렬된 집합) 같은 고급 자료구조를 통째로 넣을 수 있다.
- 이것 덕분에 백엔드 개발자가 자바 코드로 짜야 할 정렬 로직이나 중복 제거 로직을 Redis 엔진이 알아서 다 해준다.
3. Single Thread (싱글 스레드)
- 놀랍게도 Redis는 일꾼(스레드)이 단 1명이다.
- 여러 명이 동시에 덤벼도 1명씩 차례대로 처리하므로, 개발자가 동시성 버그(Race Condition)를 고민할 필요 없이 안전하게 결괏값을 얻을 수 있다. (대신 O(N)짜리 무거운 명령어를 치면 뒤에 줄 선 사람들이 다 멈춰버리니 주의해야 함)
Ⅲ. 실무 활용 3대 시나리오
백엔드 아키텍처에서 Redis가 빠지는 곳은 없다.
- 캐싱 (Caching):
- 10초 걸리는 무거운 MySQL 통계 쿼리 결과를 Redis에
[Key: "오늘의매출", Value: "10억"]으로 저장해 둔다(TTL 1시간). - 다음 1시간 동안은 100만 명이 접속해도 MySQL을 괴롭히지 않고 Redis에서 0.01초 만에 10억이라는 글자를 뱉어낸다.
- 10초 걸리는 무거운 MySQL 통계 쿼리 결과를 Redis에
- 세션 (Session) 스토어:
- 웹 서버가 10대로 늘어나도(Scale-out), 로그인된 유저의 정보는 10대가 공유하는 중앙의 Redis 한 곳에만 저장하여 로그인이 풀리지 않게 만든다.
- 실시간 랭킹 보드 (Sorted Set):
- 게임의 '전교 1등~100등'을 보여주기 위해 매번 점수를 정렬(Sort)하면 DB가 터진다.
- Redis의
Sorted Set에 점수를 던져주면, 알아서 실시간으로 랭킹이 매겨져 있어서 그냥 꺼내오기만 하면 된다.
┌──────────────────────────────────────────────────────────────┐
│ Redis를 활용한 캐시(Cache) 아키텍처 흐름 시각화 │
├──────────────────────────────────────────────────────────────┤
│ │
│ [ 👨💻 유저 ] "내 장바구니 보여줘!" │
│ │ │
│ ▼ │
│ [ 🌐 웹 서버 ] ── 1. Redis 찔러보기 ──▶ [ ⚡ Redis (Key-Value) ] │
│ │ (Key: "cart:123") │
│ │ │
│ │ 2. "캐시에 없네? (Cache Miss)" │
│ ▼ │
│ [ 🗄️ MySQL ] ── 3. 무거운 쿼리 실행 ──▶ 결과를 꺼내옴 │
│ │
│ │ │
│ └── 4. 다음번을 위해 Redis에 저장(Cache Hit 준비) ──▶ [ Redis ]│
└──────────────────────────────────────────────────────────────┘
Ⅳ. 결론
"가장 단순한 것이 가장 빠르다." Key-Value DB는 관계형 데이터베이스(RDB)의 대체재가 아니다. 두 기술은 완벽한 보완재다. RDB가 영원히 기억해야 할 무거운 '법전'이라면, Redis 같은 Key-Value DB는 1초 뒤면 지워질지라도 당장 대답해야 하는 가벼운 '포스트잇'이다. 이 단순함의 미학을 이해하고 시스템의 병목 구간(Bottleneck)에 적절히 캐시를 발라주는 기술이야말로, 트래픽을 감당하는 백엔드 아키텍트의 첫 번째 무기다.
📌 관련 개념 맵
- 관련 저장소: Memcached, Amazon DynamoDB (Disk 기반 K-V)
- 보장 기법: RDB 스냅샷, AOF 로깅 (381번 문서)
- 캐시 전략: Look-Aside (읽기 위주), Write-Through (쓰기 동기화)
- 보조 기술: TTL (Time To Live - 지정된 시간 뒤에 데이터가 폭파되는 시한폭탄 설정)
👶 어린이를 위한 3줄 비유 설명
- RDBMS는 크고 두꺼운 '출석부'예요. "1반 3번 이름이 뭐지?" 하고 찾으려면 책장을 펴서 표를 찾아봐야 하죠.
- Key-Value DB는 사물함에 붙여둔 '이름표'예요. 15번 사물함을 열면 그냥 그 안에 들어있는 물건(Value)이 바로 나오죠.
- 찾기 규칙이 너무 단순해서 컴퓨터가 생각할 필요도 없이 빛의 속도로 물건을 찾아주는 마법의 사물함이랍니다!