본문 바로가기

좋아하는 것_매직IT/9.redis

6.Redis, NoSQL를 한번 분류해볼께요. ^^

반응형

NoSQL 분류는 ?

  • 데이터의 저장 방식에 따라 분류되기도 함.
    • NoSQL은 데이터 접근을 위해 키를 사용함, 키에 저장된 값의 데이터 모델에 따라서 분류하는 방법.
      • 키-값 모델
      • 문서 모델
      • 컬럼 모델
      • 그래프 모델

키-값 모델 

  • 가장 기본적인 형태 NoSQL
    • 키 하나로 데이터 하나를 저장하고 조회할 수 있는 단일 키-값 구조를 가짐.
  • 공통특징
    • 키-값 모델 NoSQL에 저장 가능한 데이터의 종류는 각 NoSQL별로 상이함.
    • 대부분 키-값 모델 NoSQL은 단순한 저장구조로 인하여 복잡한 조회 연산을 지원하지 않음.
    • 고속읽기 와 쓰기에 최적화된 경우가 많음.
    • 대부분 저장된 데이터에 대한 검증이나 데이터의 내용에 기반한 조회를 지원하지 않음.
    • 저장된 값을 단지 의미없는 바이너리 데이터로 처리함.
  • 주요 솔루션
    • 레디스
      • 홈페이지 : http://redis.io
      • 특징
        • 다양한 자료구조를 저장하고 조회할 수 있음.
        • 다양한 종류의 조회 방법을 지원하는 인메모리 NoSQL
        • C언어로 구현되어 있음.
    • 리악
      • 홈페이지 : https://docs.riak.com/
      • 특징
        • 단일 고장점을 가지지 않는 아키텍처와 맵-리듀스를 지원하는 키-값 모델 NoSQL
        • 값에 태그를 저장하여 보조 인덱스의 생성이 가능함.
        • 카산드라와 유사한 클러스터링 아키텍처를 지원함.
        • 최종 일관성을 지원함.
    • 다이나모
      • 홈페이지 : http://aws.amazon.com/dynamodb
      • 특징
        • 범위 조회가 가능한 키-값 모델 NoSQL
        • 아마존에서 개발하고 서비스 중인 상용서비스
        • 서비스 종류에 따라 다른 과금 체계를 가짐
        • 데이터는 SSD에 저장되며, 맵-리듀스를 사용한 프로그래밍이 가능함.
    • 볼드모트
      • 홈페이지 : http://www.project-voldemort.com/voldemort
      • 특징
        • 링크드인에서 사용하고 있는 키-값 모델 저장소
        • 단일고장점을 가지지 않음.
        • 아마존의 다이나모 설계를 구현한 오픈소스 솔루션
        • 볼드모드 공식 문서에 따르면 초당 1~2만건을 처리가능함.
  • 적절한 사용처
    • 단일연산으로 처리를 완료하거나 취소가능한 종류
      • 사용자의 프로필 정보
      • 웹 서버의 클러스터를 위한 세션 정보
      • 장바구니 정보
      • 단축 URL 정보 저장
      • 기타 등등
    • 대부분의 키-값모델 NoSQL은 데이터 자체의 값을 기준으로 검색하는 기능을 지원하지 않기때문에 그런연산이 필요한 곳에는 사용하지 않아야함.
    • 또한, 단일키 처리만을 지원하기때문에, 복잡한 다중연산이 필요한 서비스에는 어울리지 않음.
    • 하나의 서비스 요청에 다수의 데이터 조회및 수정연산이 발생하면 트랜잭션처리가 불가능하여 데이터 정합성을 보장하지 못하는 단점.

문서 모델 

  • 키-값 모델을 개념적으로 확장한 구조
    • 문서모델 NoSQL과 키-값 모델 NoSQL은 경계가 모호함.
  • 공통특징
    • 하나의 키에 하나의 구조화된 문서를 저장하고 조회함.
      • 구조화된 문서
        • JSON, BSON, XML 
    • 논리적인 데이터의 저장과 조회방법이 관계형 데이터베이스와 유사함.
    • NoSQL을 처음 도입하는 프로젝트에서 많이 선택함.
    • 마치 URL을 이용하여, 웹 서버에 저장된 HTML 문서를 조회하는 것과 유사함.
      • 키 : URL
      • 데이터 : HTML 문서
    • 문서 모델 NoSQL의 키는 문서에 대한 ID로 표현됨.
    • 저장된 문서를 컬렉션으로 관리하고, 문서 저장과 동시에 문서 ID에 대한 인덱스를 생성함.
    • 관계형 데이터베이스와 유사한 검색 조건을 포함한 쿼리를 처리할 수 있음.
      • 이런 장점으로 많은 사용자가 문서 모델 NoSQL을 선호함.
    • 대부분의 문서 모델 NoSQL은 B트리 인덱스를 사용하여 2차 인덱스를 생성함.
  • 주요 솔루션
    • MongoDB
    • 카우치베이스
      • 홈페이지 : http://www.couchbase.com
      • 특징
        • B트리의 단점을 보완한 수정된 B트리 인덱스를 사용함.
        • 자체 클러스터 모니터링 기능이 뛰어난 문서 모델 NoSQL
        • 내부적으로 맵-리듀스를 사용하여 동작함
    • 테라스토어
    • 레이븐DB
      • 홈페이지 : https://github.com/ravendb/ravendb
      • 특징
        • 분산노드의 관계형 데이터베이스에서 지원하는 ACID 특성을 지원하는 문서 모델 NoSQL
        • 닷넷(.NET)으로 작성되어 있고, LINQ라는 쿼리 언어를 지원함.
  • 적절한 사용처
    • B트리의 특성으로 인하여 한번 작성되면, 자주 변하지 않는정보를 저장하고 조회하는데 적합함.
      • 중앙집중식로그 저장
      • 타임라인 저장
      • 통계정보 저장
      • 기타 등등
    • 조회 시 특정 수량을 기준으로 잘라서 조회하는 기능등에는 부적합함.

컬럼 모델

  • 하나의 키에 여러개의 컬럼 이름과 컬럼 값이 쌍으로 이루어진 데이터를 저장하고 조회하는 NoSQL
  • 공통특성
    • 단일 키에 의한 단일 컬럼 및 범위 조회도 가능함.
    • 모든 컬럼은 항상 타임스탬프값과 함께 저장됨.
    • 컬럼모델 NoSQL에서 키는 로우키라 불림.
    • NoSQL의 분류 중에서 가장 복잡한 저장구조를 가지는 NoSQL
    • 대부분의 컬럼 모델 NoSQL은 구글 빅테이블의 영향을 받아 개발됨.
      • 로우키(row key), 컬럼키(column key),컬럼패밀리(column family) 같은 빅테이블 개념이 공통적으로 사용됨.
    • 저장과 조회의 기본단위는 컬럼.
      • 컬럼 = 컬럼이름 + 컬럼 값 + 타임스탬프 
      • 컬럼 집합은 로우
        • 로우키는 각 로우를 유일하게 식별하는 값
        • 로우의 집합은 테이블 or 키스페이스가 됨.
    • 컬럼하나를 조회할때는 행을 구분하는 로우키와 열을 구분하는 컬럼키를 사용함.
      • 컬럼키 생략 : 해당 로우에 저장된 모든 컬럼이 조회됨.
  • 주요 솔루션
    • HBase
      • 홈페이지 : http://hbase.apache.org
      • 특징
        • 자바로 구현된 하둡 기반의 컬럼 모델 NoSQL
        • 데이터를 저장하기 위한 파일시스템으로 하둡을 사용함.
    • 카산드라
      • 홈페이지 : http://cassandra.apache.org/
      • 특징
        • 아마존의 분산 처리 아키텍처와 빅테이블의 데이터 구조를 가지고 있는 컬럼 모델 NoSQL
        • 페이스북에서 개발함.
    • 하이퍼 테이블
      • 홈페이지 : http://hypertable.com
      • 특징
        • C++로 구현되어 있고, HBase와 유사한 구조를 가짐.
        • 보통 HBase에 비하여 빠른 성능을 제공하는 것으로 알려짐.
  • 적절한 사용처
    • 쓰기와 읽기 중에서 쓰기에 더 특화되어있음.
    • 쓰기 연산은 데이터를 먼저 커밋로그와 메모리에 저장한 후 응답하기 때문에 매우 빠른응답속도를 제공함.
    • 읽기 연산 대비 쓰기 연산이 많은 서비스나, 빠른 시간안에 대량의 데이터를 입력하고 조회하는 서비스를 구현할 때 사용하면 좋음.
      • 채팅내용저장
      • 메일 저장소
      • 알림 내용 저장
      • 실시간 분석을 위한 데이터 저장소등의 서비스 구현
      • 기타 등등

그래프 모델

  • 노드와 관계를 사용하여 데이터를 저장하고 조회하는데, 관계는 속성이라는 부가 정보를 가짐.
    • 노드와 관계로 표현함.
      • 예) 사용자와 구매 정보
        • 사용자와 상품은 노드
        • 구매는 관계
  • 공통특징
    • 관계형 데이터베이스와 가장 유사함.
    • 노드와 노드간의 관계를 저장하고, 노드가 하나일 때는 관계를 지정할 수 없음.
    • 노드의 조회를 위해서 관계를 조회 조건으로 사용함.
    • 관계는 방향성을 가지고도 하는데, 방향성에 의하여 여러 단계의 조회가 가능함.
      • 이를 순회라고 함.
    • 하나의 노드에서 다른 노드까지 도착하는데 여러 경로가 존재할 수 있음.
    • 많이 알려지지 않아서 서비스 도입사례가 적은 단점.
  • 주요 솔루션
    • Neptune
      • 홈페이지 : https://aws.amazon.com/ko/neptune/
      • 특징
        • 빠르고 안정적인 완전관리형 그래프 데이터베이스 서비스로, 상호연결성이 높은 데이터 집합을 활용하는 애플리케이션을 손쉽게 구축 및 실행할 수 있음.
        • Amazon Neptune은 한마디로 수십억 개의 관계를 저장하고 불과 몇 밀리초의 지연 시간으로 그래프를 쿼리하는 데 최적화된, 특수 목적의 고성능 그래프 데이터베이스 엔진
    • 기타 등등
  • 적절한 사용처
    • 친구 추천과 같은 연관검색을 위한 정보를 저장하고 조회하는데 적합함.
      • 추천시스템
      • 다중관계를 가진 엔티티를 저장하고조회하는데 알맞음.
    • 많은 그래프 모델 NoSQL은 각 데이터에 대한관계를 저장하기 때문에 데이터를 다중 노드에 분산하여 저장하는 데 많은 한계가 있음.

결론

  • NoSQL은 키에 저장된 값의 데이터 모델에 따라서 아래와 같이 분류가능함
    • 키-값 모델
    • 문서 모델
    • 컬럼 모델
    • 그래프 모델
  • NoSQL을 사용할 때 선택사항은 많지만 적절한 서비스 구현에 사용하기 위해서는 세밀하게 사용하고자 하는 NoSQL에 대해서 정확하게 공부하고 사용해야함.

  • 금일의 명언 한마디
    • 우리 모두 같은 인간이고, 우리 모두 두려움과 의심, 믿음과 강점 그리고 약점을 갖고 있다. 하지만, 우리가 그런 것들에 반응하고 그런 유사점을 다루는 방식은 서로 다르다. -로버트 기요사키,  『부자아빠, 가난한아빠2』 중에서..

  • 금일의 영어 한마디
    • 질문)He's got a lot of charm.
      • 그는 정말 너무 멋지지 않아.
    • 대답)Tell me more.
      • 그래서? 더 좀 이야기해봐.
    • 해설)
      • "a lot of"는 많은(다량의) 이란 의미
      • "Tell me more."는 상대방의 말에 흥미가 있을 때 많이 쓰이는 표현
        • 어디, 더 좀 말해봐라는 뜻
      • 그것에 관해 더욱 더 는 "more about it" 이라고 함.
728x90
300x250