[DB] NoSQL

NoSQL의 등장 배경

---

NoSQL은 기본 RDBMS의 한계를 극복하기 위해 만들어진 새로운 형태의 데이터베이스로, 분산 환경에서 대용량의 데이터를 빠르게 처리하기 위해서 개발되었다.

 

RDBMS의 한계

NoSQL이 등장하기 20년간, 데이터를 저장하는데는 RDBMS가 주로 사용되었다. 하지만 2009년 이후로 폭발적으로 데이터가 늘어나면서 RDBMS는 데이터를 처리하는 비용의 증가로 난관에 부딪힌다.

• 스키마 문제: 빅데이터를 RDB의 스키마에 맞춰 저장하려면 매우 긴 시간이 걸린다.
• 스케일업의 한계: 성능을 올리는 데에 비용의 한계가 있으며, 스케일 아웃 환경에서 RDBMS를 조작하는 것은 어렵다.

 

Relational SQL vs NoSQL

---

	Relationl SQL	NoSQL
데이터 저장	행과 열을 가진 관계형 모델(Table) 저장	다양한 저장 모델: document, key-value, column, graph
스키마와 융통성	- 각 레코드는 고정된 스키마를 따름 - 컬럼들은 미리 정의되어야 함 - 데이터 입력시에 빈 필드에도 Null 값 입력 - 한번 정해진 스키마는 변경이 어렵고 변경 시 비용(Cost)이 발생	- 가변적 스키마 - 데이터 입력 시 실시간으로 변경 가능 - 빈 필드는 저장 공간을 할당받지 않음
확장성	Scale-up → 데이터 확장 시 더 크고 비싼 서버를 필요로 함	Scale-out → 데이터 확장 시 일반적인 서버 개수 확대로 가능
ACID 호환	O	X
데이터 타입	정형 데이터	비정형 데이터, 반정형 데이터, 정형 데이터
예	MySQL, Oracle, MS-SQL	HBase, MongoDB, Cassandra → 시스템 특성에 따라 선택

 

언제 NoSQL을 사용할 것인가?

• 다양한 수준의 성능, 일관성, 가용성, 확장성을 필요로 하는 어플리케이션
• 하루 수 십 테라 바이트 이상의 데이터를 생산하는 시스템
• 실시간을 필요로 하는 시스템
• 고가용성이 필요하지만 일관성이 요구되지 않는 시스템
• 일정 시간 지연 후 최종 일관성 보장
• 빅데이터 처리 및 분석
• ACID 필수가 아닌 경우
• 소셜 네트워크, 온라인 쇼핑, 데이터 분석 및 시각화를 위한 데이터 저장 및 처리 시스템

 

부적합 어플리케이션 (항상 일관성 유지가 필요한 경우)
→ 은행, POS system, 증권 거래 등

 

NoSQL이란?

---

• Not only SQL
• 비 관계형 데이터 저장소 역할
• Schema-less, not support transaction
• 구조화된 데이터와 반구조화된 데이터 모두를 저장하고 처리할 수 있는 유연한 데이터베이스 관리 시스템

 

NoSQL 특징

---

• 거대한 Map으로서 key-value 형식을 지원한다.
• 복잡한 질의(join 등)는 지원하지 않는다.
• 고정된 스키마가 없다.
• 분산형 구조를 통해 여러대의 서버에 분산하여 저장하고 상호복제하여 데이터 유실이나 서비스 중지에 대비한다.
• 읽기 작업보다 쓰기 작업이 더 빠르며, 일반적으로 RDBMS에 비하여 쓰기와 읽기 성능이 빠르다.

 

BASE: Basically Available, Soft state, Eventual consistency

모든 RDBMS가 ACID를 보장하는 것과 달리 NoSQL은 ACID를 보장하기 보다는 BASE 원칙을 따르는 것이 대부분이다.

 

Basically, Available

기본적으로 가용성을 유지한다.

 

Soft state

직접적인 입력이 없어도 시스템 상태를 변경 가능하다. 즉, 다른 데이터베이스에서 일어난 변경 사항을 현재 데이터베이스에도 자동으로 반영할 수 있다.

 

Eventual consistency

일관성이 즉시 유지되는 RDBMS와 다르게 최종적인 일관성을 보장한다.

 

→ NoSQL은 고가용성과 확장성을 위해 여러 시스템에 데이터 사본을 보유한다. 또한 한 시스템의 모든 데이터 항목에 대한 변경 사항은 다른 복제본으로 전파하여 일관성을 유지한다.

 

CAP Theorem

어떠한 분산 시스템도 일관성(Consistency), 가용성(Availability), 분할 허용(Partition tolerance) 3가지 속성을 동시에 지원하는 것은 불가능하다.

• Consistency(일관성)
  : 모든 노드들은 같은 시간에 동일한 항목에 대하여 같은 내용의 데이터를 제공한다.
• Availability(가용성)
  : 모든 client는 항상 read/write 연산이 가능하다. (24hours * 7days)
• Partition toleration(분할 허용)
  : 시스템은 물리적 네트워크 분할(메시지 전달 실패 또는 시스템 일부 고장)된 상태에서도 동작한다.

 

분산 데이터 시스템은 일관성, 가용성 및 분할 허용 간의 균형을 이루며, 모든 데이터베이스는 3가지 속성 중 2가지만 보장한다.

• 관계형 데이터베이스
  일반적으로 일관성(C)과 가용성(A)을 제공하지만 분할 허용은 제공하지 않는다.
  따라서 파티션 발생 시 시스템이 정지된다.
• NoSQL 데이터베이스
  일반적으로 가용성(A) 및 분할 허용(P)을 지원한다.

 

Consistency & Partition-tolerance

• 일관성 및 분할 허용(CP) 보장 및 가용성(A) 포기
• 일관성을 보장하기 위해 네트워크가 차단된 상태에서는 데이터베이스 사용 불가

 

Availability & Partition-tolerance

• 가용성 및 분할 허용(AP) 보장 및 일관성(C) 포기
• 읽기 요청이 수신되면 조회된 노드가 보유한 정보를 전달
• Client 별로 일치하지 않는 데이터를 읽을 수 있음

 

NoSQL 종류

---

데이터를 저장하는 방식에 따라 분류한다.

 

1. Key-Value Database

• 데이터를 키/값 쌍으로 저장한다.
• Unique한 key에 하나의 value를 가지고 있는 형태이다.
• 기본키(primary key)를 기반으로 작업한다.
• Random access에 유용하다.
• ex. DynamoDB, Redis, Riak

 

2. Document Database

• JSON 구조로 데이터가 저장된다. 즉 key에 해당하는 value 필드에 데이터를 저장하는 구조로, 저장되는 value의 데이터 타입이 document(XML, JSON 등)이다.
• key-value store의 확장된 형태로, 복잡한 쿼리에는 부적합하다.
• CMS 시스템, 블로그 플랫폼, 실시간 분석 및 전자 상거래 응용에 적합하다.
• ex. MongoDB, CouchDB, ElasticSearch

 

3. Column Database

• 데이터를 행 대신 열로 구성된다.
• 큰 데이터 셋 query에 장점이다.
• 데이터를 열에서 쉽게 사용할 수 있으므로 SUM, COUNT, AVG, MIN 등과 같은 집계 쿼리에 적합하다.
  • 행으로 데이터를 가져오면 오버헤드 발생 가능성이 높기 때문이다.
  • 범위 기반 데이터를 불러오기에 유리하기 때문이다.
• ex. Cassandra, Hbase, BigTable

 

4. Graph Database - neo4j

• 데이터를 node(object)와 edge(relationships)로 구성된다.
• Graph 구조의 데이터를 저장한다.
• 노드는 독립적으로 저장되며 노드 사이의 관계는 데이터와 같이 저장된다.
• 소셜 네트워크, 물류, 공간 데이터에 주로 사용한다.