I. 자료형의 기능과 개요
1. 다섯 가지 자료형
(1) Redis가 기본적으로 제공하는 주요 자료형 다섯 가지:
- String형: 문자열 및 숫자값 저장에 적합한 단순한 키-값 구조.
- List형: 삽입 순서를 유지하는 문자열 리스트.
- Hash형: 필드-값 쌍으로 객체를 표현하는 데 유용.
- Set형: 순서 없이 중복 없는 고유 문자열의 집합.
- Sorted Set형: 점수(score)에 따라 자동 정렬되는 집합.
이들 자료형은 각각 명확한 유스케이스에 따라 선택되며, 상황에 맞게 적절히 사용하는 것이 성능과 코드 간결성에 중요함.
2. 보조 자료형과 기능
(1) 특정 용도에 특화된 보조 자료형:
- 비트맵(BitMap)
- 지리적 공간 인덱스(Geospatial Index)
(2) 기능적 목적의 주요 기능:
- Pub/Sub (발행-구독 기능)
- HyperLogLog (중복 추정 계산)
- Redis Stream (스트림 기반 데이터 처리)
3. Redis의 폭넓은 데이터 모델 표현성
- Redis는 단순 KVS(Key-Value Store) 이상의 데이터 모델을 표현 가능.
- 적절한 자료형을 선택하면 원자성 보장, 코드 단순화, 성능 최적화가 가능.
- 키 간 독립성 원칙을 따르되, Hash형을 통해 연관 값들을 묶어서 관리 가능.
- 향후에는 "키 어노테이션" 기능으로 키 간 관계성도 표현할 수 있게 될 예정.
4. Redis의 자료형과 명령어
- 각 자료형에 맞는 전용 명령어 존재 (예: SET/GET for String, HSET/HGET for Hash 등).
- 잘못된 자료형에 명령어 사용 시 오류 발생.
- MSET, MGET 등 여러 키를 동시에 다룰 수 있는 명령어도 존재.
- 명령어는 대소문자를 구별하지 않음.
5. Redis 유틸리티 명령어
- KEYS pattern: 키 목록 검색 (운영 환경에서 비권장).
- EXISTS key: 키 존재 여부 확인.
- TYPE key: 해당 키의 자료형 확인.
- DEL key: 키 삭제.
- SCAN 계열 명령어 권장 (KEYS 계열 대체용, 운영환경 안전성 보장).
II. String형
1. 개요
(1) Redis의 기본 자료형으로, 키-값 형태의 가장 단순한 구조
(2) 값으로 문자열, 이진 데이터, 정수, 부동소수점 모두 저장 가능
(3) 최대 512MB까지 저장 가능하며, 설정을 통해 확장 가능
(4) 가장 널리 쓰이며, 캐시·세션·카운터 등 범용적으로 활용됨
2. 주요 활용 예시
(1) 세션 캐시
- session:<id> 형태로 세션 정보(JSON 등)를 빠르게 저장/조회.
- 예: 로그인 사용자 정보, 장바구니 정보 등.
(2) 숫자 카운터
- 방문자 수, 클릭 수, 사용량 등을 카운트하기 위해 INCR, DECR 사용.
- 부동소수점 증가도 가능 (INCRBYFLOAT)
3. 주요 명령어
(1) 값 설정 및 조회
- SET key value – 값 저장
- GET key – 값 조회
- MSET k1 v1 k2 v2 – 다중 저장
- MGET k1 k2 – 다중 조회
(2) 부분 읽기/쓰기 및 부가 명령어
- APPEND key val – 뒤에 추가
- STRLEN key – 길이 확인
- GETRANGE key s e – 부분 조회
- SETRANGE key off val – 부분 변경
(3) 숫자 조작
- INCR key – +1 증가
- DECR key – -1 감소
- INCRBY key n – 정수 증가
- DECRBY key n – 정수 감소
- INCRBYFLOAT key f – 소수 증가
(4) TTL 설정
- SETEX key sec val – 만료 저장
- EXPIRE key sec – TTL 설정
- SET key val EX sec – 만료 저장
- TTL key – TTL 조회
(5) 원자적 처리 및 조건부 저장
- SET key val NX – 없을 때 저장
- SET key val XX – 있을 때 저장
- SET key val GET – 이전값 반환
- MSETNX – 조건 다중저장
- GETEX key – 만료+조회
- GETDEL key – 조회+삭제
4. 폐지 예정 및 대체 권장 명령어
- GETSET → SET ... GET
- SETNX → SET ... NX
- SETEX, PSETEX → SET ... EX | PX
5. 주의사항 및 팁
- TTL 설정은 SET 옵션 조합 사용 시 원자성 확보
- 최대 512MB 제한은 proto-max-bulk-len 조정으로 완화 가능
- 키 네이밍은 : 구분자 활용한 네임스페이스 방식 권장
- 명령어는 대소문자 구분 없음 (관례상 대문자 사용)
III. List형
1. 개요
(1) 문자열(String)의 순서 있는 컬렉션 자료형
(2) 삽입 순서를 유지하며 중복 허용
(3) 스택, 큐, 로그 기록, 타임라인 등에 적합
(4) 앞/뒤 양쪽에서 푸시/팝 가능 (양방향 큐)
2. 주요 활용 예시
(1) SNS 타임라인 – 최신 글 순서대로 정렬
(2) 인기 콘텐츠 캐시 – 조회수 순 정렬
(3) 작업 큐 – 메시지 처리용 큐 구현
(4) 로그 저장 – 순차 기록 저장용
3. 주요 명령어
(1) 요소 추가 및 제거
- LPUSH key val – 왼쪽 추가
- RPUSH key val – 오른쪽 추가
- LPOP key – 왼쪽 제거
- RPOP key – 오른쪽 제거
- LPUSHX key val – 조건부 왼쪽 추가
- RPUSHX key val – 조건부 오른쪽 추가
(2) 범위 조회 및 특정 위치 조작
- LRANGE key s e – 범위 조회 (시작과 끝)
- LINDEX key i – 인덱스 조회
- LSET key i val – 위치 수정
- LTRIM key s e – 범위 유지
- LLEN key – 길이 확인
- LPOS key val – 위치 찾기
(3) 블로킹 및 멀티리스트 조작
블로킹 명령어는 리스트가 비어있는 경우 데이터가 들어올 때 까지 대기한다.
일반 명령어(LPOP, RPOP)는 빈 리스트면 바로 nil을 반환하지만, 블로킹 명령어는 timeout까지 대기함
비동기 환경 또는 쓰레드 풀에서 처리해야 함 & 블로킹 시간이 길거나 너무 많은 리스트를 대상으로 할 경우 서버 응답 지연에 주의
- BLPOP key t – 왼쪽 대기
- BRPOP key t – 오른쪽 대기
- LMOVE src dst L|R L|R – 요소 이동
- BLMOVE src dst L|R L|R timeout – 대기 이동
- LMPOP N keys DIR – 멀티 추출
- BLMPOP timeout N keys DIR – 대기 추출
4. 폐지 예정 및 대체 권장 명령어
- RPOPLPUSH → LMOVE ... RIGHT LEFT
- BRPOPLPUSH → BLMOVE ... RIGHT LEFT
5. 주의사항 및 팁
- LRANGE는 전체 조회, LTRIM은 리스트 유지 용도로 구분
- LLEN, LPOP 등은 O(1) 연산이지만, 중간 접근은 느릴 수 있음
- 블로킹 계열 명령어는 작업 큐 구현에 유용 (BLPOP, BRPOP 등)
- Redis 6.2+에서는 count, timeout, 멀티리스트 등을 지원하는 고급 명령어 제공됨
- List가 너무 커지면 메모리 부담 및 블로킹 지연 주의 필요
IV. Hash형
1. 개요
(1) 하나의 키 안에 여러 필드(field)-값(value) 쌍을 저장하는 자료형
(2) 자바의 Map, 자바스크립트의 Object, Python의 dict와 유사
(3) 사용자의 프로필, 설정, 객체 데이터 등 표현에 적합
(4) 필드 단위 조작이 가능해 부분 업데이트나 조회에 유리
2. 주요 활용 예시
(1) 사용자 정보 저장 – 이름, 이메일, 나이 등
(2) 상품 정보 저장 – 이름, 가격, 재고 등
(3) 세션, 설정 등 구조화된 객체 표현
3. 주요 명령어
(1) 필드-값 저장 및 조회
- HSET key f v – 필드 저장
- HGET key f – 필드 조회
- HMSET key f1 v1 ... – 다중 저장
- HMGET key f1 f2 ... – 다중 조회
- HGETALL key – 전체 조회
- HKEYS key – 필드 목록
- HVALS key – 값 목록
- HLEN key – 필드 수량
(2) 필드 존재/삭제/부분 탐색
- HEXISTS key f – 존재 확인
- HDEL key f – 필드 삭제
- HSTRLEN key f – 값 길이
- HSCAN key cursor – 반복 탐색
- HRANDFIELD key [cnt] – 무작위 필드
(3) 숫자 조작
- HINCRBY key f n – 정수 증가
- HINCRBYFLOAT key f fval – 소수 증가
(4) 조건부 저장
- HSETNX key f v – 없을 때 저장
4. 폐지 예정 및 대체 권장 명령어
- HMSET → Redis 4.0 이후에도 유지되지만, HSET f1 v1 f2 v2 ... 권장
- HMGET → Redis 4.0 이후 HGET f1 f2 ... 사용 가능
5. 주의사항 및 팁
- Hash 내 필드는 각각 TTL 설정이 불가능 (키 단위 TTL만 가능)
- 작은 필드 수, 작은 값일수록 메모리 효율적 (ziplist/hashtable 내부 인코딩)
- HDEL, HGETALL은 필드 수가 많으면 성능 저하 가능
- 많은 사용자 데이터를 다룰 때는 key = user:<id>, 필드 = name, age 형태로 구성
- Redis Cluster 사용 시, 필드 단위 샤딩 불가 (키 단위 분산)
VI. Sorted Set형
1. 개요
(1) Set형과 유사하지만 각 요소에 score(부동소수점 수)를 부여하여 자동 정렬
(2) 중복 없이 고유한 멤버 관리 + 점수 기반 정렬
(3) 랭킹, 점수판, 순위 계산 등 실시간 정렬 데이터 처리에 최적
(4) score를 기준으로 범위 조회, 위치 검색, 증가/감소 등이 가능
2. 주요 활용 예시
(1) 게임 랭킹 시스템 – 실시간 유저 순위 표시
(2) 게시글 인기 순위 – 좋아요 수에 따라 정렬
(3) 뉴스 피드 – 최신 순 혹은 점수 순 정렬
(4) 실시간 점수판, 추천 알고리즘, 탑N 추출
3. 주요 명령어
(1) 요소 추가 및 수정
- ZADD key score member – 점수 추가
- ZINCRBY key delta member – 점수 증가
(2) 정렬/범위 조회
- ZRANGE key start end – 오름차순 조회
- ZREVRANGE key start end – 내림차순 조회
- ZRANGE key BYSCORE min max – 점수 범위
- ZRANGEBYSCORE key min max – 점수 범위
- ZREVRANGEBYSCORE key max min – 역방향 범위
- ZRANGEBYLEX key min max – 사전순 범위
- ZRANK key member – 순위 조회
- ZREVRANK key member – 역순위 조회
- ZSCORE key member – 점수 조회
- ZCARD key – 요소 수량
(3) 삭제 및 조건 조회
- ZREM key member – 요소 삭제
- ZPOPMAX key [count] – 최대 추출
- ZPOPMIN key [count] – 최소 추출
- ZCOUNT key min max – 범위 수량
- ZLEXCOUNT key min max – 사전범위 수
- ZSCAN key cursor – 반복 탐색
- ZMSCORE key m1 m2 – 다중 점수 조회
(4) 집합 연산
- ZUNIONSTORE dest N k1 k2 – 합집합 저장
- ZINTERSTORE dest N k1 k2 – 교집합 저장
- ZDIFFSTORE dest k1 k2 – 차집합 저장
- ZUNION dest WITHSCORES – 합집합 반환
- ZINTER dest WITHSCORES – 교집합 반환
- ZDIFF dest WITHSCORES – 차집합 반환
4. 주의사항 및 팁
- ZADD, ZINCRBY, ZRANGE, ZREVRANGE는 실시간 랭킹 구현의 핵심
- 동일 score일 경우 멤버 이름의 사전순으로 정렬됨
- score는 부동소수점(float) → 정렬 오차 고려
- 멤버 수 많을수록 정렬 성능과 메모리 주의
- ZCARD, ZCOUNT는 O(1), ZRANGE, ZREM 등은 O(logN)~O(N)
- ZPOPMAX, ZPOPMIN은 탑N 추출에 유용
VII. 기타 고급 기능 정리
1. 비트맵 (Bitmaps)
(1) 개요
- String 자료형 기반 비트 연산
- 특정 위치에 0 또는 1로 상태를 기록
- 출석 체크, 플래그 저장 등 비트 기반 상태 관리에 적합
(2) 주요 명령어
- SETBIT key offset value – 비트 설정
- GETBIT key offset – 비트 조회
- BITCOUNT key [s e] – 비트 수 카운트
- BITOP op dest k1 k2 ... – 비트 연산
- BITPOS key bit – 최초 위치 조회
(3) 활용 예시
- 일자별 출석 체크
- 플래그 상태 저장 (예: 로그인 여부)
- 대용량 사용자 상태 추적
2. 하이퍼로그로그 (HyperLogLog)
(1) 개요
- 고유한 요소 수 추정용 데이터 구조
- 메모리 12KB 내외로 매우 많은 유저 수 추정 가능
- 정확도는 다소 낮지만 메모리 효율이 뛰어남
(2) 주요 명령어
- PFADD key elem – 요소 추가
- PFCOUNT key – 고유 수 추정
- PFMERGE dest k1 k2 – 합치기
(3) 활용 예시
- UV(고유 방문자) 추정
- 대규모 사용자 이벤트 집계
- 메모리 효율 중시할 때 사용
3. Pub/Sub (발행/구독)
(1) 개요
- 실시간 메시지 브로드캐스트 시스템
- 채널 단위로 메시지 발행(PUBLISH) / 구독(SUBSCRIBE)
- 메시지 큐 역할은 못하지만 실시간 알림 등에 유용
(2) 주요 명령어
- PUBLISH channel msg – 메시지 발행
- SUBSCRIBE channel – 채널 구독
- UNSUBSCRIBE channel – 구독 해제
- PSUBSCRIBE pattern – 패턴 구독
- PUNSUBSCRIBE pattern – 패턴 해제
(3) 활용 예시
- 실시간 알림, 채팅
- 분산 환경의 이벤트 전파
- 마이크로서비스 간 메시징
4. 스트림 (Streams)
(1) 개요
- 로그와 큐의 기능을 갖춘 데이터 스트림 자료형
- ID 기반 순서 보장, 소비자 그룹 지원 → 메시지 큐 대체 가능
- Kafka와 유사하지만 Redis 내부에서 동작
(2) 주요 명령어
- XADD key * f1 v1 – 요소 추가
- XRANGE key - + – 범위 조회
- XREAD COUNT 10 STREAMS key 0 – 읽기
- XDEL key id – 요소 삭제
- XGROUP CREATE – 그룹 생성
- XREADGROUP – 그룹 읽기
- XACK – 처리 완료 확인
(3) 활용 예시
- 실시간 로그 수집
- 분산 작업 큐
- 순차적 데이터 처리
5. 지오스페이셜 (Geospatial)
(1) 개요
- 위도/경도 기반 위치 정보 저장
- 반경 검색, 거리 계산 등 가능
(2) 주요 명령어
- GEOADD key lon lat mem – 위치 추가
- GEOPOS key mem – 좌표 조회
- GEODIST key m1 m2 – 거리 계산
- GEORADIUS key lon lat r – 반경 검색
- GEOSEARCH key FROMMEMBER m BYRADIUS r – 위치 검색
(3) 활용 예시
- 주변 상점 검색
- 사용자 근처 서비스 제공
- 거리 기반 정렬
VIII. 꼭 알고가자. (기억포인트)
1. 내용
CHAPTER 02 전체 정리 및 의의 (GPT 이용)
1. Redis는 단순한 K/V 저장소가 아니다
- 단순한 문자열 저장 뿐 아니라, 구조화된 데이터, 정렬, 통계, 메시징 등 다양한 형태의 데이터를 효율적으로 처리할 수 있는 풍부한 자료형을 제공
- 자료형을 잘 활용하면 별도 DB 없이도 많은 문제 해결 가능 (ex: 랭킹, 출석체크, 메시지 큐 등)
2. 6가지 핵심 자료형의 특성과 용도 이해
String | 기본 K/V 구조 | 세션, 카운터, TTL 캐시 등 |
List | 순서 있는 목록 | 큐, 로그, 피드 |
Hash | 필드 기반 객체 | 유저 정보, 설정 값 |
Set | 중복 없는 집합 | 태그, 유니크 유저 |
Sorted Set | 점수 기반 정렬 | 랭킹, 점수판 |
Stream | ID 순 데이터 | 로그 수집, 메시지 처리 |
→ 자료형을 올바르게 선택하면 성능 최적화, 구현 단순화, 원자성 보장까지 가능
3. Redis를 DB, 캐시, 큐, 브로커 등으로 확장 가능
- Pub/Sub, Stream으로 메시징 기능
- HyperLogLog, Bitmaps로 통계 기능
- 지오스페이셜, TTL, 조건 저장, 블로킹 큐 등 → 다양한 실시간 서비스 구현 가능
- → Redis 하나로 마이크로서비스의 여러 기술 요소 대체 가능
4. 실무에서 Redis를 쓸 때 중요한 기준
- 자료형 선택 기준: _데이터 구조 특성_과 접근 패턴
- 명령어 사용 시 주의: O(N) 성능 비용, SCAN 계열 권장
- 운영환경에서는 무거운 명령어(KEYS, FLUSHALL 등) 피할 것
- TTL, 조건부 명령어 조합으로 원자적 캐시 처리 가능 (SET key val NX EX 60 등)
2. 문제
📘 CHAPTER 02 연습문제 (자료형과 기능)
✅ 기본 개념 확인
- 다음 중 Redis의 기본 자료형이 아닌 것은?
A. String
B. List
C. Tree
D. Set - Hash 자료형은 어떤 형태로 값을 저장하는가?
A. 단일 문자열
B. 필드-값(Field-Value) 쌍
C. 점수-멤버 쌍
D. 키-리스트 쌍 - Sorted Set 자료형의 주요 특징으로 옳은 것은?
A. 중복 허용
B. 삽입 순서 유지
C. 점수(score)에 따라 정렬됨
D. FIFO 구조를 따름
✅ 명령어 이해
- 아래 명령어 중 String 자료형에서 숫자를 1 증가시키는 것은?
A. INCRBY key 1
B. SADD key 1
C. HINCRBY key field 1
D. ZINCRBY key 1 member - 다음 중 List 자료형에서 왼쪽 끝에 요소를 삽입하는 명령어는?
A. RPUSH
B. LPOP
C. LPUSH
D. RPOP - 다음 중 Set 자료형의 교집합 결과를 반환하는 명령어는?
A. SUNION
B. SINTER
C. SDIFF
D. ZINTER
✅ 실무 응용
- 사용자별 로그인 상태(1 또는 0)를 일자별로 관리하려고 한다. 가장 적합한 자료형은?
A. List
B. Set
C. BitMap
D. Stream - 하루 방문자 수(중복 제거된 사용자 수)를 대용량으로 추정하고 싶다. 가장 적합한 기능은?
A. Set
B. BitMap
C. HyperLogLog
D. Sorted Set - 실시간 랭킹 시스템(예: 게임 점수판)을 구성하려 한다. 어떤 자료형을 쓰는 것이 가장 적절한가?
A. Hash
B. Sorted Set
C. List
D. Pub/Sub - Redis에서 SET key value NX EX 60 명령어의 의미로 알맞은 것은?
A. 값을 덮어쓰고 TTL은 무한
B. 키가 존재하면 덮어씀, TTL은 60초
C. 키가 없을 때만 저장하고 TTL은 60초
D. 키가 없을 때만 저장하고 TTL은 무제한
3. 해설
📘 정답 및 해설
✅ 기본 개념 확인
- 정답: C. Tree
해설: Redis 기본 자료형은 String, List, Hash, Set, Sorted Set입니다. Tree는 없음. - 정답: B. 필드-값(Field-Value) 쌍
해설: Hash는 필드-값 구조로 구성되며, 사용자 프로필 같은 구조적 데이터에 적합합니다. - 정답: C. 점수(score)에 따라 정렬됨
해설: Sorted Set은 score에 따라 자동 정렬되며, 랭킹 시스템 등에 사용됩니다.
✅ 명령어 이해
- 정답: A. INCRBY key 1
해설: String형 숫자 값을 정수 단위로 증가시킬 때 사용합니다.- INCR key와 동일 효과
- 정답: C. LPUSH
해설: LPUSH는 List의 왼쪽(앞)에 요소를 추가합니다. - 정답: B. SINTER
해설: Set 자료형의 교집합을 반환합니다.- SUNION: 합집합
- SDIFF: 차집합
✅ 실무 응용
- 정답: C. BitMap
해설: 로그인 여부(0/1) 같은 이진 상태를 일자별로 기록할 때 비트맵이 메모리 효율적입니다. - 정답: C. HyperLogLog
해설: HyperLogLog는 메모리 사용을 최소화하면서 고유 수(Unique Count)를 추정합니다. - 정답: B. Sorted Set
해설: 점수(score)에 따라 정렬되는 구조이므로 실시간 랭킹 시스템에 가장 적합합니다. - 정답: C. 키가 없을 때만 저장하고 TTL은 60초
해설: NX는 존재하지 않을 때만 저장, EX 60은 TTL을 60초로 설정 → 원자적 캐싱 처리 가능.
'서적 > 실전 Redis' 카테고리의 다른 글
CHAPTER 05 레디스 운용 관리 [PART 02 실전] (0) | 2025.06.24 |
---|---|
Chapter 03.고급 기능 [Part1 기초] (2) | 2025.06.09 |
Chapter 01.레디스의 시작 [Part1 기초] : 연습문제 포함 (1) | 2025.05.17 |