Data Science Lab

NoSQL 특징및 분류

NoSQL은 아래와 같은 속성을 가지고 있다.

·       Key-Value (키-밸류) 값 또는 이를 응용한 데이터 모델

·       상대적으로 값싼 다수의 하드웨어를 이용

·       데이터는 분산된 노드에 파티션 및 복제되어 저장

·       데이터의 정합성 보다 단절내성에 대한 요구사항에 목적

·       2단계 커밋의 트랜잭션 수준보다, 정족수 기반의 트랜잭션 선호

데이터 모델은 아래와 같이 분류 할 수 있다.

·       Key-Value : 가장 단순한 데이터 모델로, 키와 바이너리 타입의 값을 저장소에 저장하는 구조이며, 데이터 조회또하 키로만 조회할 수 있다.

·       Column :  관계형 데이터베이스와 비슷하게 데이터는 컬럼에 저장되며, 트에빌, 컬럼등과 같은 스키마가 존재한다.

·       Document :  데이터의 저장단위가 문서가 되며 하나의 무서 내에는 여러 개의 필드와 필드에 대응하는 값이 있다.

·       Graph :  그래프에 있는 노드와 엣지를 저장하고 이를 쉽게 네비게이션할 수 있는 모델을 제공한다.

아래 표는 데이터 모델에 대한 대표적인 솔루션들이다.

대부분의 NoSQL은 분산된 서버에 데이터를 저장한다. 이때 분산을 어떻게 하느냐에 따라 크게 메타데이터방식과 P2P 방식으로 분류할 수 있다.

·       메타데이터 : 데이터의 배치 정보가 중앙 집중적인 데이터 서버나 마스터 서버에 저장되어 있으며, 클라이언트는 데이터 연산을 위해 중앙(마스터) 서버를 경유해 실제 데이터를 처리할 서버로 접속하는 방식이다. 데이터 정보를 중앙에서 관리하기 때문에 관리가 편하며 맵리듀스와 결합하기도 용이하다. 단점으로는 중앙(마스터) 서버가 문제가 생기거나 데이터 관리 테이블에 문제가 발생하면 전체 데이터에 접근할 수가 없다. 대표적으로 빅테이블, 몽고DB 등이 이 방식을 사용한다.

·       P2P : 별도의 메타 정보가 없으며 해시 함수를 이용해 특정 키를 서비스하는 서버를 찾는 방식. 메타 정보를 관리하는 서버가 없기 때문에 장애범위가 지역적이다. 하지만 저장된 데이터를 이용해 분석 작업을 하는 경우 메타데이터 방석보다 어렵다.

파일 저장 방식에 따라 2가지로 구분할 수 있다.

·       데이터 파일은 분산 파일 시스템에 저장하고, 데이터 관리 시스템에서는 논리적인 관리만 담당하는 방식은 데이터의 복제, 장애 발생시 복제본의 재생성등은 분산 파일 시스템에서 제공하는 기능을 이용한다. 빅테이블, 클라우데이터, HBase 등이 있다.

·       데이터 관리 시스템 자체적으로 데이터 파이을 저장하는 방식은 데이터 관리 시스템 자체적으로 복제, 장애 시 복구 등에 대한 기능을 담당한다. 대부분의 NoSQL 솔루션들이 이 방식을 사용한다.

2020-06-08 / Sungwook Kang / http://sungwookkang.com

NoSQL, 분산 데이터 저장, NoSQL 특징, NoSQL 분류, 분산처리, 메타데이터, 데이터노드

CAP 이론

관계형 데이터베이스는 ACID 속성을 가지고 있으며 안전하게 저장하고 정합성을 보장하는데 주목적이 있다.

·       Atomicity(원자성) : 트랜잭션과 관련된 모든 작업들이 정상적으로 수행 되었는지, 아니면 모든 작업들이 수행되지 않았는지를 보장한다. 원자성은 중간 단계까지 실행되고 실행이 실패하는 일은 없도록 한다.

·       Consistency(일관성) : 트랜잭션 실행이 성공적으로 완료되면 언제나 일관성 있는 데이터베이스 상태로 유지한다.

·       Isolation(고립성) : 트랜잭션이 실행되는 동안 다른 트랜잭션의 작업이 끼어들지 못하게 보장한다. 즉, 다른 트랜잭션에서 중간단계의 데이터를 확인할 수 없다.

·       Durability(지속성) : 성공적으로 수행된 트랜잭션은 영원히 유지되어야 한다.

최근 하드웨어가 발전하고, 검색 서비스, SNS 서비스 같은 대규모 데이터 처리 및 장애 상황에서도 서비스를 유지해야하는 특성을 반영하여 BASE 라는 속성에 맞는 데이터 관리 시스템이 필요로 하게 되었다.

·       Basically Available : 언제든지 데이터에 접근할 수 있는 속성

·       Soft state : 특정 시점에서는 데이터 일관성이 보장되는 않는 속성

·       Eventually consistent : 일정시간이 지나면 데이터의 일관성이 유지되는 속성

결국 확장성과 고가용성을 제공해야하지만, 표준 SQL이나 엔티티 간의 관계를 지원하지 않는 데이터 관리 시스템이 등장하게 되었으며, 이러한 시스템을  NoSQL이라고 한다. 분산환경의 NoSQL 시스템을 구성할 경우 CAP 이론이라는 것이 있다.

·       Consistency (정합성) : 모든 클라이언트는 항상 동일한 데이터를 보장 받는 속성

·       Availability (가용성) : 네트워크 단절 상황에서도 장애가 발생하지 않은 노드는 모든 요청에 대해서 정해진 시간 내에 응답해야하는 속성

·       Partition Tolerance (단절내성) : 네트워크가 단절된 상태에서도 시스템의 속성(정합성이나 가용성)을 유지해야한다는 속성. 분산환경에서는 네트워크상에 서버들이 분산배치되기 때문에 이 속성은 반드시 포함해야하는 속성이다.

CAP 이론은 CAP 속성을 정의한것으로 “적절한 응답 시간내에 세 가지 속성을 모두 만족시키는 분산 시스템을 구성할 수 없다”라고 정의한 이론이다.

관계형 데이터베이스는 정합성(C)과 가용성(A)에 초점이 맞춰져 있는 반면, NoSQL 솔루션들은 가용성(A) – 단절내성(P) 또는 정합성(C)-단절내성(P) 특성을 제공한다. CAP 이론에 따라 분산된 환경에서는 세 가지 속성을 동시에 만족시킬 수 없기 때문에 저장되는 데이터의 속성과 요구사항을 파악해 요구사항에 어떤 속성을 갖는지를 알아야 한다.

2020-06-07 / Sungwook Kang / http://sungwookkang.com

NoSQL, 분산 데이터 저장, CAP이론, Consistency, Availability, Partition Tolerance

 Redis Memory LFU(Least Frequently Used) 캐시

·       Version : Redis 4.0

Redis 4.0 부터 제공되는 LFU 알고리즘 캐시는 자주 참조되는 데이터만 배치하고 그렇지 않은 데이터들은 메모리로부터 제거하여 자주 사용되는 데이터들이 메모리에 배치되도록하는  알고리즘이다. LRU 알고리즘은 최근에 액세스 했지만 실제로는 거의 요청하지 않는 항목에 대해서도 메모리에 보관하고 자주 요청되는 키에 대해서는 만료가 되기 때문에 의도하지 않은 성능이 나타날 수도 있다.

LFU는 Approximated LRU와 유사하다. 모리스 카운터라고 하는 확률적 카운터를 사용하여 개체의 액세스 빈도를 계산하고 감쇠 기간과 결합하여 시간이 지남에 따라 카운터가 감소한다. 알고리즘은 액세스 패턴의 변화를 확인하고 과거에 액세스가 있었지만 자주 액세스되지 않는 키는 삭제 후보로 선정한다. 이러한 방법은 LRU에서 발생하는것과 유사하게 샘플링된다. 그러나 LRU와 달리 LFU에는 특정 조정가능한 매개변수가 있다. 예를들어 더 이상 객체에 액세스하지 않게 되면 랭크를 얼마나 빨리 감소 시킬것인지 설정할 수 있다. Redis 4.0은 기본적으로 아래와 같이 구성된다.

·       100만건의 요청에 카운터를 포화시킨다.

·       카운터를 1분마다 감쇠한다.

카운터 범위 조정은 Redis.conf 파일에 아래와 같이 관련 파라메터를 수정한다.

·       lfu-log-factor 10 (기본값 10)

·       lfu-decay-time 1

lfu-decay-time의 변수값은 분(minute)로 사용되며 0으로 설정할 경우 항상 카운터를 스캔할 때마다 카운터를 감소시킨다.

lfu-log-factor의 범위는 0-255이며,  factor가 높을수록 최대 값에 도달하기 위해 더 많은 액세스가 필요하다. Hits 값은 사용자가 메모리로부터 데이터를 재참조한 값으로 높을 수록 좋다. 아래 표에서는 팩터가 10일때 1M 이상의 힛트가 발생하는 경우 가장 이상적인 것을 확인할 수 있다..

[참고자료]

·       https://redis.io/topics/lru-cache

·       Approximate counting algorithm : https://en.wikipedia.org/wiki/Approximate_counting_algorithm

2019-06-06 / Sungwook Kang / http://sungwookkang.com

Redis, Redis Architecture, 레디스 메모리, Redis LFU, LFU 알고리즘, Least Frequently Used, 레디스 메모리 공간 확보, 레디스 메모리 제거

 Redis Memory LRU(Least Recently Used) 캐시

·       Version : Redis 3.2.100 (Windows)

Redis에서 캐시로 사용되는 알고리즘으로 LRU(Least Recently Used)를 사용한다.  LRU 알고리즘은 최근에 사용된 데이터들은 재사용이 될 가능성이 높다고 판단하여 계속해서 메모리에 상주 시킬수 있도록 재배치 하는 작업이다.  LRU 알고리즘으로 Redis 서버 인스턴스를 운영하기 위해서는CONFIG SET 명령어 또는  redis.conf 파일에서 아래 파라메터를 수정한다.

·       maxmemory <bytes>

·       maxmemory-samples 5

maxmemory 파라메터는 Redis 서버에 할당할 수 있는 최대 메모리 크기이며, 이 값을 0로 설정할 경우 최대 메모리 한계가 없어진다. 32 bit 시스템에서는 암시적으로 메모리 제한이 3GB 를 사용한다.

maxmemory-samples 파라메터는 LRU 알고리즘에서 퇴거(eviction)를 검사할 샘플 수 이다.

Redis 메모리의 상주 데이터를 삭제하는 종류는 몇 가지가 있으며 memory-policy  구문을 사용하여 아래와 같은 정책을 적용할 수 있다.

·       noeviction : 메모리 제한에 도달한 상태에서 클라이언트가 더 많은 메모리를 사용하는  명령을 실행하려고 할 때 오류를 리턴한다. (대부분 쓰기 명령 및 DEL 명령시 발생한다.)

·       allkeys-lru : 가장 최근에 사용하지 않는 키(LRU)를 먼저 퇴거(eviction)하여 새로운 데이터를 위한 공간을 확보한다.

·       volatile-lru :  가장 최근에 사용되지 않은 키(LRU)를 먼저 퇴거(evict)하려고 시도하지만 만료 세트가 있는 키만 퇴거하여 새로운 데이터 공간을 확보한다.

·       allkeys-random : 새 세이터를 추가할 공간을 만들기 위해 임의로 키를 퇴거(evict)한다.

·       volatile-random :  새 데이터를 추가하기위한 공간을 만들기 위해 무작위로 키를 퇴거(evict)하지만 만료 세트가 있는 키만 제거한다.

·       volatile-ttl : 만료 세트가 있는 키를 제거하고 TTL(Short Time to Live)키를 제거하여 새로운 데이터를 추가 공간을 확보한다.

volatile-lru, volatile-random 및 volatile-ttl 정책은 필수 구성요소와 일치하는 키가 없으면 아무런 행동을 하지 않는다. 올바른 퇴거 정책을 수립하기 위해서는 Redis INFO 정보를 모니터링하여 정책에 반영할 수 있도록 한다.

·       요청이 많으며 과거 데이터를 자주 사용하지 않는다면 allkeys-lru  정책을 사용한다.

·       모든 키가 연속적으로 스캔되는 순환 액세스가 있거나 배포가 균일할 것으로 예상되는 경우 (모든 요소는 동일한 확률로 액세스 될 가능성이 높음) allkeys-random을 사용한다.

·       캐시 개체를 만들 때 다른 TTL 값을 사용하여 만료 기간이 좋은 항목에 대한 힌트를 Redis에 제공하려면 volatile-ttl을 사용한다.

volatile-lru 및 volatile-random 정책은 캐싱 및 영구 키 집합에 대한 단일 인스턴스를 사용하려는 경우 유용하다. 그러나 일반적으로 이러한 문제를 해결하기 위해 두 개의 Reids 인스턴스를 실행하는 것이 좋다. 또한 키에 만료를 설정하면 메모리가 낭비되므로 allkeys-lru와 같은 정책을 사용하면 메모리가 부족할 때 키가 만료되도록 설정할 필요가 없기 때문에 더 많은 메모리가 효율적으로 운영된다.

Redis LRU 알고리즘은 정확한 구현이 아니다. 이뜻은 Redis가 퇴출을 위한 최선의 후보, 즉 과거에 가장 많이 액세스 된 액세스를 선택할 수 없음을 의미한다. 대신 LRU 알고리즘의 근사치를 실행하거나 소수의 키를 샘플링 하고 샘플링된 키 중에서 가장 오래된 액세스 시간(가장 오래된 액세스 시간)을 제거하려고 시도한다. 그러나 Redis 3.0 이후 알고리즘은 개선 된 퇴거 후보자를 확보하기 위해 개선되었다. 이로 인해 알고리즘의 성능이 향상되어 실제 LRU 알고리즘의 동작을 보다 자세히 근사할 수 있게 되었다.

Redis가 진정한 LRU 구현을 사용하지 않는 이유는 더 많은 메모리가 필요하기 때문이다. 그러나 근사값은 Redis를 사용하는 응용프로그램과 거의 같다. 다음은 Redis에서 사용한 LRU 근사값과 실제 LRU를 비교하는 방법을 그래픽으로 비교한 것이다.

위 그림에서 연한 회색은 퇴거된 영역이며, 회색은 퇴거되지 않은 대상이다. 녹색은 추가된 객체이다. 시뮬레이션에서 지수법 접근 패턴을 사용하여 실제  LRU와 Redis 근사값 간의 차이가 미미하거나 존재하지 않는다는 것을 발견했다. 그러나 실제 LRU를 근사하게 비교하고 캐시 미스 비율에 차이가 있는지 확인하기 위해 몇 가지 추가 CPU 사용량을 희생시켜 샘플 크기를 10으로 늘릴 수 있다.

[참고자료]

https://redis.io/topics/lru-cache

2019-06-03 / Sungwook Kang / http://sungwookkang.com

Redis, Redis Architecture, 레디스 메모리, Redis LRU, LRU 알고리즘, Least Recently Used, 레디스 메모리 공간 확보, 레디스 메모리 제거

 Redis Memory 정보

·       Version : Redis 3.2.100 (Windows)

Redis에서 info명령은 서버의 각종 통계 및 상태를 보여준다. 다양한 매개 변수를 사용하여 특정 정보를 확인할 수 있으며 이번 포스트에서는 메모리 관련 정보를 확인해본다.

Redis에 접속하여 Redis info 명령을 실행하면 메모리 관련 사용 정보를 반환한다.

·       *_human 값은 동일 항목의 byte 값을 Kbyte로 변환하여 나타낸 값

이상적으로 used_memory_rss 값은 used_memory 보다 약간 높아야 한다. rss >>를 사용하면 mem_fragmemtation_ratio 를 검사하여 메모리 조각화(내부 또는 외부)가 있는지 확인할 수 있다.  >> rss를 사용하면 Redis 메모리의 일부가 운영체제에 스왑 아웃을 되었다는 것을 의미한다. 이 뜻은 지연이 있다는 것을 의미한다.

Redis는 메모리 페이지에 매핑되는 할당 방식을 제어할 수 없으므로 높은 used_memory_rss는 메모리 사용이 급증하여다는 것을 의미한다. Redis가 메모리를 해제하면 메모리는시스템에 메모리를 반환하거나 하지 않을 수 있다. 따라서 운영체제에서 보고한 used_ memory값과 메모리 소비간에 불일치가 있을 수 있다. used_memory_peak  값은 일반적으로 이 지점을 확인하는데 유용하다.

서버의 메모리에 대한 추가 정보는 memory stats 명령과 memory doctor를 참조하여 확인할 수 있다.

[참고자료]

https://redis.io/commands/INFO

2019-05-20 / Sungwook Kang / http://sungwookkang.com

Redis, Redis Architecture, 레디스 메모리, 레디스 메모리 사용량, 메모리 모니터링, Redis, info memory

 Redis Architecture

·       Version : Redis 3.2.100 (Windows)

아래 그림은 Redis Server Architecture 이며, 크게 3가지 영역인, 메모리, 파일, 프로세스 영역으로 구성되어 있다.

[메모리 영역]

·       Resident Area (Working Set) : 사용자가 Redis 서버에 접속해서 처리하는 모든 데이터가 가정 먼저 저장되는 영역이며 실제 작업이 수행되는 영역.

·       Data Structure : Redis를 운영하기 위한 다양한 정보를 저장하고 관리하기 위한 영역.

[파일 영역]

·       AOF 파일 : 메모리에 저장된 사용자 데이터를 파일에 기록하는 영역 (스냅샷 데이터)

·       DUMP 파일 : 소량의 데이터를 일시적으로 저장할때 사용하는 영역

[프로세스 영역]

·       Server Process : redis-server.exe 또는 redis-sentinel.exe  실행 코드에 의해 활성화되는 프로세스이며, Redis 인스턴스 관리 및 사용자 요청 작업을 처리한다. 4개의 멀티 스레드로 구성된다.

ü  Main Thread : Redis 서버에서 수행되는 대부분의 명령어와 이벤트 처리

ü  BIO-Close-FILE  : AOF(Append Only File)에 데이터를 Rewrite 할때 기존 파일은 Close 하고 새로운 AOF 파일에  Write할 때 사용.

ü  BIO-AOF-Resync : AOF에 쓰기 작업을 수행할 때 사용

ü  BIO-LAZY-Free : unlink, FLUSHALL, FLUSHDB 명령어를 실행할 때 빠른 성능을 보장하기 위해 백그라운드에서 사용

·       Client Process : redis-cli.exe 또는 사용자 애플리케이션에 의해 실행되는 명령어를 실행하기 위해 제공되는 프로세스.

[참고자료]

https://docs.redislabs.com/latest/rs/concepts/

2019-05-14 / Sungwook Kang / http://sungwookkang.com

Redis, Redis Architecture, 레디스 아키텍처, 레디스 스레드, 레디스 프로세스, 레디스 메모리 아키텍처

 Redis 데이터 타입 – Geo

·       Version : Redis 3.2.100 (Windows)

Redis 의 Geo 데이터 타입은 위치정보(위도, 경도) 데이터를 효율적으로 저장하고 사용할 수 있다.  geoadd, geopos, geodist, georadius, geohash 명령어를 사용한다.

[geoadd]

데이터를 저장한다.

[geopos]

데이터를 검색한다

[geodist]

두 맴버간의 거리를 반환

[georadius]

중심위치로 부터 최대 거리(반지름)으로 지정된 경계 내에 있는 목록을 반환

[참고자료]

https://redis.io/commands

2019-05-14 / Sungwook Kang / http://sungwookkang.com

Redis, Redis 입,력geoadd, geopos, geodist, georadius, geohash데이터 타입, 위치정보, 레디스 위치 정보,

 Redis 데이터 타입 – bit

·       Version : Redis 3.2.100 (Windows)

Redis 의 bit는 0과 1로 표시하며 setbit, getbit, bitcount 명령어를 사용한다.

[setbit]

데이터를 저장한다.

[getbit]

데이터를 검색한다.

[bitcount]

키 범위내의 value 카운트를 나타낸다.

[참고자료]

https://redis.io/commands

2019-05-09 / Sungwook Kang / http://sungwookkang.com

Redis, Redis 입력, setbit, getbit, bitcount, redis 데이터 타입, redis sorted set 데이터 타입, 레디스 데이터 타입, 레디스 bit,  레디스 비트값 저장

 Redis 데이터 타입 – Sorted Set

·       Version : Redis 3.2.100 (Windows)

Redis 의 Sorted Set 데이터 타입은 Set과 동일한 구조이며 차이점은 데이터가 정렬된 상태로 저장된다는 것이다. 명령어는 zadd, zrange, zcard, zcount, zrank, zrevrank를 사용한다.

[zadd]

데이터를 저장할때 zadd 명령을 사용한다.

[zrange]

키 범위에 데이터를 검색한다.

[zcard]

저장된 value 개수는 scard 명령을 사용한다.

[zcount]

키 범위내의 value 카운트를 나타낸다.

[zrem]

저장되어 있는 value를 삭제 한다.

[zrank]

Data가 저장된 value의 rank를 나타낸다.

[zrevrank]

Data가 저장된 value의 rank를 표시하되 리버스된 rank 값을 나타낸다.

[zscore]

데이터가 저장된 시점의 value 포인터를 나타낸다.

[참고자료]

https://redis.io/commands

2019-05-02 / Sungwook Kang / http://sungwookkang.com

Redis, Redis 입력, zadd, zrange, zcard, zcount, zrank, zrevrank, redis 데이터 타입, redis sorted set 데이터 타입, 레디스 데이터 타입, 레디스 sorted set, 정렬데이터 저장

 Redis 데이터 타입 - Set

·       Version : Redis 3.2.100 (Windows)

Redis 의 Set 데이터 타입은 Element 단위로 저장한다. Set 타입의 데이터를 핸들링할 때에는 sadd, smembers, scard, sdiff, sunion 명령어를 사용한다.

[sadd]

데이터를 저장할때 sadd 명령을 사용한다.

[smembers]

Set 으로 저장된 데이터 검색은 smembers 명령을 사용한다.

[scard]

저장된 value 개수는 scard 명령을 사용한다.

[sdiff]

Key의 엘레멘트를 비교하여 전자의 key에만 있는 value를 출력한다. 아래 예제는 order 와 order_new 를 비교해서 order에만 있는 value를 출력한다.

[sdiffstore]

Key의 엘레멘트를 비교하여 전자의key에만 있는 value를 다른 key의 엘레멘트로 저장한다. 아래 예제는  order와 order_new를 비교하여 order 에만 있는 value를 order_diff 로 저장한다.

[sunion]

Key의 엘레멘트의 value를 합쳐서 출력한다.

[sunionstore]

Key의 엘레멘트의 value를 합쳐서 다른 key로 저장한다.

[srem]

저장되어 있는 value를 삭제 한다.

[spop]

저장되어 있는value 에서 random으로 삭제한다.

[참고자료]

https://redis.io/commands

2019-04-29 / Sungwook Kang / http://sungwookkang.com

Redis, Redis 입력, sadd, smembers, scard, sdiff, sunion, redis 데이터 타입, redis set 데이터 타입, 레디스 데이터 타입, 레디스 set

 Redis 데이터 타입 - List

·       Version : Redis 3.2.100 (Windows)

Redis 의 List 데이터 타입은 배열(Array) 과 비슷한 데이터 구조이다. List 타입의 데이터를 핸들링할 때에는 lpush, lrange, rpush, rpop, llen, lindex 명령어를 사용한다.

[lpush]

List 타입은 하나의 key에 여러 개의 value를 저장할 수 있다.

[lrange]

List 형태의 데이터를 검색할때 lrange 명령어를 사용한다. 명령어 사용시 key, start, stop 값을 함께 사용한다. 아래 스크립트는 0 -10개의 리스트값을 검색한다.

[rpush]

List데이터 타입에서 기존에 저장되어 있는 데이터 마지막에 새로운 value 를 저장할때 rpush 명령어를 사용한다.

[lpushx]

타입에서 기존에 저장되어 있는 데이터 맨 앞에 새로운 value 를 저장

[linsert]

Value 와 value 사이에 값을 끼워넣는다. 아래 스크립트는 <item_id>3</item_id>앞에 <item_id>5</item_id> 값을 끼워 넣는다.

[lset]

특정 key 의 인덱스에 해당하는 value 값 변경

[rpop]

마지막에 저장된 values값을 제거

[llen]

저장된 values의 개수를 출력

[lindex]

검색하려는 key의 특정 인덱스 위치에 저장된 데이터 검색

[참고자료]

https://redis.io/commands

2019-04-26 / Sungwook Kang / http://sungwookkang.com

Redis, Redis 입력, hget, hmset, hmget, redis 데이터 타입, redis list 데이터 타입, 레디스 데이터 타입, 레디스 리스트

 Redis 데이터 타입 - Hash

·       Version : Redis 3.2.100 (Windows)

Redis 에서 데이터를 저장할때, 하나의 key 에 여러 개의 Value를 저장할때에는 Hash 데이터 타입을 사용할 수 있다. Hash 데이터 타입은 하나의 key 에 하나 이상의 value 값을 콜론(:)으로 구분하여 데이터를 저장할 수 있다. 기본적으로 필드의 갯수는 제한이 없으며, Value 값에 문자열을 사용할 때는 “string”를 사용한다.

[hmset / hget / hmget]

Hash 타입의 데이터를 입력할때 hmset 명령어를 사용한다. 데이터를 검색할 때에는 hget 명령어를 사용한다.

Key에 정의된 특정 필드의 value만 출력할 때에는 hmget 을 사용한다.

[hgetall]

특정 key 값의 모든 필드와 value를 검색할 때에는 hgetall 명령을 사용한다.

[hkeys / hvals]

Key에 대한 모든 field 명을 출력할 때에는 hkeys 명령어를 사용하고, key에 대한 모든 value만 출력할 때에는 hvals 를 사용한다.

[hexists]

Key 와 field값으로 필드의 존재 유무를 확인할 때는 hexists 명령어를 사용한다. 반환되는 값이 1이면 검색한 필드가 존재하며 0이면 존재하지 않는 필드이다.

[hdel]

Key에 대한 특정 필드를 삭제 하려면 hdel 명령을 사용한다. Item_name의 필드와value가 삭제된 것을 확인할 수 있다다.

[참고자료]

https://redis.io/commands

2019-04-25 / Sungwook Kang / http://sungwookkang.com

Redis, Redis 입력, hget, hmset, hmget, redis 데이터 타입, redis hash 데이터 타입, 레디스 데이터 타입, 레디스 해시

 Redis 데이터 입력, 수정, 삭제, 조회

·       Version : Redis 3.2.100 (Windows)

Redis는 키밸류(Key-Value) 시스템으로 데이터를 입력,수정,삭제,조회를 하기 위해서는 Redis에서 제공하는 명령어를 사용해야 한다. 아래 실습을 통해서 데이터를 핸들링하는 방법에 대해서 알아본다.

[set]

데이터를 저장할 때에는 set 명령을 사용한다.

[get]

데이터를 검색할 때에는 get 명령을 사용한다.

[rename]

저장된 key 값을 변경할 때에는 rename 명령을 사용한다.

[keys]

저장된 모든 키를 검색할때 key 명령을 사용한다.

[randomkey]

저장된 key 중에 하나의 랜덤한 key를 검색할 때 randomkey 명령을 사용한다.

[exists]

검색 하려는 key가 존재하는지 여부를 확인할때 exists 명령어를 사용한다. 반환되는 값이 1이면 존재하는 키값이며, 0이면 존재하지 않는 키값이다.

[strlen]

검색하려는 key의 value 길이를 확인할때 strlen 명령을 사용한다.

[flushall]

 현재 저장되어 있는 모든key를 삭제 할 때에는 flushall 명령을 사용한다.

[setex]

데이터를 입력할때  일정 시간이 지나 자동으로 삭제하는 명령은 setex 이다. 시간 단위는 초(second)이다. 데이터 입력후 ttl key를 사용하면 삭제 되기 까지의 시간을 확인할 수 있다.

[mget / mset]

여러개의 key와 value를 한번에 검색/저장할때에는 mget / mset 명령어를 사용한다. mset 명령어 사용시 데이터가 입력 순서대로 저장된다는 보장은 없다.

[append]

현재 value 값에value를 추가할때에는 append 명령어를 사용한다.  추가하려는 value에 첫 공백이 없을 경우 기존의 값 앞 부분에 추가가 되면 공백이 있을경우 기존 값의 뒷 부분에 추가 된다.

[incr / decr]

특정 key 값의 value 값에 대한 증가 또는 감소 값을 가져올때 incr / decr 명령을 사용한다.

[save]

현재 입력되어 있는  key, value 값을 파일러 저장할 때에는 save명령어를 사용한다. Save 명령으로 저장된 데이터는 Redis 폴더의 dump.rdb파일로 생성된다.

[참고자료]

https://redis.io/commands

2019-04-24 / Sungwook Kang / http://sungwookkang.com

Redis, Redis 입력, get, set, mget, mset, flushall, keys, append, redis 조회, redis 데이터 수정

 Redis - redis-cli를 사용한 Redis Server접속

·       Version : Redis 3.2.100 (Windows)

Redis가 설치 되어 있으면 설치되어 있는 폴더에서 redis-cli.exe를 사용하여 Redis 서버에 접속할 수 있다. 이때 Redis 인스턴스를 활성화 할 때 사용했던 포트 번호를 -p 옵션과 함께 사용한다.

Redis-Shell에서 실행할 수 있는 명령어 리스트를 조회하려면 help를 입력한다.

help 명령어와 함께 실행할 명령어를 입력하면 해당 명령어의 자세한 사용법이 표시 된다.

[참고자료]

https://redis.io/documentation

2019-04-23 / Sungwook Kang / http://sungwookkang.com

Redis, Redis install for windows,  redis-cli, redis 접속

Redis 설치 (Windows)

·       Version : Redis 3.2.100

Redis는 (글을 쓰는 현재)공식적으로 Windows 버전을 지원하지 않는다. 하지만 공식 사이트를 살펴 보면 Microsoft에서 Win-64 port를 개발하고 유지한다고 한다.

·       Redis : https://redis.io/topics/introduction

Redis 공식 사이트에서 안내되어있는 링크를 클릭하면 MicrosoftArchive 깃헙으로 연결된다. 아래 깃헙에서 필요한 버전을 다운받아서 설치 한다.

·       Redis for Windows :  https://github.com/MicrosoftArchive/redis/releases

Redis 설치가 완료되면 Task Manager – Services 탭에서 Redis 서비스가 실행중인것을 확인할 수 있다.

[참고자료]

·       https://redis.io/topics/introduction

·       https://github.com/MicrosoftArchive/redis/releases

2019-04-22 / Sungwook Kang / http://sungwookkang.com

Redis, Redis install for windows,  MicrosoftArchive, 레디스, 레디스 설치, NoSQL, Memory DB

Cassandra 설치

• Version : Windows / Cassandra 2.1.14

Cassandra DB(이하 카산드라) 를 설치하기 위해서는 Apach Software에서 다운로드 받을 수 있다. 아래 링크를 클릭하여 카산드라를 다운로드 받아 설치 한다. 최신 버전을 설치하여도 좋지만 필자의 생각으로는 각 버전에 따른 호환성을 잘 고려해서 설치 버전을 선택 할 수 있도록 한다.

• Cassandra download : http://cassandra.apache.org/

카산드라를 실행 하기 위해서는 JAVA 6 (java 1.6) 이상의 버전이 필요하다. JAVA 버전을 확인 후 필요에 따라 최신 버전을 설치 한다. 아래 링크를 클릭하여 JAVA를 다운로드 받는다.

• Free Java Download : https://www.java.com/en/download/

다운로드 받은 카산드라 DB 압축 파일을 해제하고 사용자 환경는 폴더에 압축 해제한 파일을 위치한다. (필자의 경우 C:\Cassandra 에 위치 하였다.)

카산드라 파일에 대한 위치 선정이 완료되면 시스템 속성의 환경 변수에서 JAVA_HOME및 CASSANDRA_HOME 설정을 한다.

PATH 설정에서 다음과 같이 환경 변수를 등록 한다.

PATH 설정이 완료되면 커맨드창을 하나 실행하여실행하여 카산드라가 위치한 디렉토리로 이동하여 카산드라를 실행 한다. (카산드라도 PATH설정을 하였을 경우 어느 경로 상관없이cassandra라고 실행하면 된다.)

카산드라가 실행되면 카산드라의 버전, 사용포트 등의 정보가 표시 된다. 카산드라 실행시 사용할 포트 및 각종 설정에 대한 정의는 conf 폴더의 cassandra.yaml 파일에서 설정 할 수 있다. (자세한 내용은 추후 다루도록 한다.)

카산드라의 버전을 확인 하는 명령문으로는 아래와 같이 실행한다.

2016-09-26 / 강성욱 / http://sqlmvp.kr

카산드라 DB, nosql, Cassandra, key values, 카산드라 설치