NoSQL과 NoSQL의 종류들

NoSQL은 전통적인 관계형 DBMS을 문제점을 극복하기 위해서 나온 개념으로 빅데이터에 특화된 DB라고 이해를 하면 쉽다. 관계형 DBMS의 무거운 처리와 다양한 기능들을 제거하고 심플한 매커니즘을 장착하여 범용적인 서비스보다는 특별한 목적이 있는 DB라고 생각하면 된다.

---

일관성 모델의 Not only SQL, NoSQL의 개요

가. NoSQL의 개념

- 데이터베이스는 전통적인 관계형 데이터베이스 보다 덜 제한적인 일관성 모델을 이용하는 데이터의 저장 및 검색을 위한 매커니즘을 제공하는 DB (wikipedia)

- Not only SQL, 즉 SQL만을 사용하지 않는 데이터베이스 관리 시스템

데이터를 저장하는 방법에는 여러가지가 있으며, NoSQL은 SQL만을 사용하여 저장하지 않는다는 의미를 담고 있다 (즉, SQL로도 저장할 수 있지만 다양한 방법으로 저장을 지원한다는 의미이며, NoSQL은 일반적으로 API를 호출하여 저장을 한다)

나. NoSQL의 특징

- 최적화된 공간 : 단순 검색 및 추가 작업을 위한 최적화된 키 값 저장 공간

- 분산 저장 : 트래픽 증가에 따른 비용에 효율적인 scale-out 지원

- Schemaless : RDBMS와 같은 스키마 구조를 가지고 있지 않기 때문에, 개발 진척에 따른 스키마 변화에 flexible하다

NoSQL의 이론적 배경 CAP 정리 및 종류

가. NoSQL의 이론적 배경, CAP 정리

- DBMS는 모든 것을 만족할 수 없기 때문에 사이트에 맞는 속성(데이터 일관성, 가용성, 단절내성)을 선택하여 적용을 해야 하는데 이것을 CAP Theorem이라고 한다. 

Consistency (데이터 일관성)

- 모든 노드들은 같은 시간에 같은 데이터를 보여줘야 한다. (각각의 사용자가 동일한 데이터를 조회한다)

Availability (가용성)

- 몇몇 노드가 작동이 되지 않아도 시스템은 이상없이 작동한다

Partition Tolerance (단절내성)

- 메시지 전달이 실패(네트워크 장애)하거나 시스템 일부가 망가져도 시스템이 계속 동작한다

CAP 이론은 사실 상당히 이해하기 힘든 이론이다. 위 분류를 보면, 같은 NoSQL인 카산드라(cassandra)와 mongoDB가 서로 AP, CP로 나뉘어져 있는 것을 볼 수 있는데 DB를 잘 아는 사람도 쉽게 이해하기 힘들 것이다. 가용성과 단절내성의 차이점이 쉽게 받아들여지지 않는다. 둘다 사실 시스템이 장애나도 이상없이 작동되는가의 범위에서 차이점은 단절 내성은 네트워크의 장애이고, 가용성은 시스템의 장애이다.

즉 가용성은 시스템 하나가 죽어도(down) 작동이 되야 하는 것이고, 단절 내성은 네트워크가 하나 이상 단절(노드간 통신 실패)이 되어도 작동이 되야 하는 것이다. 그러면 우리는 왜 A와 P를 분류해야 하는지 이해가 되지 않는다 네트워크 단절에 따른 시스템 작동은 당연히 모든 시스템에서 고려를 해야 하는 범위인데 마치 P로 분류를 하는 모습은 쉽게 와닿지 않는다.

참고로 이 이론의 한계로 인해 나온 또 다른 이론이 PACELC 이론이다. 해당 이론에 관련된 설명은 다음 포스팅에 적을 예정이다.

나. CAP 이론에 따른 DBMS 선택 전략

C + A (일반적인 DBMS)

- 특정 노드가 죽더라도 시스템은 정상적으로 동작을 해야 하며, 메시지 손실을 방지하는 강한 신뢰형

- 트랜잭션이 필요한 경우 필수적

C + P (HBase, MongoDB)

- 모든 노드가 함께 퍼포먼스를 내야 하는 성능형

A + P (Cassandra, CouchDB)

- 비동기화된 스토어 작업에 필수적

다. NoSQL의 종류

항목	HBase	Cassandra	MongoDB
아키텍쳐	- Master-slave 구조	- Decentralized 구조, 모든 노드 동등 - peer-to-peer 복제방식	- Master-slave 구조
구성환경	- 복잡한 구성 - HBASE + HDFS + ZooKeeper 필수 구성	- 단순한 구성 - Cassandra 단일 구성	- 단순한 구성 - sharding 시 config 서버
Sharding	row key 전체가 sharding key	Row key 일부 속성으로 sharding key 지정 가능	Row key가 아닌 일반컬럼을 sharding key로 지정 가능
Analytic	분석용 데이터센터로 연동용이	Hadoop 연동을 위해 DSE 제품 사용 요구될 수 있음	Hadoop 연동 connector 사용
모델	Column-Family	Column-Family	Document

라. 데이터 저장 방식에 따른 분류

Key-Value

- 다이나모(dynamodb), 리악(Riak), 레디스(Redis), 캐시(Cash), 프로젝트 볼드모트(Voldmort)

Column

- H베이스, 아큐물로

Document

- 몽고DB(MongoDB), 카우치베이스(Couchbase)

Graph

- Neo4J, AgensGraph, 알레그로그래프, 버투오소

NoSQL의 적용 시 고려사항

- 프로젝트의 특성에 맞는 DBMS를 선택해야 한다(일반적으로 NoSQL을 사용하지 않아도 될 프로젝트에서 NoSQL을 무리해서 사용하는 경우가 많음)

- 조인(Join)이 되어 있는 DB 구조의 경우, 반정규화 등을 통해서 데이터를 분리하거나 중복 입력이 될 가능성을 염두해야 한다

연관포스팅

블록체인(Blockchain)의 트릴레마(Trilemma)