NoSQL의 개념과 필요성

1960년대 컴퓨터가 처음 발명된 이후 인류는 수 많은 데이터를 양산하고 있으며, 이를 효과적으로 저장 관리해 오고 있습니다. 하지만 기존의 File System과 DBMS로는 오늘날 기하급수적으로 증가하는 데이터를 처리하기에는 많은 부담과 문제가 있습니다. 특히 장비의 성능이 좋을수록 성능을 향상(Scale-up: 수직적 확장)시키는 비용이 기하급수적으로 증가하기 때문입니다.

따라서 2000년대 초반, 여러대의 컴퓨터에 데이터를 분산하여 저장하는 것(Scale-out: 수평적 확장)을 목표로 NoSQL이라는 새로운 관리 기술이 등장하게 됩니다.

기존 관계형 DBMS는 Client/Server 플랫폼을 기반으로 한다면 NoSQL은 이에 Client/Server 플랫폼과 Cloud Computing 플랫폼 모두 기반으로 합니다. 여기서 Not only SQL의 의미를 확인 할 수 있습니다.

특징

  1. Cloud Computing 환경에 적합합니다.
  2. 유연한 데이터 모델입니다.
  3. 빅데이터 처리에 효과적입니다.

데이터 구조에 따른 구분

  1. Key-Value
  2. Column-Family
  3. Document
  4. Graph

CAP 이론

CAP 이론은 분산 데이터베이스 시스템에서 의미있는 이론입니다. 분산 데이터베이스의 세 가지 속성인 일관성(Consistency), 가용성(Availability), 네트워크 파티션 허용(Partition Tolerance)을 나타냅니다.

CAP 이론과 이를 보완한 PACELC 이론에 대한 자세한 내용은 Ohjongsung's Dev Story에 있습니다.

Redis

  • REmote DIctionary System (인메모리 원격 캐시 서버)
  • In-Memory 기반의 데이터 저장 구조입니다.
  • 명시적으로 삭제, Expire를 설정하지 않으면 데이터는 삭제되지 않음
  • 여러대의 서버 구성이 가능

메모리를 이용하여 고속으로 <key, Value> 스타일의 데이터를 저장하고 불러올 수 있는 원격 시스템

Value가 갖는 다양한 Data type

  1. String 일반적인 문자열

  2. Set string의 집합으로 여러개의 값을 하나의 value에 넣을 수 있다.

  3. Sorted Set Set + Score(가중치),오름차순으로 내부 정렬 된다.

  4. Hashes field/string value 쌍으로 이루어진 테이블을 저장하는 데이터 구조체

  5. List string들의 집합으로 저장되는 형태는 set과 유사, 일종의 양방향 Linked List

Persistence(데이터 저장)

Snapshotting(RDB)

순간적으로 메모리에 있는 내용을 disk 전체에 옮겨 담는 방식
1) SAVE 순간적으로 redis의 모든 동작을 정지시키고 그때의 snapshot을 disk에 저장(blocking 방식)
2) BGSAVE 별도의 process를 띄워 명령어 수행 당시의 메모리 snapshot을 disk에 저장(non-blocking 방식), 이 때 redis는 정지하지 않고 정상적으로 동작

  • 장점: 메모리의 snapshot을 그대로 뜬 것이기 때문에, 서버 restart시 snapshot만 load하면 되므로 restart 시간이 빠르다.
  • 단점: snapshot을 추출하는데 시간이 오래 걸리며, snapshot 추출된후 서버가 down되면 snapshot 추출 이후 데이타는 유실된다.
    (백업 시점의 데이타만 유지된다는 이야기)

AOF(Append On File)

AOF(Append On File) 방식은 redis의 모든 write/update 연산 자체를 모두 log 파일에 기록하는 형태이다. 서버가 재 시작될때 기록된 write/update operation을 순차적으로 재 실행하여 데이타를 복구한다. operation 이 발생할때 마다 매번 기록하기 때문에, RDB 방식과는 달리 특정 시점이 아니라 항상 현재 시점까지의 로그를 기록할 수 있으며, 기본적으로 non-blocking call이다.

  • 장점: Log file에 대해서 append만 하기 때문에, log write 속도가 빠르며, 어느 시점에 server가 down되더라도 데이타 유실이 발생하지 않는다.
  • 단점: 모든 write/update operation에 대해서 log를 남기기 때문에 로그 데이타 양이 RDB 방식에 비해서 과대하게 크며, 복구시 저장된 write/update operation을 다시 replay 하기 때문에 restart속도가 느리다.

결론

RDB와 AOF 방식의 장단점을 상쇠하기 위해서 두가지 방식을 혼용해서 사용하자.

주기적으로 snapshot으로 백업, 다음 snapshot까지의 저장은 AOF 방식 수행

이렇게 하면 서버가 restart될 때 백업된 snapshot을 reload하고, 소량의 AOF 로그만 replay하면 되기 때문에, restart 시간을 절약하고 데이타의 유실을 방지할 수 있다.

Pub/Sub Model

1:1, 1:N 형태의 pub/sub messaging 지원, pattern matching을 통해 다수의 topic에서 message를 subscribe 할 수 있다.
(내용 추가 예정)

개인적으로 궁금했던 Kafka와 Redis의 차이점에 대한 글을 공유합니다.

Expriation

Data에 대한 생명 주기를 정해 일정 시간이 지나면 자동으로 삭제 할 수 있음
1) Active Client가 expired된 데이터에 접근 시, 체크해서 삭제
2) Passive 주기적으로 key들을 랜덤으로 100개만 스캔해서 삭제


References