레디스 개요

앞서 NoSQL에 대해 알아 보았겠지만, RDBMS와 비교해 다시 한 번 정리해 보자. NoSQL은 관계형 데이터베이스(RDB)의 표 형태 관계들이 아닌, 다른 형태로 데이터를 저장ㆍ조회할 수 있는 메커니즘을 제공하는 모든 데이터베이스를 칭한다(http://en.wikipedia.org/wiki/NoSQL). 아래 표와 같이 크게 4가지 형태로 분류할 수 있다. 이중 레디스(Redis: Remote Dictionary Server)는 Key-Value Store로 분류된다.

[표 Ⅱ-3-1] NoSQL의 유형과 특징

Column-Oriented Store	Accumulo, Cassandra, Druid, HBase 하나의 키에 여러 개의 컬럼 이름과 값의 쌍으로 이뤄진 데이터를 저장 및 조회 컬럼은 컬럼 이름, 컬럼 값, 타임스탬프(버전) 등으로 구성되며, 컬럼의 집합을 Row라 하며 Row Key로 식별
Document-Oriented Store	Clusterpoint, Apache CouchDB, Couchbase, MarkLogic, MongoDB ‘키-값’ 구조를 확장한 것으로, 하나의 키에 하나의 구조화한 문서(JSON, BSON, XML 등)를 저장ㆍ조회
Key-value Store	Dynamo, FoundationDB, MemcacheDB, Redis, Riak, FairCom c-treeACE 가장 기본적인 형태의 NoSQL로 ‘키-값’ 구조로 데이터를 저장ㆍ조회
Graph Database	Allegro, Neo4J, InfiniteGraph, OrientDB, Virtuoso, Stardog 노드(Vertex)와 관계(Edge)를 사용해 데이터를 저장ㆍ조회, 관계는 속성이라는 부가정보를 가짐

Ben Scofield의 데이터베이스 유형 간 비기능 품질 특성 비교를 따르면, Key-Value Store는 기능ㆍ확장성ㆍ유연성 면에서 매우 높은 품질을 가지면서도 구성 복잡도가 매우 낮음을 알 수 있다.

[표 Ⅱ-3-2] NoSQL 유형 간 비교

데이터 모델	성능	확장성	유연성	복잡도	기능성
Key?Value Store	hjgh	hjgh	high	none	variable (none)
Column-Oriented Store	high	high	moderate	low	minimal
Document-Oriented Store	high	variable (high)	high	low	variable (low)
Graph Database	variable	variable	high	high	graph theory
Relational Database	variable	variable	low	moderate	relational algebra

반면 Eric Brewer의 CAP 원칙(1999)을 따르면, 분산 컴퓨터 시스템은 아래 세 가지의 비기능 품질 속성을 동시에 모두 만족시킬 수 없으며, 최대 두 가지만 동시에 만족시킬 수 있다.

• Consistency: 모든 노드들에게 동시에 동일한 데이터 조회 보장
• Availability: 성공 또는 실패를 막론하고 모든 요청에 대한 응답을 보장
• Partition Tolerance: 미리 예측할 수 없는 데이터 손실 또는 시스템 구성 요소 중 일부의 실패(Failure)에도 전체 시스템은 항상 정상 작동함을 보장

또한 Nathan Hurst의 ‘Visual Guide of NoSQL System’에서 확인해 보면 레디스는 데이터 일관성(Consistency)과 Partition Tolerance를 동시에 만족시키지만, 데이터 가용성(Availability)에 대한 지원은 부족해 구성 및 운영 시 이에 대한 고려가 필요함을 알 수 있다.

[그림 Ⅱ-3-1] Visual Guide to NoSQL Systems

Redis(Remote Dictionary Server)를 간단히 살펴보면 다음 표와 같다.

[표 Ⅱ-3-3] 레디스 개요

구분	내용
개발자(사)	Salvatore Sanfilippo
최초 배포일	2009년 04월 10일
최신 안정 배포판	2.8.14(2014년09월 10일 기준)
구현 언어	ANSI C
지원 운영체계	크로스플랫폼
유형	Key?value stores
라이선스	BSD
웹 사이트	http://www.redis.io

다음은 배치도(Deployment Diagram)형태의 레디스 기반 시스템 아키텍처 사례다.

[그림 Ⅱ-3-2] 레디스 아키텍처 사례(배치도)

위 아키텍처 배치도 사례 내 주요 구성요소들은 다음과 같다.

구성요소	설명
Web app	Web Browser 기반 사용자 클라이언트
Load Balancer	Web 서버로 향하는 워크로드를 분산시켜 성능/안정성을 향상시키는 네트워크 장비(L4 Switch)
Web Socket Server	Web Server
Redis	메시징 및 데이터 캐싱 용도로 사용
Data Layer	RDBMS로의 접근 경로 제공 (ODBC, JDBC, ADO .NET 등)
Application Layer	Business Application 탑재 및 접근 경로 제공
Persistent RDBMS	하드디스크 기반의 관계형 데이터베이스 (Oracle, MySQL, 등)

레디스 설치

가상머신 소프트웨어는 Virtual Box를 사용해도 무방하고 게스트 OS는 레디스가 공식 지원하는 Unix, Linux, MacOS 중에서 하나를 선택해 설치한다. 윈도우용 레디스는 https://github.com/dmajkic/redis/downloads에서 내려 받아 설치할 수 있지만, 개발 또는 학습 용으로만 사용하기를 권장한다.

Ubuntu의 터미널에서 아래의 명령을 수행해 레디스 설치 파일을 다운로드하고 설치한다.

다음 명령으로 레디스 서버를 기동한다.

[그림 Ⅱ-3-3] 레디스 서버 기동화면

레디스가 기동 되면 [그림 Ⅱ-3-3]과 같은 화면이 출력된다 레디스는 기본적으로 싱글스레드를 사용하기 때문에 PID 하나를 사용하고 6379포트를 사용하여 클라이언트와 통신한다. 레디스를 설치하고 서버를 기동한 후 내장된 명령행(CLI) 클라이언트를 통해 다음과 같이 정상적으로 동작하는지를 확인할 수 있다.

레디스 환경 설정

레디스 환경설정에는 다음 두 가지 방법이 있다.

[표 Ⅱ-3-4] 레디스 환경 설정 방법

환경설정방법	형식	설명
redis.conf	설정 파일	레디스 서버 인스턴스 기동 시 적용 파일 수정 후 레디스 서버 재기동 시 변경내역 반영
config set	런타임 명령어	변경 내역이 현재 동작중인 서버에 즉시 반영(레디스서버인스턴스 재기동 시 변경 설정값이 저장되지 않으므로, 필요한 경우 반드시 redis.conf 파일에 사전 반영해 둔다.)

2014년 9월10일 현재, 주석을 제거한 redis.conf 파일의 내용은 다음과 같다. 해당 설정 항목을 일일이 소개하기에는 지면 제한으로 어려워, 레디스 기반 시스템 아키텍처 설계 시 필수적으로 고려해야 하는 복제(Replication), 샤딩(Sharding), 스냅샷(Snapshot), AOF를 위주로 살펴본다. 독자가 향후 이 파일의 주석과 함께 관련 문서들을 더 폭넓게 살펴봄으로써 레디스 구성 및 설정에 대한 지식을 넓힐 수 있다. redis.conf 파일의 최신본은 http://download.redis.io/redis-stable/redis.conf에서 내려 받을 수 있다.

레디스 설정 파일 내 메모리 크기 등을 지정하기 위한 단위 사용 시 대소문자를 구분하지 않는다.

[표 Ⅱ-3-5] 레디스 환경설정 파일 숫자 단위

표현	설명
1k	1,000바이트
1kb	1,024바이트
1m	1,000,000바이트
1mb	1,024×1,024바이트
1g	1,000,000,000바이트
1gb	1,024× 1,024×1,024바이트

레디스 설정 항목

레디스 설정 및 관리 작업에 참조할 수 있도록, 설정 파일 내 각 설정 항목들을 알아보자. 해당 내용은 본 교재의 내용을 충분히 살펴보고, 레디스의 기본 구조와 메커니즘에 대해 이해한 후 다시 살펴볼 필요가 있다.

General

설정항목	설정사례	설명
daemonize	No	레디스는 기본적으로 daemon으로 동작하지 않음
pidfile	/var/run/redis.pid	레디스가 daemon으로 동작할 때, pid[process id] 파일을 기록하는 기본 위치(별도 파일 지정 가능)
port	6379	기본 포트 번호(별도 포트번호 지정 가능)
bind	127.0.0.1	특정 네트워크 I/F 지정(미지정 시 모든 네트워크 I/F 사용)
unixsocket	/tmp/redis.sock	특정 UNIX 소켓 지정(미지정 시 UNIX 소켓을사용 안함)
unixsocketperm	755
timeout	0	특정 시간(Second) 클라이언트 미동작 시 연결 종료 0은 timeout 미적용을 의미함
tcp-keepalive	60	특정 시간(Second) 클라이언트 미동작 시 TCP ACK 전송
loglevel	notice	debug(가장 상세한 로그) / verbose / notice / warning(중요 또는 심각한 메시지만 기록)
logfile	stdout	별도 파일 지정 필요 레디스가 daemon으로 동작 시 이 값이 stdout이면 /dev/null 보내짐(미기록)
syslog-enabled	no	yes로 지정한 경우 OS syslog 활용(syslog 설정 조정 필요)
syslog-ident	redis	syslog 사용 시 log identity 지정
syslog-facility	local0	User 또는 local0 ~ local7 사이의 값을 지정해야 함

Snapshotting

설정항목	설정사례	설명
save	900 1	900초(15분) 이후 1개의 쓰기 발생
save	300 10	300초(3분) 이후 10개의 쓰기 발생
save	60 10000	60초 이후 10,000개의 쓰기 발생 시 디스크에 데이터 복제
stop-writes-onbgsave-error	yes	RDB 스냅샷 중 쓰기요청 수행 중단옵션. 레디스 서버 및 Disk 지속성에 대한 적절한 모니터링 체계를 갖췄다면 ‘no’로 지정해 사용가능
rdbcompression	yes	dump.rdb 파일을 LZF로 압축
rdbchecksum	yes	CRC64로 Checksum 값 생성후 dump.rdb 파일에 추가 데이터영속성 보장이 강화되나 10% 정도의 성능오버헤드 발생
dbfilename	dump.rdb	변경 지정 가능
dir	./	dump.rdb 파일과 AOF 파일 생성 위치

Replication

설정항목	설정사례	설명
slaveof	<masterip> <masterport>	복제 대상 마스터 노드의 IP 주소와 포트 번호를 명기
slave-serve-stale-data	yes	Master노드와 연결 단절 또는 Replication 진행중일 때 ‘yes’(기본값)로 지정 시 클라이언트의 요청에 항시 응답. ? ‘no’로 지정시 info/slaveof 명령 외의 클라이언트 요청 명령에 ‘SYNC with master in progress’ 에러 메시지 출력
slave-read-only	yes	권장 기본 값
repl-ping-slaveperiod	10	슬레이브 노드가 마스터 노드에게 정기적으로 ping을 보내는 간격 (초)
repl-timeout	60	Bulk transfer I/O, Master Data, Ping Response에 대한 timeout 값(부적절한 timeout 발생을 방지하기 위해 repl-ping-slave-period보다 반드시 큰 값이어야 함)
repl-disable-tcp-nodelay	no	‘no’ - 대역폭을 최대한 활용한 Replication 데이터 전송 모드 ‘yes’ - TCP 패킷 개수를 제한해 대역폭 소모를 줄이는 Replication 데이터 전송 모드
repl-backlog-size	1mb	backlog는 슬레이브 노드 연결 단절 시 슬레이브 노드에 전송할 데이터를 임시 저장하는 버퍼 단절 시 재연결된 슬레이브 노드의 Full Resync를 방지하고 Partial Resynch로 대신할 수 있도록 함.이 크기를 크게 할 수록 슬레이브 노드의 연결 단절 여유 시간을 더 확보할 수 있음.
repl-backlog-ttl	3600	3600초(60분) 동안 연결이 끊어진 슬레이브 노드의 재연결이 이루어지지 않은 경우 해당 슬레이브 노드를 위한 backlog 파일을 삭제. ‘0’으로 지정 시 backlog를 삭제하지 않음.
slave-priority	100	Redis Sentinel이 마스터 노드 장애 시 슬레이브 노드들 중 마스터 노드 선택 기준 값(적은 숫자가 더 높은 우선 순위를 가짐)
min-slaves-to-write	0	마스터 노드가 쓰기 요청을 수용하기 위한 최소 연결 슬레이브 노드개수(충분한 개수의 슬레이브 노드가 없어서 데이터 복제본을 유지할 수 없으면 쓰기 결과가 유실될 수 있음)
min-slaves-max-lag	10	최소 연결 슬레이브 노드 개수에 모자랄 때 슬레이브 노드들의 연결을 기다리는 시간(Second)

Security

설정항목	설정사례	설명
requirepass	foobared	클라이언트에게 명령 요청 시 패스워드를 입력하도록 강제
renamecommand	CONFIG b840fc02d524045429941cc15f59e41cb7be6c52	명령어 치환. 다음의 경우 해당 명령어 사용을 거부하게 됨 (예: rename-command CONFIG "")

LIMITS

설정항목	설정사례	설명
maxclients	10000	접속 클라이언트 개수 제한
maxmemory	<bytes>	메모리 사용 제한
maxmemory-policy	volatile-lru	사용 메모리가 maxmemory에서 지정한 값을 넘을 때 메모리 관리 정책 volatile-lru: (기본 값)expire set에 포함된 Key들을 LRU(Least Recently Used) 정책에 의거 삭제 allkeys-lru: 모든 Key들에 LRU 정책적용 volatile-random: expire set에 포함된 Key들을 무작위로 삭제 allkeys-random: 모든 Key들을 무작위로삭제 volatile-ttl: 가장적은잔여 TTL(Time To Live) 값을 가지고 있는 Key를 삭제 noeviction: 어떤 Key도 삭제하지 않고 쓰기 요청에 대한 에러를 반환
maxmemory-samples	3	LRU 또는 최소 TTL 정책을 적용해 Key 삭제 전에 유사한 조건을 가진 Key들을 선택한 뒤, 최종적으로 삭제 대상 Key를 선정하기 위한 선택 범위 지정(샘플링 개수)

APPEND ONLY MODE

설정항목	설정사례	설명
appendonly	yes	AOF 파일 사용 여부
appendfilename	"appendonly.aof"	AOF 파일 이름 지정
appendfsync	always	운영체제의 fsync( )에 의한 지연된 쓰기 옵션 (메모리 -> Disk) no:fsync()사용없이 즉시 쓰기, 가장 빠름. always:항상 fsync( ) 사용, 느리지만 안전함. everysec:매 초 마다 fsync( )를 호출
no-appendfsync-on-rewrite	no	쓰기 명령에 대한 fsync( ) 리턴 지연 시간이 너무 길어지면 운영체제의 간섭이 있을 수 있으므로, 스냅샷 생성을 위한 BGSAVE 또는 AOF 파일 기록을 위한 BGREWRITEAOF가 실행되고 있을 때는 fsync( )의 호출을 블록킹 함
auto-aof-rewrite-percentage	100	AOF 파일 초기화 및 재기록 시작을 위해 최초 AOF 파일의 크기를 기준으로 사용 비율을 지정(‘0’으로 지정 시 AOF 파일 초기화 없음)
auto-aof-rewrite-min-size	64mb	AOF 파일 초기화 및 재기록 시작을 위해 파일 크기를 지정(‘0’으로 지정 시 AOF 파일 초기화 없음)

LUA SCRIPTING

설정항목	설정사례	설명
lua-time-limit	5000	5,000초까지 Lua 스크립트 실행 미종료 시 에러 메시지 리턴(‘0’으로 지정 시 실행 시간 무제한)

SLOW LOG

설정항목	설정사례	설명
slowlog-log-slower-than	10000	지정된 시간을 넘어 실행이 완료되지 않은 명령들을 Slow Log에 기록함.micro second 단위(1,000,000 = 1 초)

LATENCY MONITOR

설정항목	설정사례	설명
latency-monitor-threshold	0	(milli second) Redis Latency Monitor 서브 시스템이 지연 명령을 추적ㆍ관리하는 기준 시간 지정 ‘LATENCY’ 명령으로 관련 데이터를 출력할 수 있음. ? 레디스 실행 중에는 ‘CONFIG SET latency-monitor-threshold <milliseconds>‘으로 레디스를 실시간 모니터링할 수 있음

EVENT NOTIFICATION

설정항목	설정사례	설명
notify-keyspace-events	""	(레디스의 이벤트 notification 옵션을 아래의 키워드로 설정) " ": notification 비활성화 K:Keyspace 이벤트, published with __keyspace@__ prefix. E:Keyevent 이벤트, published with __keyevent@__ prefix. g:데이터 타입이 지정돼 있지 않은 일반 명령어(예: DEL, EXPIRE, RENAME 등) $: String 명령어 l:List 명령어 s: Set 명령어 h:Hash 명령어 z: Sorted set 명령어 x:Expired 이벤트 (events generated every time a key expires) e: Evicted 이벤트 (events generated when a key is evicted for maxmemory) A: g$lshzxe 혼합 옵션 (예: "AKE"는 모든 이벤트를 의미함) ※ http://redis.io/topics/notifications 추가 참조

LUA SCRIPTING

설정항목	설정사례	설명
lua-time-limit	5000	5,000초까지 Lua 스크립트 실행 미종료 시 에러 메시지 리턴(‘0’으로 지정 시 실행 시간 무제한)

ADVANCED CONFIG

설정항목	설정사례	설명
hash-max-ziplist-entries	512	해시 값이 512개를 넘지 않고 그 중 가장 큰 해시 값의 크기가 64바이트를 넘지 않을 경우, ziplist 형식으로 압축해 메모리 절약
hash-max-ziplist-value	64
list-max-ziplist-entries	512	List가 512개를 넘지 않고 그 중 가장 큰 List의 크기가 64바이트를 넘지 않을 경우, ziplist 형식으로 압축해 메모리 절약
list-max-ziplist-value	64
set-max-intset-entries	512	Set의 크기가 512를 넘지 않는 경우 intset 형식으로 압축해 메모리 절약
zset-max-ziplist-entries	128	정렬된 Set 내 항목 개수가 128개를 넘지 않고 각 항목의 크기가 64바이트를 넘지 않을 경우, ziplist 형식으로 압축해 메모리 절약
zset-max-ziplist-value	64
hll-sparse-max-bytes	3000	HyperLogLog의 sparse representation 한계. 이 값을 넘으면 dense representation이 적용 됨. dense representation이 더 효율적이 되는 한계점인 16,000 이상의 값 부여는 무의미 CPU 사용률보다 메모리 공간 효율성이 더 중요할 경우 10,000정도의 값을 부여할 수 있음
activerehashing	yes	"no": 레디스 기본 옵션인 lazy rehashing 기능 사용 "yes": 실시간 요구사항이 존재하고 지속적으로 메모리 자원을 최적화해야 할 경우 사용(1초당 1millisecond의 CPU 타임을 해시 테이블 재계산에 할당)
hz	10	Redis 백그라운드 타스크 실행 주기 0~500사이의 값을 부여할 수 있음 더 높은 숫자는 Redis의 반응 시간을 줄여주지만 CPU를 더 많이 점유하게 됨 (최대 100까지를 권장)
aof-rewrite-incremental-fsync	yes	"yes"로 지정 시, AOF 파일 기록을 위한 Redis child 프로세스가 fsync( )를 활용 데이터를 32 MB 단위로 전송 반영 함.
client-output-buffer-limit	<class> <hardlimit> <softlimit> <softseconds>	클라이언트 time out 시간 지정 <class> 3가지 클라이언트 유형 - normal : MONITOR포함 일반 클라이언트 - slave : slave 클라이언트 - pubsub : 하나 이상의 pubsub channel 또는 pattern에 등록한 클라이언트 <hardlimit> 클라이언트 - output buffer의 크기가 지정된 크기를 넘는 경우 즉시 종료 <softlimit> 클라이언트 - output buffer의 크기가 지정된 크기를 넘는 경우 soft second 동안 대기 후 종료 <softseconds> 클라이언트 - softlimit대기 시간 hardlimit/softlimit/softsecond의 값을 "0"으로 지정하는 경우 클라이언트 out buffer 크기에 제한을 두지 않음 [지정 사례] client-output-buffer-limitnormal000 client-output-buffer-limitslave256mb64mb60 client-output-buffer-limitpubsub32mb8mb60

레디스 실습

레디스는 스토리지에 저장되는 일반 RDB와 두 가지 차이점이 있다. 첫 번째 NoSQL을 지원하는 key-value로 데이터를 관리하며. 두 번째 스토리지가 아닌 메모리에서 데이터를 관리한다는 점이다.
이 두 가지 차이점을 생각하며 레디스에서 데이터를 다루는 방법을 실습해 보도록 하자.

레디스의 기본사용법

데이터 입력

데이터를 레디스에 입력하기 위해서는 set명령어를 사용한다. 레디스 클라이언트 명령행에서 데이터 입력을 실습해 보자.

1. ① set 명령어를 사용해 data1을 “key”로 mydata1을 “value”로 레디스에 저장한다.
2. ② keys 명령어를 사용하여 data1 key가 있는지 확인한다.
3. ③ get 명령어를 사용하여 data1의 value값을 확인한다. mydata1 value가 저장 되어 있는 것을 확인할 수 있다.

여러 건의 데이터 입력

mset을 사용하여 여러 건의 데이터를 입력해보자.

1. ① mset은 여러 건의 데이터를 입력하는 명령어이다. mset으로 입력시 항상 key1 value1 key2 value2 형식으로 입력하며 key와 value의 쌍이 맞아야 한다.
2. ② keys명령어를 사용하여 key가 정확히 저장되었는지 확인할 수 있다.
3. ③ get명령어를 사용하여 data1의 value를 확인할 수 있다. 그런데 data1의 value값이 변한 것을 볼 수 있다. 레디스는 초기에 multi 선언을 하지 않으면 트랜잭션을 일으켜 데이터를 commit한다.
4. ④ mget 명령어로 여러 개의 키에 할당된 값을 조회할 수 있다.

트랜잭션관리

레디스에서 트랜잭션을 관리하기 위해서는 multi 명령어를 사용한다.

multi 명령어를 사용하고 data1에 mydata4를 저장하면 “QUEUED” 상태가 된다.

현재 세션에서 get 명령어로 데이터를 조회해 보고 터미널을 새로 열어 데이터를 조회해 보자

현재 세션에서는 상태가 “QUEUED”로 조회되고 새로운 터미널에서 조회하면 이전에 입력한 데이터인 mydata0이 조회된다.

레디스의 트랜잭션 실행 명령어인 exec를 사용하여 데이터를 commit하고 현재 세션의 데이터와 다른 터미널에서도 데이터가 변했는지 확인해 보자.

두 개의 세션에서 모두 데이터가 commit 된 것을 확인할 수 있다.

데이터 타입

레디스는 String, List, Hash, Set, Stored set의 데이터타입을 지원한다.

String

String 타입은 레디스의 가장 기본적인 데이터타입이다. binary형태로 저장되기 때문에 데이터의 포맷에 관계없이 (동영상이나 이미지 같은 데이터도 상관없이) 저장할 수 있다. 또한 문자열과 정수형을 자동으로 구분하기 때문에 해당 key에 대한 데이터 형태는 각 key의 value를 판단하여 레디스에서 자동으로 인식하게 된다.

String 타입의 데이터를 추가하는 것에 대하여 알아보자. key-value 데이터베이스에서 데이터를 추가하는 것은 스키마를 가지고 있는 RDB와는 다르게 데이터 건수를 늘리는 것이 아니라 특정 key에 대한 value의 값을 더하는 것이다.

append명령어를 사용하여 데이터를 추가 하였다. 결과는 이전에 입력한 “11a”에 입력한 문자열 “12a”가 추가 되어 “11a12a”로 값이 저장된 것을 확인 하였다.

List

List 타입은 String 타입의 데이터가 생성된 순서대로 정렬된 리스트라 이해하면 된다.
List 타입으로 데이터를 생성해 보자. List 타입의 데이터 입력은 push명령어를 사용한다. rpush는 오른쪽으로 데이터를 추가하고 lpush명령은 왼쪽으로 데이터를 추가한다. 데이터를 조회하기 위해서는lrange 명령어를 사용하여 범위 값을 지정하여 지정된 범위내의 데이터 값을 조회할 수 있다.

리스트의 데이터를 삭제해 보자. lrem 명령어를 사용하여 “d”를 삭제하였다.

Set

Set 타입은 먼저 String 타입에서 데이터 입력을 위해 사용하는 set명령과는 상관이 없다. Set 타입은 String 타입의 데이터가 순서에 관계없이 집합된 형태이다. Set 타입에서는 Set내에서 데이터의 추가, 삭제 및 테스트가 가능하다.
Set 타입으로 데이터를 입력해 보자. sadd 명령어를 사용하여 데이터를 입력한다. smembers 명령어를 사용하여 데이터를 조회한다. Set 데이터타입의 특이한 점은 key에 대하여 중복된 값을 입력하여도 데이터의 값을 중복으로 저장하지 않는다는 것이다.

Sinter를 사용하여 교집합을 구해보자. Sinter는 RDB의 조인과 유사하게 사용할 수 있다.

Hash

Hash 타입은 여러 개의 key들과 value들이 구조화 된 타입이라 할 수 있다. 레디스에서 Hash 데타입은 RDB의 테이블과 가장 유사한 데이터처럼 보이지만 RDB 측면에서 보면 단 하나의 로우만 갖는 테이블처럼 보일 것이다.
Hash 타입으로 이름, 나이, 성별을 가지고 있는 데이터 오브젝트를 만들어보자. hmset 명령어를 사용하여 emp라는 오브젝트에 name, age, gender의 필드를 만들고 데이터를 입력하였다. hmget명령어를 사용하여 데이터를 조회한다.

Sorted Set

Sorted Set 타입은 Set 타입과 유사하지만 각각의 값에 스코어가 추가 된다. 스코어를 이용하기 때문에 Set 타입보다 데이터의 입력, 추가, 삭제에서 훨씬 좋은 성능을 보장한다.
Sorted Set 타입으로 데이터를 입력해 보자. zadd 명령어를 사용하여 데이터를 입력한다. zrange 명령어를 사용하여 입력한 데이터를 조회한다. zrange명령어에 withscores 옵션을 사용하면 입력시 저장한 score값도 함께 조회할 수 있다.