NoSQL 종류, 활용, 모델 (비관계형 데이터베이스 관리 시스템(DBMS))

참고하면 좋을 사이트 

SQL과 NOSQL의 차이

 

Cf. NoSQL 데이터베이스 
관계형 데이터베이스에 반대되는 개념/ 직접적으로 반대되는 구조 
Table 없음Schema (구조) 없음관계 Relations 없음 
 
테이블 없으니 테이블로 저장 안 함
JSON과 같은 key- value형태로 저장 (데이터 그대로 저장)


스키마 없으니, 각 데이터가 통일될 필요 없음
관계형 데이터 베이스에서는, Name, email, number 테이블이 있으니 그 외 데이터 (age, gender)는 들어올 수 없음. 
Nosql 데이터베이스는은 age, gender, 
막 저장 가능 schemaless

관계 없기에 원하는 대로 저장 가능
 
관계 중심이 아니라 document (= 데이터)  중심 문서와 비슷함
Ex. mongo DB(최초 NoSQL 데이터베이스), redis
 
NoSQL 언제 사용? (지켜야 할 게 없으니, 확장과 속도가 빨라진다. )
비정형화 데이터 저장해야할 때 (ex.로그 데이터) _ 구조 없으니 데이터 처리 속도 중요할 떄  (관계형 데이터 하려면 테이블 짜고 들어가야 하니) 이런거 skip 하고 바로 개발할 수 있으니 빠르게 개발 가능 수평적 확장 중요할 때(관계형데이터는 관계 있고, 서로 구조 맞아야 하니 제약이 많음→ 확장이나 속도에서 희생을 해야 함, 대신 데이터 구조/안정성/온전성 가져갈 수) , big data처리 중요할 때

 

전통적인 관계형 데이터베이스 관리 시스템(RDBMS)과는

다르게 설계된 비관계형(non-relational) DBMS로,

 

대규모의 데이터를 유연하게 처리할 수 있는 것이 강점

 

테이블-컬럼과 같은 스키마 없이,

분산 환경에서 단순 검색 및 추가 작업을 위한 키 값을 최적화하고,

지연(latency)과 처리율(throughput)이 우수하다.

 

대규모 확대가 가능한 수평적인 확장성의 특징

 

NoSQL에 기반을 둔 시스템의 대표적인 예

- 아파치 카산드라(Apache Cassandra), 하둡(Hadoop), 몽고디비(MongoDB) 등.

[네이버 지식백과] 노에스큐엘 [NoSQL, non SQL] (IT용어사전, 한국정보통신기술협회)

 

 

"Not only SQL"

SQL만을 사용하지 않는 데이터베이스 관리 시스템(DBMS)

관계형 데이터베이스를 사용하지 않는다는 의미가 아닌, 여러 유형의 데이터베이스를 사용하는 것이다.

 

데이터를 조직하는 방법

- 리스트, 해시 테이블, 트리, 그래프 등의 다양한 방법

- 각각은 장점과 단점이 명확하기 때문에 단순히 NoSQL이라고만 해서는 너무 뜬구름 잡는 얘기가 된다.

- NoSQL이라는 단어는 RDBMS가 데이터베이스의 독점적인 지위를 차지하고 있는 현재 상황에 반발하는 정신을 담고 있다.

 

MongoDB에서 사용하는 쿼리 언어와 
CouchDB에서 사용하는 쿼리 언어는 서로 전혀 다르다. 

그럼에도 이 두 쿼리 언어는 같은 NoSQL 카테고리에 속한다. 어쨌거나 SQL이 아니기 때문이다.

 

NoSQL이 No RDBMS를 의미하지는 않는다.
BerkeleyDB같은 예외

 

No RDBMS가 NoSQL인 것도 아니다.
SQL호환 레이어를 제공하는 KV-store라는 예외

물론 KV-store의 특징상 range query를 where절에 넣을 수 없으므로
완전한 SQL은 못 되고 SQL의 부분집합 정도를 제공한다.

 

1. 특징

1-1. 일관성과 확장성 사이의 Trade-off

일관성(Consistency)이 데이터베이스의 절대적인 요소가 아님을 주장하는 움직임이 생기기 시작

 

비일관성이 다음과 같은 두 가지 이유로 감수할 만한 것이라고 주장

• 다수가 동시에 읽고 쓰는(Read and write) 상황에서의 성능 향상을 위해서.
• 분산 환경에서 노드들이 잘 작동하고 있음에도, 시스템의 일부가 고장나면 데이터베이스를 사용할 수 없게 되는 문제를 해결하기 위해서.

 

1-2. 분산 저장

데이터와 트래픽이 증가함에 따라 

기존의 장비로는 원활한 데이터의 처리가 어려워졌다. 

 

이를 해결하기 위한 방법

1-2-1. 처리하는 장비의 성능을 키우는 수직적 확장(Scale-up) 

1-2-2. 처리하는 장비의 수를 늘리는 수평적 확장(Scale-out)

 

수직적 확장은 비용적인 문제가 발생하므로

수평적 확장을 통해 성능을 올려야 한다.

 

하지만 문제는,

관계형 데이터베이스가 클러스터상에서 효율적으로 동작하도록 설계되지 않았다는 점이다.

물론 관계형 데이터베이스를 클러스터상에서 돌리지 못하는 것은 아니다.

클러스터상에서 동작하는 관계형 데이터베이스 솔루션도 존재한다.

 

이러한 데이터베이스에서는

클러스터를 인식할 수 있는 파일 시스템을 사용해

고가용성 디스크 서브시스템에 데이터를 기록하는 공유 디스크 개념을 사용

 

하지만 클러스터의 디스크 서브시스템이 단일 고장점이 되어,

디스크 서브시스템에 문제가 생길 경우 데이터베이스를 사용할 수 없게 된다.

샤딩(Sharding)은 

샤드 키(Shard key)를 기준으로 하나의 테이블을 수평 분할하여 

서로 다른 클러스터에 분산 저장하고 질의할 수 있는 기법

 

이를 통해 관계형 데이터베이스에서도 부하를 분산할 수 있지만

어플리케이션 레벨에서 모든 샤딩을 제어해야 한다. (어떤 데이터를 어느 클러스터에서 처리해야 하는지 등)

 

또한 여러 샤드에 걸치는 쿼리나 참조 정합성, 트랜잭션, 일관성의 제어에 문제가 발생한다.

 

분산 저장을 지원하는 NoSQL 데이터베이스의 경우, 

집합-지향(Aggregate-oriented) 모델을 사용하여 이러한 문제를 해결한다. 

 

연관된 데이터들이 함께 분산되므로, 관계형 모델에서처럼 복잡한 제어가 필요하지 않게 된다.

 

 

1-3. 데이터 일치

RDBMS에서

관계형 튜플 안의 값은

단순해야 하며

중첩된 레코드나 리스트 등 다른 구조를 포함할 수 없는 반면,

 

메모리 내 데이터 구조에서는

이런 제약이 없어 훨씬 복잡한 구조를 사용한다.

(ex: 리스트, 딕셔너리, 중첩된 객체 구조)

 

그 결과, 복잡한 메모리 내 데이터 구조를

데이터베이스에 저장하려면

먼저 관계형 표현으로 변환해야 한다.

 

물론 이는 ORM(Objective-Relational Mapping: 객체-관계 매핑) 프레임워크를 통해 해결할 수 있지만,

여전히 관계형 모델과

메모리 내 데이터 구조 간에는

데이터 불일치는 존재한다. =  Impedance mismatch

 

하지만 NoSQL은 그런 게 없다. 

 

메모리 내의 데이터가 어떤 구조이든지 상관하지 않고 

하나의 Aggregation으로 취급하여 저장해버리기 때문이다. 

따라서 NoSQL에서는 ORM 프레임워크가 필요하지 않다.

 

1-4. Schema-less

NoSQL 데이터베이스의 공통적인 특징:

사용 전에 정의된 명시적인 스키마 없이 동작한다

 

 따라서 데이터 구조를 미리 정의할 필요가 없으며,

시간이 지나더라도 언제든지 바꿀 수 있기 때문에

비형식적인 데이터를 저장하는 데 용이

 

하지만 이는 데이터베이스가

스키마를 직접 관리하지 않는 것을 의미할 뿐,

 

데이터 타입에 따른

암묵적인 스키마는 여전히 존재한다.

 

이 때문에,

단일 값에 대한 데이터 타입에서 불일치가 발생할 수 있다.

예를 들어,

필드의 이름을 “Quantity”라고 하기로 했다고 하자.

 

이것은 앞으로 저장할 때

반드시 필드의 이름을 “Quantity”라고 저장하겠다는 암묵적인 스키마가 된다.

 

암묵적인 스키마를 무시할 경우

Quantity를 quantity, qty, QUANTITY 등으로 저장할지도 모른다.

 

뜬금없이 qty, quantity같은 새로운 필드가 추가되는 것이나 마찬가지이다.

 

이는 NoSQL 데이터베이스가

암묵적인 스키마에 대해 전혀 알지 못하며,

이를 강제하지 않기 때문에 발생하는 일이다. 그렇게 때문에 NoSQL을 사용할 때에는 주의를 기울일 필요가 있다.

 

 

2. 종류

NoSQL 데이터베이스:  네 가지 모델

• Key-value 
• Document
• Column-family
• Graph

Graph 모델을 제외한 세 모델은 집합-지향(Aggregate-oriented) 모델이다.

 

 

2-0. [집합-지향 (Aggregate-oriented) 모델]

집합(Aggregate)이란 

연산의 한 단위로 취급되는

연관된 객체들의 집합

 

집합 지향 데이터베이스는

집합 자료구조로 이루어져 있다.

 

관계형 모델: 하나의 엔티티에 대한 ACID transaction을 지원

집합-지향 모델: 하나의 집합에 대한 연산에서는 transaction을 지원한다.

 

Project 2- 3일차: Database 세션 심화 [Indexing, Transaction, ACID] **

 

2-0-1. 여러 대의 클러스터로 이루어진 시스템에서 사용하기 적합하다. 

= 수평적 확장이 용이

= 연관된 데이터들이 함께 움직이기 때문

 

2-0-2. 메모리 내의 자료구조와 집합 간 데이터가 잘 일치하므로,

- 관계형 데이터베이스처럼 객체-관계 매핑 프레임워크가 필요하지 않다.

- 데이터의 검색 아주 쉬운 편, 키나 ID를 사용하면 쉽게 집합 레코드를 찾아낼 수 있다.

2-0-3. 조인 연산이 불가능한데,

이를 보완하기 위해 MongoDB나 Cassandra등의 데이터베이스에서는

맵 리듀스(MapReduce) 기능을 제공함으로써

 

조인과 유사한 연산을 가능하도록 설계했다.

 

이를 사용하여 데이터 분석도 가능하다.

하지만 사용법이 어렵고 Hadoop의 맵 리듀스에 비하면 속도도 매우 느리다.

 

2-1. 'Key-value' Model

키 값(Key-value) 저장소는 가장 단순한 형태의 NoSQL으로,

 수평적 확장이 용이하며 속도도 엄청 빠르다. 

 

또한 아주 간단한 API만을 제공하기 때문에 배우는 것이 어렵지 않다.

 

하지만 값의 내용을 사용한 쿼리가 불가능하다는 단점이 있다.

사용자는 키를 사용해 값을 읽어들인 뒤,

어플리케이션 레벨에서 적절히 처리해야 한다.

키-값 저장소는 

데이터가 키와 값의 쌍으로 저장된다.

 

키: 값에 접근하기 위한 용도로 사용되며, 

값: 어떠한 형태의 데이터라도 담을 수 있다. 이미지나 비디오도 가능하다.

 

또한 간단한 API를 제공하는 만큼 질의의 속도가 굉장히 빠른 편이다.

Key-value 모델을 사용하는 NoSQL 데이터베이스: Memcached, Riak, Redis, Amazon Dynamo DB, LevelDB 등

 

2-2. 'Document' Model

"키-값(Value)" 모델에서 한층 진화한 모델로 생각할 수 있다. 

 

2-2-1. 데이터 => "키와 도큐먼트(Document)"의 형태로 저장

 * Value --> 계층적인 형태인 Document로 저장

 

2-2-2. 객체지향에서의 객체와 유사,

하나의 단위로 취급되어 저장된다.

= 하나의 객체를 여러 개의 테이블에 나눠 저장할 필요가 없어진다

 

도큐먼트 내의 item을 이용한 쿼리가 가능 -->  Xquery나 다른 도큐먼트 질의 언어가 필요

2-2-3. 객체-관계 매핑이 필요하지 않다.

객체를 도큐먼트의 형태로 바로 저장 가능

 

2-2-4. 검색에 최적화되어 있는데, 이는 키-값 모델의 특징과 동일하다.

 

2-2-5. 단점: 사용이 번거롭고 쿼리가 SQL과는 다르다

- 질의의 결과가 JSON이나 xml 형태로 출력되기 때문에

   RDBMS에서의 질의 결과를 사용하는 방법과 다르다.

- 질의 언어가 SQL과 다르기 때문에 사용에 익숙해지기까지 다소 어려움이 있을 수 있다.

Document 모델을 사용하는 NoSQL 데이터베이스: MongoDB, CouchDB, MarkLogic 등

 

2-3. 'Column-Family' Model

위의 두 모델과는 다소 차이가 있지만 집합-지향 모델로 간주

 

'document, key-value' model: 값을 이용해 필드 결정 / Blob 단위의 쿼리가 가능

'column- family' model:  키에서 필드 결정 / Blob 단위의 쿼리가 불가능

 

키: Row(키 값), Column-family, Column-name

연관된 데이터들은

같은 Column-family 안에 속해 있으며,

각자의 Column-name을 가진다.

 

관계형 모델로 설명하자면 어트리뷰트가 계층적인 구조를 가지고 있는 셈이다.

 

이렇게 저장된 데이터는

하나의 커다란 테이블로 표현이 가능하며,

질의는 Row, Column-family, Column-name을 통해 수행된다.

- clusting 이 쉽게 이뤄지며, 

- Time stamp가 존재해 값이 수정된 히스토리를 알 수

- 일련의 바이너리 데이터로 존재, 어떤 형태의 데이터라도 저장될 수

Blob 단위의 쿼리가 불가능하기에,

Row와 Column의 초기 디자인이 중요

 

Schema-less이긴 하지만

새로운 필드를 만드는 데 드는 비용이 크기 때문에

사실상 결정된 스키마를 변경하는 것이 어렵다.

Column-family 모델을 사용하는 NoSQL 데이터베이스: HBase, Cassandra, Hypertable 등

 

 

2-4. 'Graph' Model

상당히 독특한 디자인을 가진 모델로써

관계형 모델에 가깝다.

 

실제 세계의 데이타를 관계와 함께 표현하기 위해 디자인된 모델로써,

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

==> 질의는 그래프 순회를 통해 이루어진다

개체와 관계를 그래프 형태로 표현 --> 관계형 모델

 

[적합한 경우]

- 데이터 간의 관계가

탐색의 키일 경우에 적합

 

- 페이스북이나 트위터 같은 소셜 네트워크에서(내 친구의 친구를 찾는 질의 등) 적합

 

- 연관된 데이터를 추천해주는 추천 엔진이나 패턴 인식 등의 데이터베이스

 

또한 집합 지향 모델과는 다르게, 개체의 ACID transaction 지원

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

 

또한 질의 언어도 특화되어 있어 배우기 어렵다.

 

 

3. 의의, 활용

 

대부분의 사람들은 NoSQL이 RDBMS를 대체할 수 있을 것이라고는 생각하지 않는다. 

RDBMS가 가진 장점이 너무나 명확하고, 또한 많은 사람들이 RDBMS을 사용하는 데 익숙해져 있기 때문

 

그럼에도 불구하고 NoSQL이 각광받고 있는 까닭은

NoSQL만의 장점이 뚜렷하기 때문

 

 구매 내역이나 게임의 로그 같은 데이터들

 

매 초마다 엄청난 양이 생성되지만 

한번 저장되고 난 뒤에는 수정될 일이 거의 없다.

 

- 이런 데이터들을 저장하는 데 데이터의 일관성을 보장하기 위해 ACID 트랜잭션을 지원할 필요는 없을 것

 

- 생성되는 데이터의 양도 많기 때문에, 장비의 성능에도 상당한 영향을 미칠 것

 

NoSQL은 이러한 데이터들을 효율적으로 저장할 수 있다.

여러 대의 장비에 빠른 속도로 저장이 가능하며, 데이터의 양이 누적되더라도 얼마든지 수평적 확장이 가능하기 때문이다.

 

실제로 페이스북이나 트위터 같은 소셜 네트워크 서비스에서는
게시글들을 저장하는 데 NoSQL 데이터베이스를 사용하고 있다.

 

매 초에 수백 기가~수 테라 바이트씩 생성되는 데이터들을 RDBMS를 사용해 저장한다면, 글 작성 버튼을 누른 후 글이 중앙 데이터베이스에 저장되기까지 한참을 기다려야 글을 성공적으로 게시할 수 있을 것이다.

 

하지만 NoSQL의 분산 데이터베이스를 사용한다면 부하가 분산되기 때문에

우리가 글쓰기 버튼을 누르고 한참을 기다릴 필요가 없게 된다.

 

 각종 검색 엔진에도 사용되는 것이 NoSQL

 

웹 페이지 내의 텍스트들을 형태소 단위의 토큰으로 분리하여
토큰과 해당 토큰이 포함된 페이지들의 URL을 매핑하는 Inverted Index(역 인덱스) 구조를 NoSQL을 통해 구현한다.

이런 기능을 일반적인 RDMBS로 구현했을 경우 검색 창에 단어를 입력했을 때마다 상당한 시간이 소요될 것이다.

 

데이터의 일관성이 보장되어야 하거나 여러번의 조인 연산이 필요한 데이터라면 NoSQL을 사용하는 것보다 RDBMS 사용 

NoSQL은 RDBMS를 대체하기 위한 데이터베이스가 아니라, 상호 보완할 수 있는 데이터베이스

목적에 맞게 사용하는 것이 중요

C++, Java, Python 등 여러 언어를 사용해서 하나의 프로그램을 만들 수 있는 것처럼(Polyglot Programming) 데이터베이스 역시 다양한 저장소(Polyglot Persistance)를 사용할 수 있게 되었다는 점에서 NoSQL의 의의는 크다고 볼 수 있다.

 

 

4. 종류

• Redis
• Cassandra
• HBase
• Firebase의 실시간 데이터베이스와 Cloud Firestore
• MongoDB