NoSQL 저장방식에 따른 분류

간단하게

Not Only SQL의 의 약자로 기존 RDBMS 형태의 관계형 데이터베이스가 아닌 다른 형태의 데이터 저장 기술을 의미하며 관계형 데이터 베이스의 한계를 극복하기 위한 데이터 저장소의 새로운 형태로 수평적 확장성이 있다

RDBMS 가 클라이언트/서버 환경에 맞는 데이터 저장기술이라면 NoSQL은 클라우드 환경에 맞는 저장 기술이다.

이전까지의 컴퓨팅 시스템은 기업 업무를 자동화하고 효율화 하는데 그 목적이 있었고 복잡한 데이터를 저장하거나 그 데이터간의 관계를 정의하고 분석하는데 최적화되어 있었다. 물론 그 과정에서 생성되는 데이터의 양은 한계를 가지고 있었다.

그러나 인터넷의 발전과 함께 특정 고객이 아닌 전세계의 사람들을 대상으로 하는 형태의 서비스가 발전이 되었고 이는 기존의 기업 시스템에서 볼 수 없었던 대규모 데이터를 생산해냈다.

또한 이 데이터들은 기존에 복잡했던 데이터 형태에 비해 매우 단순한 형태를 띠었고 이것은 기존의 Oracle, MySQL 등으로 대변되는 RDBMS 중심의 데이터 저장 기술 시장에서 새로운 데이터 저장 기술인 NoSQL이 등장하는 계기가 되었다.

- > 대용량의 데이터가 계속 들어온다면, 스키마에 맞춰 변경해서 넣기 위해 긴 시간의 down time이 발생한다.

NoSQL은 거대한 Map<String, Object>이라고 할 수 있다. 따라서 대부분 NoSQL은 Key/Value 개념을 지원한다. 이 때 저장소는 RAM일 수도, 디스크일 수도 있다. 보통 데이터 모델(key에 저장되는 값)에 따라 NoSQL을 분류한다.

Key를 이용해 value에 접근하는 구조.
단순한 저장구조를 가지며, 복잡한 조회 연산을 지원하지 않는다.
고속 읽기와 쓰기에 최적화된 경우가 많다. key에 대한 단위 연산이 빠른 것이지, 여러 key에 대한 연산은 느릴 수 있다.
메모리를 저장소로 쓰는 경우, 아주 빠른 get과 put을 지원한다.
Value는 문자열이나 정수와 같은 원시 타입이 들어갈 수도 있고, 아래 사진처럼 또 다른 key/Value이 들어갈 수도 있다. 이를 Column Family이라고 하며, Key 안에 (Column, Value) 조합으로 된 여러 개의 필드를 갖는 것을 말한다.
어떠한 형태(List, Set 등)의 데이터든 저장이 가능함. 각 DB별로 value의 최고 저장 size가 있으므로 이점을 유의. Key를 기반으로 정렬/비정렬 가능한점이 다름.
장점 : 간단한 API를 제공하는 만큼 질의의 속도가 굉장히 빠른 편이다. 수평적 확장이 용이하다.
단점 : 값의 내용을 사용한 쿼리가 불가능하다.

Key/Value Store와 데이터 저장 방식은 동일하다. 보통 NoSQL은 RDBMS의 order by같은 정렬기능을 제공해주지 않는다. 그러나 이 모델은 내부적으로 Key를 정렬한다.
키를 정렬함으로써, 값을 날짜나 선착순으로 정렬해서 보여줄 때 매우 유용하다.
두 단계의 집합(Map) 구조.
Row Key에 다수의 column&value가 들어감. Row key로 자동정렬, column key로 자동정렬 가능.(각 NoSQL마다 상이) 하나의 행에 수천~수만개의 컬럼을 저장가능.
장점 : 클러스터링이 쉽게 이뤄지며, Time stamp가 존재해 값이 수정된 히스토리를 알 수 있다. 또한 값들은 일련의 바이너리 데이터로 존재하기 때문에 어떤 형태의 데이터라도 저장될 수 있다
단점 : Blob 단위의 쿼리가 불가능하며, Row와 Column의 초기 디자인이 중요하다. Schema-less이긴 하지만 새로운 필드를 만드는 데 드는 비용이 크기 때문에 사실상 결정된 스키마를 변경하는 것이 어렵다.

Key/Value Store의 확장된 형태로, value에 Document라는 타입을 저장한다. Document는 구조화된 문서 데이터(XML, JSON, YAML 등)을 말한다.
복잡한 데이터 구조를 표현가능하다.
Document id 또는 특정 속성값 기준으로 인덱스를 생성한다. 이 경우 해당 key 값의 range에 대한 효율적인 연산이 가능해 지므로 이에 대한 쿼리를 제공한다. 따라서 Sorting, Join, Grouping 등이 가능해진다.
쿼리 처리에 있어서 데이터를 파싱해서 연산을 해야하므로 overhead가 key-value 모델보다 크다. 큰 크기의 document를 다룰 때는 성능이 저하된다.
장점 : 객체-관계 매핑이 필요하지 않다. 객체를 도큐먼트의 형태로 바로 저장 가능하기 때문이다.
단점 : 사용이 번거롭고 쿼리가 SQL과는 다르다. 도큐먼트 모델에서는 질의의 결과가 JSON이나 xml 형태로 출력되기 때문에 그 사용 방법이 RDBMS에서의 질의 결과를 사용하는 방법과 다르다.

실제 세계의 데이터를 관계와 함께 표현하기 위해 디자인된 모델로써, 데이터는 연속적인 노드, 관계, 특성의 형태인 그래프 형태로 저장된다. 따라서 질의는 그래프 순회를 통해 이루어진다. 역시 Key/Value Store이며 모든 노드는 끊기지 않고 연결되어 있다.
relationship은 direction, type, start node, end node에 대한 속성 등을 가진다. 보통 양(코스트, 무게 등)적인 속성들을 가진다.
관계형 모델이라고 할 수 있으며, 데이터 간의 관계가 탐색의 키일 경우에 적합하다. 연관된 데이터를 추천해주는 추천 엔진이나 패턴 인식 등의 데이터베이스로 적합하다. 또한 집합 지향 모델과는 다르게 개체의 ACID 트랜잭션을 지원한다.

ref)

티스토리툴바