redis 설치 및 간략 체계 설명

nosql의 한 종류인 redis 실전 테스트 내용.

결론 먼저 내리자면, 다량의 키값들을 뽑아 낼 때 편리하다.

예를 들어 도서관 대출 장부라고 가정한다면, 2000년 1월 1일 ~ 2014년 11월 26일 까지 A 회원이 빌려간 도서 목록,

A회원의 방문 일자, A회원이 빌려간 도서목록과 같은 책을 빌려간 다른 회원, 목록이 이에 해당 된다.

즉, 입력된 값들에 대해 특정 구문만을 이용 결과 값을 얻는데 기존 데이터 베이스 형태의 sql보다 훨씬 빠르며, 부하율도 현저하게 낮은 값을 갖는다.

redis는 단순 키값만을 이용하는 sql로 그 사용 범위가 좁다.

레디스설치

gcc컴파일러.
커널 2.6.x 이상의 환경.

-실제 환경.

-가상화(서비스중인 share core)
-Mem 1G
-Cent 6 64bit (Linux REDIS 2.6.32-431.11.2.el6.x86_64)
——
gcc 버전 확인( x86_64 – 4.4.7-4.el6 )

설치 진행.

[root@REDIS src]# pwd
/usr/local/src

[root@REDIS src]# wget http://download.redis.io/redis-stable.tar.gz (항시 최신 버전으로 자동 업데이트되어 있음)
[root@REDIS src]# tar vxfz redis-stable.tar.gz

[root@REDIS src]# ll
total 1240
drwxr-xr-x 6 1000 1000 4096 2014-09-20 00:49 redis-stable

[root@REDIS redis-stable]# pwd
/usr/local/src/redis-stable

[root@REDIS redis-stable]# make

..
(중략)
..
Hint: It’s a good idea to run ‘make test’ 😉

make[1]: Leaving directory `/usr/local/src/redis-stable/src’
위와 같이 떨어진다면 정상 빌드된것!

<참고> 32bit 환경에서는 빌드시 다음과 같은 오류 발생.-(이미 알려진 버그)

make[1]: ***[redis-server] 오류 1
make[1]: Leaving directory ‘/usr/local/src/redis-server/src’
make: ***[all] 오류 2

해당 오류 해결 –> /usr/local/src/redis-stable/src/ 에 위치한 Makefile의 내용 수정.
첫 부분에 ‘CFLAGS=-march=i686’ 추가하면 끝~

내용참조 : http://github.com/antirez/redis/753 ( issue NO. 736 753 )

[root@REDIS src]# pwd
/usr/local/src/redis-stable/src

[root@REDIS src]# ./redis-server

[3826] 26 Sep 09:27:44.045 # Warning: no config file specified, using the default config. In order to specify a config file use ./redis-server /path/to/redis.conf
[3826] 26 Sep 09:27:44.048 * Increased maximum number of open files to 10032 (it was originally set to 1024).
_._
_.-“__ ”-._
_.-“ `. `_. ”-._ Redis 2.8.17 (00000000/0) 64 bit
.-“ .-“`. “`\/ _.,_ ”-._
( ‘ , .-` | `, ) Running in stand alone mode
|`-._`-…-` __…-.“-._|’` _.-‘| Port: 6379
| `-._ `._ / _.-‘ | PID: 3826
`-._ `-._ `-./ _.-‘ _.-‘
|`-._`-._ `-.__.-‘ _.-‘_.-‘|
| `-._`-._ _.-‘_.-‘ | http://redis.io
`-._ `-._`-.__.-‘_.-‘ _.-‘
|`-._`-._ `-.__.-‘ _.-‘_.-‘|
| `-._`-._ _.-‘_.-‘ |
`-._ `-._`-.__.-‘_.-‘ _.-‘
`-._ `-.__.-‘ _.-‘
`-._ _.-‘
`-.__.-‘

[3826] 26 Sep 09:27:44.052 # Server started, Redis version 2.8.17
[3826] 26 Sep 09:27:44.052 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add ‘vm.overcommit_memory = 1’ to /etc/sysctl.conf and then reboot or run the command ‘sysctl vm.overcommit_memory=1’ for this to take effect.
[3826] 26 Sep 09:27:44.052 * The server is now ready to accept connections on port 6379

위의 연결을 끊지 않은채 새로운 쉘을 열어 대화형 레디스 클라이언트를 실행 하여 보자

[root@REDIS src]# pwd
/usr/local/src/redis-stable/src

[root@REDIS src]# ./redis-cli
127.0.0.1:6379> info <– 명령어 실행시 레디스가 실행된 이후의 각종 통계 정보와 설정을 출력한다.

*참고 127.0.0.1:6379> <—– 접속한 아이피와 포트를 보여준다 클라이언트에 따라 달리 보이는…

127.0.0.1:6379> set key1 “smileserv cloud team redis server install test” <—요런식으로 key값을 생성.
OK
127.0.0.1:6379> get key1
“smileserv cloud team redis server install test”

127.0.0.1:6379> set key2 “connect complete ok?” <–키값 추가 예시.
OK
127.0.0.1:6379> get key2
“connect complete ok?”

* 참고 redis 의 명령어는 http://redis.io/commands 에서 확인 가능.

*set 명령어는 주어진 key에 값을 저장한다.
*append 명령어는 주어진 키가 존재하면 함께 입력된 값을 이미 저장되어 있는 제일 마지막 값의 뒤에 추가한다.

즉 > set 키이름 “문자열1” <—-형식
> set 키이름 “문자열2”
> append 키이름 “값”

> get 키이름
“키값2값”

-> 이를 실제 적용해보면 다음과 같다.

127.0.0.1:6379> set user1 “chansuk”
OK
127.0.0.1:6379> set user1 “jongha”
OK
127.0.0.1:6379> get user1
“jonghababo”
127.0.0.1:6379>

..
..
127.0.0.1:6379> mset cliudteam.master jeaminJang cliudteam.servmaster kyounghyunLee cliudteam.chief ounghoJang cliudteam.chief ounghoJang cliudteam.servchief hyukYoo cliudteam.member sanyukSun cliudteam.member2 jonghaKimmak

개별적 set으로 키값을 지정할 때와 멀티로 한번에 키값을 정할때의 차이가 있다 등록값에 “”가 없다는것!

127.0.0.1:6379> mget cliudteam.master cliudteam.servmaster cliudteam.chief cliudteam.chief cliudteam.servchief cliudteam.member cliudteam.member2
1) “jeaminJang”
2) “kyounghyunLee”
3) “younghoJang”
4) “younghoJang”
5) “hyukYoo”
6) “sanyukSun”
7) “jonghaKimmak-dung2makdung2”

위에서 등록된 키값과 등록된 키값을 불러왔을때 등록된 값의 차이를 눈여겨 볼 필요가 있다.

문제시 되는 키값은 바로 키값중 “cliudteam.chief”
cliudteam.chief의 하나의 키값에 등록값인 서로 다른 두개이다. 확인된 키값에 대한 등록값은 뒤에 입력된 younghoJang 값임을 확인할 수 있다.
결혼은 하나의 키값에는 하나의 등록값. 즉, 뒤에 입력된 값이 최종값이 된다.
이는 키값과 등록값은 1:1이 성립되며, 기존 키값에 등록된 값을 다시 같은 키값에 등록할 시에는 추가 삽입의 계념이 아닌 덮어쓰기 즉 선입력된 값은 없어지게 된다.

명령어 관이 여기까지 ( 이후 자세히)

다음은 해당 redis 클라이언트가 실행될때 응답 시간을 체크 해보도록 하자.
[root@REDIS src]# ./redis-cli –latency <– 명령이 서버로 전달되고 나서부터 응답이 돌아오기까지의 시간을 측정.부하는 없으나 오래 하지는 말아라.
min: 0, max: 1, avg: 0.15 (4873 samples)
min: 0, max: 1, avg: 0.15 (5737 samples) 등으로 출력되며 멈출때는 Ctrl+c

—-

redis의 수치 예제

127.0.0.1:6379> INCR cloud:key1 <- 등록값 부재시 해당 기본 값은 “1”
(integer) 1
127.0.0.1:6379> INCRBY cloud:key1 100
(integer) 101
127.0.0.1:6379> INCRBY cloud:key1 -50
(integer) 51
127.0.0.1:6379> DECR cloud:key1
(integer) 50
127.0.0.1:6379> DECRBY cloud:key1 49
(integer) 1
127.0.0.1:6379> DECRBY cloud:key1 -49
(integer) 50
127.0.0.1:6379>

이를 활용하여 비트연산으로 진행. –>
레디스는 비트연산을 통해 저장되는 문자열 데이터를 비트 단위로 처리할 수 있다.즉, 레디스는 각 비트의 값을 변경하고 조회할 수 있다.

이에 앞서 비트가 저장되는 위치를 살펴보자.

127.0.0.1:6379> set bitadd:key11 te
OK
127.0.0.1:6379> GETBIT bitadd:key11 0
(integer) 0
127.0.0.1:6379> GETBIT bitadd:key11 1
(integer) 1
127.0.0.1:6379> GETBIT bitadd:key11 2
(integer) 1
127.0.0.1:6379> GETBIT bitadd:key11 3
(integer) 1
127.0.0.1:6379> GETBIT bitadd:key11 4
(integer) 0
127.0.0.1:6379> GETBIT bitadd:key11 5
(integer) 1
127.0.0.1:6379> GETBIT bitadd:key11 6
(integer) 0
127.0.0.1:6379> GETBIT bitadd:key11 7
(integer) 0
127.0.0.1:6379> APPEND bit:key1 -cloud
(integer) 15
127.0.0.1:6379> set bitadd:key11 st
OK
127.0.0.1:6379> GETBIT bitadd:key11 0
(integer) 0
127.0.0.1:6379> GETBIT bitadd:key11 1
(integer) 1
127.0.0.1:6379> GETBIT bitadd:key11 2
(integer) 1
127.0.0.1:6379> GETBIT bitadd:key11 3
(integer) 1
127.0.0.1:6379> GETBIT bitadd:key11 4
(integer) 0
127.0.0.1:6379> GETBIT bitadd:key11 5
(integer) 0
127.0.0.1:6379> GETBIT bitadd:key11 6
(integer) 1
127.0.0.1:6379> GETBIT bitadd:key11 7
(integer) 1

여기에서 처음에 저장한 smileserv 와 두번째 append에 의해 저장해준 cloud를 이 진수로 나타낸다면

te:01110100
test:01110100 01110011 <-append로 추가될때 먼저 저장된 비트는 삭제 되지 않고 뒤에 추가 되는 형식으로 비트가 나열된다.

즉 te의 이진수의 표현은 01110100이며 st의 이진수 표현은 01110011이되어
test의 이진수는 0111010001110011이 된다.(1바이트는 8자리 2바이트는 16자리 <–이것에 대한 비트 오프셋 최상위 값은 15 ( 0부터 시작이므로))
그러므로 setbit로 최대한 표현될 수 있는 크기인 512MB에 대한 제한은 고려되어야 한다.

-책자에 의하면 해당 사항을 활용할 수있는것을 관계형 테이터 베이스의 구축비용대비 훌륭하다고 나타낸 글이 있다.
오늘 로그인 했는지 확인하여야 할 회원수가 천만명이고 5분동안 십만 명이 로그인할 때 이를 확인 하기 위해 관계형 데이터 베이스의 경우 수억깨진다.
하지만 redis 빛을 바람.
문자열의 비트수를 on/off 스위치로 생각해볼때.
사용자의 아이디를 숫자로 바꾸어 비트연산의 오프셋값과 대응시키면 사용자가 로그인을 하면 사용자의 아이디에 해당하는 오프셋 스위치를 on으로 바꾼다.

‘ 사용자 로그인 요청 -> 오늘 날짜의 로그인 키를 만든다 exlogin:20141001
-> 사용자 번호에 해당하는 오프셋에 로그인 상태를 표시하기 위해 비트를 1로 바꾼다.
-> 오늘 로그인한 사용자의 수를 확인한다.

[polldaddy rating=”7739789″]