NoSQL 정리

나무위키의 내용을 요약/정리 했습니다.

NoSQL은 Not only SQL의 약자로 데이터를 저장하는 데에 SQL 외에 다른 방법도 있다! 라고 보면 될 듯 하다.

MongoDB와 CouchDB에서 사용하는 쿼리 언어는 전혀 다름에도 SQL이 아니기에 NoSQL 카테고리에 범주한다.

헷갈릴 수 있는데 NoSQL != No RDBMS 임을 알자. BerkleyDB와 같은 NoSQL 이면서 RDMS인 녀석도 있다. 

(반대로 No RDBMS != NoSQL 이기도 하다. KV-store라는 녀석이 있다.)

NoSQL의 정의가 명확하지는 않지만 현재 NoSQL이라 불리는 DB들은 대체적으로 공통적인 부분이 있다.

- 대부분 클러스터에서 실행할 목적으로 만들어 졌다. 

- 대부분 오픈소스이다.

- 스키마 없이 동작(Schema-less)하며, 구조에 대한 정의 변경 없이 레코드에 자유롭게 필드를 추가할 수 있다. 

RDMS은 트랜잭션을 통한 안정적인 데이터 관리가 가능하여 현재까지도 많은 인기를 누리고 있다.

하지만 빅데이터가 등장하면서 RDBMS에 한계가 발생했다: Scale-up(수직적 확장) 비용의 증가

NoSQL은 데이터의 일관성을 다소 포기하고 분산 저장하는 Scale-out(수평적 확장)을 목표로 등장했다. 

특징

- 일관성 ↓ 확장성 ↑

- 분산 저장(scale-out)

- Schema-less

- 데이터 일치

실제 메모리 내 데이터 구조와 RDBMS와는 데이터 불일치가 존재한다. (ORM이 있다 하더라도)

NoSQL은 데이터 불일치가 없다.

종류

- Aggregate-oriented(집합 지향) 모델

-- Key-value

-- Document

-- Column-family

- Graph

Key-value

가장 단순한 형태의 NoSQL, 수평적 확장이 용이

값을 사용한 쿼리가 불가능

대표적으로 Memcached, Riak, Redis, Amazon Dynao DB, LevelDB

Document

key-value 모델보다 한층 진화된 모델, key-document로 볼 수 있다.

Document로 저장되므로 내부의 item을 이용한 쿼리가 가능하다.

SQL과는 다른 형태의 쿼리이며 JSON이나 xml형태로 출력된다. 

대표적으로 MongoDB, Couchbase, MarkLogin 등이 있다.

Column-Family

이 모델은 특이하게도 key에서 필드를 결정한다.

key가 Row, Column-family, Column-name을 가진다.

클러스터링이 쉽게 이뤄지며, Time stamp가 존재해 히스토리를 알 수 있다.

Blob 단위의 쿼리는 불가능하다. 

대표적으로 HBase, Cassandra, Hypertable등이 있다.

Graph

상당히 독특한 디자인을 가진 모델로써 관계형 모델에 가깝다. 

데이터는 연속적인 노드, 관계, 특성의 형태로 저장된다. (=그래프 형태)

페이스북이나 트위터 같은 소셜 네트워크에 적합하다.

클러스터링에는 적합하지 않다.

RDBMS가 가진 장점이 너무나 명확하기 때문에 NoSQL이 RDBMS를 대체하지는 않을 것 같다.

하지만  NoSQL이 각광받는 이유는 그만의 장점이 뚜렷하기 때문이다.

구매 내역이나 게임 로그 등의 데이터는 엄청난 양이 생성되지만 수정될 일이 거의 없다.

이런 경우는 ACID 트랜잭션이 필요 없으며 scale-out 등이 중요하므로 NoSQL이 효능을 발휘한다.

페이스북이나 트위터 등의 게시글들을 저장하는데 NoSQL이 사용된다. RDBMS보다 빠른 성능 때문이다.

각종 검색엔진에도 NoSQL이 사용된다. 웹 페이지 내의 텍스트들을 형태소 단위의 토큰으로 분리하고 URL을 매핑하는 구조를 NoSQL을 통해 이룬다.

데이터의 일관성이 보장되어야 하고 여러번의 조인 연산이 필요하다면 단연 RDBMS를 고려해야 할 것이다. 

즉, 상호 보완할 수 있는 데이터베이스로 봐야하고 목적에 맞게 사용해야 한다. 

그렇다면 NoSQL은 어떻게 선정해야 할까?

Key-value 제품을 포함해 가장 인기 있는 제품은 MongoDB,  Couchbase, HBase, Cassandra 정도이다.

MongoDB와 Couchbase는 Document 모델이며 HBase, Cassandra는 Column-Family 모델이다

어느 모델이 적합한지는 프로젝트의 요구사항에 맞게 선택해야 할 것이다.

아래는 Document 모델인 Couchbase와 MongoDB를 비교한 표이다. 

기능	Couchbase	MongoDB
복제 방식	멀티 마스터(마스터-마스터)	마스터-슬레이브
확장성	매우 뛰어남	뛰어남
동적 쿼리	지원 안 함	지원함
데이터 안정성	매우 뛰어남	뛰어남. 높은 부하의 쓰기에는 부적합
앱 지원	존재. 서버와 자동 동기화	없음
Binary 데이터 읽기	상대적으로 느림	매우 빠름
복제 필터 기능	뛰어남	미약

<https://dbrang.tistory.com/1325>

<https://jacking.tistory.com/1332>

mongoDB

※ 소규모 용

장점

SQL 이상의 집계 쿼리(MS-DocumentDB와 더불어 최강)

역할 기반 액세스 관리

대량 데이터 처리

실시간으로 질의 생성

 

단점

트랜잭션을 할 수 없다

다중 마스터 업데이트

 

couchbase

※ 대형 전용

장점

다중 마스터

CRUD와 MapReduce(사전에 정한 쿼리)

GUI 콘솔이 제공된다

memcached가 내장되어 있음

단점

임시 쿼리

Which is better?

couchbase는 좀 더 대규모에 어울리는 듯하다(Map-Reduce)

mongoddb는 좀 더 다양한 인덱싱을 지원하여 RDB와 유사, 사용하기 편하다

couchbase도 group by 등이 지원된다..

KVF이 대규모 데이터베이스가 될 수도 있지 않을까?

상대적인거라 mongodb도 대용량 용이라고 판단된다.

couchbase는 캐싱이 장착되어 있다