redis 데이터타입
** 커맨드의 원자적 : 동일한 키 작업을 수행시 redis 는 Single Thread 기반으로 동작, 경합조건이 결코 발생하지 않는다.
문자열
ㄱ. 가장 많이 사용되는 타입
ㄴ. 어떠한종류의 데이터도 담을수 있으나, 512MB를 초과할수없음
ㄷ. 문자열 관련 사용예시
1) 캐시매커니즘 : html, api응답에서 이미지, 비디오까지 어떠한 텍스트 또는 바이너리 데이터라도 캐시가능
set,get,mset,mget 커맨드를 이용한 간단한 캐시 시스템 구현
2) 자동만료캐시 : 키의 만료를 자동으로 지원하는 문자열은 setex, expire, expireat 커맨드를 이용
database 질의실행이 오래걸리고, 일정시간동안 캐시돼야할때 매우 유용
성능향상 및 자주실행되는 질의를 피할수있다.
3) 개수계산 : 문자열과 incr, incrby 커맨드를 이용
리스트
ㄱ. 특징
1) 간단한 콜렉션, 스택, 큐와 같이 동작하기때문에 유연한 데이터 타입
2) 많은 이벤트 시스템들은 redis 의 리스트 를 queue 로 사용하는데, 리스트 커맨드가 원자적인 특성을 가지고있다.
3) 병렬시스템이 큐에서 엘리먼트를 얻어낼때 중복으로 얻지 않도록 보장
4) 블로킹(blocking) 커맨드가 존재
: client 가 비어있는 리스트에 blocking 커맨드를 실행시, 리스트에 새로운 엘리먼트가 추가될때까지 대기
: redis 의 리스트는 linked list 라서 처음,또는 끝에서 엘리먼트의 add, delete 는 항상 O(1) , 일정시간의 성능을 가진다.
: 리스트에서 엘리먼트에 접근하는 방식은 O(N), 선형(linear) 시간이지만, 첫 번째 또는 마지막엘리먼트에는 항상
일정한 시간으로 접근
: 메모리최적화
i. 리스트 엘리먼트 < list-max-ziplist-value(byte)
ii. 엘리먼트 개수 < list-max-ziplist-entries
일시, 리스트는 encode 될수있고, 메모리 최적화(4장에서 자세히 진행)
5) 리스트가 가질수 있는 엘리먼트의 최대개수 2의32승-1 ==> 40억개 이상의 엘리먼트를 가질수 있다.
해시
ㄱ. 특징
1) 메모리 최적화
i. 설정 : hash-max-ziplist-entires, hash-max-ziplist-value 기반
(자세한건 4장에서..: 괴물들이 사는 나라..(-_-?))
2) 해시의 내부
i. 집리스트(ziplist) : 메모리 효율화에 목적을 둔 양쪽으로 연결된 리스트
정수를 일련의 문자로 저장하지않고, 실제 정수의 값으로 저장
집리스트가 메모리 최적화가 되어있다고 하더라도, 일정시간내 검색이 수행되진 않음
ii. 해시테이블(hash table) : 일정한 시간내로 검색은 되나, 메모리 최적화가 이루어지지않음
redis 저장공간
redis 데이터 영속성
redis 데이터타입 ** 커맨드의 원자적 : 동일한 키 작업을 수행시 redis 는 Single Thread 기반으로 동작, 경합조건이 결코 발생하지 않는다.
문자열 ㄱ. 가장 많이 사용되는 타입 ㄴ. 어떠한종류의 데이터도 담을수 있으나, 512MB를 초과할수없음 ㄷ. 문자열 관련 사용예시 1) 캐시매커니즘 : html, api응답에서 이미지, 비디오까지 어떠한 텍스트 또는 바이너리 데이터라도 캐시가능 set,get,mset,mget 커맨드를 이용한 간단한 캐시 시스템 구현 2) 자동만료캐시 : 키의 만료를 자동으로 지원하는 문자열은 setex, expire, expireat 커맨드를 이용 database 질의실행이 오래걸리고, 일정시간동안 캐시돼야할때 매우 유용 성능향상 및 자주실행되는 질의를 피할수있다. 3) 개수계산 : 문자열과 incr, incrby 커맨드를 이용
리스트 ㄱ. 특징 1) 간단한 콜렉션, 스택, 큐와 같이 동작하기때문에 유연한 데이터 타입 2) 많은 이벤트 시스템들은 redis 의 리스트 를 queue 로 사용하는데, 리스트 커맨드가 원자적인 특성을 가지고있다. 3) 병렬시스템이 큐에서 엘리먼트를 얻어낼때 중복으로 얻지 않도록 보장 4) 블로킹(blocking) 커맨드가 존재 : client 가 비어있는 리스트에 blocking 커맨드를 실행시, 리스트에 새로운 엘리먼트가 추가될때까지 대기 : redis 의 리스트는 linked list 라서 처음,또는 끝에서 엘리먼트의 add, delete 는 항상 O(1) , 일정시간의 성능을 가진다. : 리스트에서 엘리먼트에 접근하는 방식은 O(N), 선형(linear) 시간이지만, 첫 번째 또는 마지막엘리먼트에는 항상 일정한 시간으로 접근 : 메모리최적화 i. 리스트 엘리먼트 < list-max-ziplist-value(byte) ii. 엘리먼트 개수 < list-max-ziplist-entries 일시, 리스트는 encode 될수있고, 메모리 최적화(4장에서 자세히 진행) 5) 리스트가 가질수 있는 엘리먼트의 최대개수 2의32승-1 ==> 40억개 이상의 엘리먼트를 가질수 있다.
해시 ㄱ. 특징 1) 메모리 최적화 i. 설정 : hash-max-ziplist-entires, hash-max-ziplist-value 기반 (자세한건 4장에서..: 괴물들이 사는 나라..(-_-?)) 2) 해시의 내부 i. 집리스트(ziplist) : 메모리 효율화에 목적을 둔 양쪽으로 연결된 리스트 정수를 일련의 문자로 저장하지않고, 실제 정수의 값으로 저장 집리스트가 메모리 최적화가 되어있다고 하더라도, 일정시간내 검색이 수행되진 않음 ii. 해시테이블(hash table) : 일정한 시간내로 검색은 되나, 메모리 최적화가 이루어지지않음