[NoSQL] 정리

NoSQL의 등장 배경

- 수년 전 인터넷이 도입되고 얼마 전부터 SNS 서비스가 활성화되면서 컴퓨팅 시스템에도 변화가 찾아온다.

예전의 컴퓨팅 시스템은 기업의 업무를 자동화하고 효율화하는 데 그 목적이 있었다. 그래서, 기업의 업무 시스템은 해당 기업의 생산과 판매를 목적으로 하였고, 거기에서 생성되는 데이터의 양은 한계를 가지고 있었다. 그러나 2000년대에 들어서면서 인터넷의 발전과 함께 SNS 서비스가 활성화되면서 SNS 서비스 시스템은 특정 고객이 아닌 전 세계 사람들을 대상으로 하는 형태의 서비스로 발전하였고 이는 기존 기업 시스템에서 볼 수 없었던 대규모의 데이터를 생산해내었고 이 데이터는 기존 기업 데이터에 비해서 매우 단순한 형태를 띠게 되었다. 즉, 데이터의 패러다임이 한정된 규모의 복잡성이 높은 데이터에서 단순한 대량의 데이터로 넘어가기 시작하였다. 이는 기존의 데이터 저장 시스템으로는 해결할 수 없는 여러 가지 한계를 일으켰고 결국에는 새로운 형태의 데이터 저장 기술을 요구하게 되었다.

오라클 등으로 대변되는 기존 RDBMS 중심의 데이터 저장 기술 시장에 새로운 데이터 저장 기술 NoSQL이 등장하게 된 계기가 된다. NoSQL은 Not Only SQL의 약자로, 기존 RDBMS형태의 관계형 DB가 아닌, 다른 형태의 데이터 저장 기술이다. NoSQL이라고 해서 RDBMS 제품군(MS SQL, Oracle, Sybase, MySQL)등과 같이 공통된 형태의 데이터 저장 구조를 총칭하며, 제품에 따라 각기 그 특성이 매우 달라서 NoSQL을 하나의 제품군으로 정의할 수는 없다.

RDBMS와 다른 NoSQL의 특징

* 데이터 간의 관계를 정의하지 않음

- 가장 큰 특징 중의 하나는 RDBMS가 관계형 데이터베이스로 데이터의 관계를 외래 키 등으로 정의하고 이를 이용하여 조인 등의 관계형 연산을 한다고 하면, NoSQL은 데이터 간의 관계를 정의하지 않는다. 데이터 테이블은 그냥 하나의 테이블이며, 각 테이블 간의 관계를 정의하지도 않고 일반적으로 테이블 간의 조인도 불가능하다.

* RDBMS에 비해 훨씬 더 대용량의 데이터를 저장할 수 있음

- 태생이 RDBMS의 복잡도와 용량 한계를 극복하기 위한 만큼, 페타바이트 급의 대용량 데이터를 저장할 수 있다.

* 분산형 구조

- NoSQL은 기존의 RDBMS와는 다르게 하나의 고성능 머신에 데이터를 저장하는 것이 아니라, 일반적인 서버(인텔 계열의 CPU를 사용하는 상용 서버) 수십 대를 연결하여 데이터를 저장 및 처리하는 구조를 갖는다. 즉, 분산형 구조를 통해서 데이터를 여러 대의 서버에 분산하여 저장하고, 분산 시에 데이터를 상호 복제하여 특정 서버가 장애가 났을 때도 데이터 유실이나 서비스 중지가 없는 형태의 구조이다.

* 고정되지 않은 테이블 스키마

- RDBMS와는 다르게 테이블의 스키마가 유동적이다. 예를 들어 RDBMS의 경우 테이블이 다음과 같은 형태로 되어 있을 때 해당 테이블은 반드시 숫자, 이름 문자열, 주소 문자열만 들어갈 수 있다.

ex) RDBMS에서 간단한 테이블 구조 예제

ID: int

이름: varchar(255)

주소:[varchar(255)]

그런데 NoSQL은 대부분 이런 개념이 없다. ID로 사용하는 키 부분에만 타입이 동일하고 생략되지 않는(Mandatory) 필드로 지정하면 값에 해당하는 칼럼은 어떤 타입이든 어떤 이름이 오던 모두 허용된다. 즉 다음과 같이 ID 필드는 공통이지만, 데이터를 저장하는 칼럼은 각기 다른 이름과 다른 데이터 타입을 갖는 것이 허용된다.

ex) NoSQL에서 테이블 설계 예제

CAP 이론

- NoSQL은 분산형 구조를 띠고 있기 때문에 분산 시스템의 특징을 그대로 반영하는데, 그 특성중의 하나가 CAP 이론이다. 

분산 컴퓨팅 환경은 일관성(Consistency), 가용성(Availability), 분산 허용(Partitioning Tolerance)의 3가지 특징을 가지고 있으며, 이 중 두가지만 만족할 수 있다는 이론이다. NoSQL은 대부분 이 CAP 이론을 따르고 있다.

* 일관성(Consistency) : 분산된 노드 중 어느 노드로 접근하더라도 데이터 값이 같아야 한다는 기능적 특징이다. (데이터 복제 중에 쿼리가 되는 일관성을 제공하지 않는 시스템의 경우 다른 데이터 값이 쿼리될 수 있다.)

* 가용성(Availability) : 클러스터링된 노드 중 하나 이상의 노드가 실패(Fail)라도 정상적으로 요청을 처리할수 있는 기능을 제공하는 특징이다.

* 분산 허용(Partition Tolerance): 클러스터링 노드 간에 통신하는 네트워크가 장애가 나더라도 정상적으로 서비스를 수행할 수 있는 기능이다.

NoSQL의 분류

- NoSQL은 데이터 저장 구조에 따라 다음과 같이 크게 세 가지로 분류할 수 있다.

1. Key/Value Store

- 가장 기본적인 패턴으로, 대부분의 NoSQL은 다른 데이터 모델을 지원하더라도 기본적으로 Key/Value 개념을 지원한다. Key/Value Store란 고유한 키에 하나의 값을 가진 형태를 이야기한다. Put(Key, Value), Value := get(Key) 형태의 API로 접근한다.

Key	Value
Key	Value

Value는 String이나 Integer와 같은 Primitive 타입이 될 수도 있지만, 이 정도로는 우리가 일반적으로 사용하는 테이블 형태의 데이터를 저장할 수 없기 때문에 조금 더 확장된 개념을 사용하는데, 바로 Column Family라는 개념이다. 

Key 안에 (Column, Value) 조합으로 된 여러 개의 필드를 갖는데, 이를 Column Family라고 한다.

예를 들어 사용자 프로필을 저장하는 시나리오가 있을 때 사용자의 이름을 키로 한다면 성별, 주소, 나이들은 각각의 칼럼이 될 수 있다. Key 필드는 RDBMS에서 주 키(Primary Key), Column 필드들은 RDBMS의 일반 데이터 필드로 이해하면 된다. 프로그램 언어와 비교해서 생각한다면, Key/Value Store는 Map 데이터 구조와 유사하다. Oracle Coherence나 Redis와 같은 NoSQL이 이 데이터 모델을 기본 모델로 사용한다.

2. Ordered Key/Value Store

- Key/Value Store의 확장된 형태로, Key/Value Store와 데이터 저장 방식은 동일하나 데이터가 내부적으로 키를 순서로 정렬해서 저장한다. ex) 위의 그림에서 키를 기준으로 정렬

- 정렬이 별거 아닌 것 같지만 NoSQL 관점에서는 대단히 중요한 기능을 제공하게 된다. 뒤에 데이터 모델링 기법에서도 다루겠지만, NoSQL은 RDBMS의 ORDER BY와 같은 기능을 제공하지 않기 때문에 결과 값을 업데이트 날짜 등으로 정렬해서 보여주는 것은 이 Ordered Key/Value Store가 절대적으로 유리하다. 대표적인 제품으로는 아파치의 Hbase, Cassandra 등이 있다.

3. Document Key/Value Store

- Key/Value Store의 확장된 형태로, 기본적으로 Key/Value Store이다. 키에 해당하는 값 필드에 데이터를 저장하는 구조는 같으나, 저장되는 값의 데이터 타입으로 Document라는 타입을 사용하는데, Document 타입은 MS 워드와 같은 문서를 이야기하는 것이 아니라 XML, JSON, YAML과 같이 구조화된 데이터 타입을 일컫는 것으로, 복잡한 계층 구조를 표현할 수 있다.

ex) user: {

name: "suspect"

,hobby: "soccer"

,address:{state : "Seoul"

  nationality : "Korea"

  }

 } 

Document Store 기반의 NoSQL은 제품에 따라 다르기는 하지만 대부분 추가적인 기능(Sorting, Join, Grouping등)을 제공한다. 대표적인 제품으로는 MongoDB, CouchDB, Riak 등이 있다.

NosQL과 기존 RDBMS와의 차이

- NoSQL이 DBMS라고 생각해서 RDBMS와 같은, 또는 떨어지지만 유사한 기능을 제공할 것으로 생각하면 큰 오산이다.

NoSQL은 데이터를 저장하고 키에 대한 Put/Get만 지원한다. 즉, RDBMS로 치자면 다음과 같은 내용만 지원한다.

ex) Put : Insert into TABLE VALUES(KEY, value, value1, value2, ... , valueN)

    Get : Select * from TABLE where KEY="key"

물론 제품에 따라서 기능에 대한 지원 범위는 다르기는 하지만, 공통으로 고민해야 하는 기능은 다음과 같다.

* Sorting(SQL의 ORDER BY)

* Join (RDBMS에서 두 개 테이블의 외래 키를 이용하여 조인)

* Grouping (SQL의 GROUP BY)

* Range Query (where key>"start" and key < 'end"와 같이 일정 범위 내의 내용을 쿼리해오는 기능)

* Index(RDBMS에 인덱스를 지정하여 SELECT 쿼리 성능을 높이는 기능)

대용량의 데이터를 빠르고 안전하게 저장할 수 있다는 데서 분명히 훌륭한 기술이기도 하지만, 그만큼 기술적인 난이도가 높고, 다루기가 쉽지 않은 기술이다. NoSQL은 절대 모든 곳에 적용되는 특효약이 아니다. 제대로된 이해와 준비가 있어야만 사용할 수 있는 기술이다.

NoSQL과 RDBMS의 데이터 모델링 차이

* NoSQL을 사용해서 데이터 모델링을 하려면 근본적인 사상 2가지를 바꿔야 한다.

1. 개체 모델 지향에서 쿼리 결과 지향 모델링

- RDBMS의 모델링 기법은 저장하고자 하는 도메인 모델을 먼저 분석한 후에 개체 간의 관계를 식별하고 테이블을 추출해내고 테이블을 이용하여 쿼리를 구현하여 결과를 뽑아내는 방식이다.

- NoSQL의 경우에는 이 접근 방법을 역순으로 진행해야 한다. RDBMS에서 도메인 모델 -> [테이블 -> 쿼리] 순서로 진행했다면, NoSQL에서는 도메인 모델 -> [쿼리 결과 -> 테이블] 순서로 테이블을 디자인 해야 한다. RDBMS의 경우 여러 가지 최적화된 기능으로 테이블을 가지고 자유롭게 쿼리 결과를 뽑아낼 수 있지만, NoSQL의 경우 복잡한 쿼리 기능이 없기 때문에 반대로 도메인 모델에서 어떤 쿼리 결과가 필요한지를 정의한 후에 이 쿼리 결과를 얻기 위한 데이터 저장 모델을 역순으로 디자인해야 한다.

2. 정규화에서 역정규화로

- RDBMS 모델링에서는 데이터의 일관성과 도메인 모델과의 일치성을 위해서 데이터 모델을 정규화 한다. 그중에서도 같은 데이터가 두 개 이상의 테이블에 중복 저장하는 것을 제거하는데, NoSQL은 반대의 접근 방법이 필요하다. 쿼리의 효율성을 위해서 데이터를 정규화하지 않고 의도적으로 중복된 데이터를 저장하는 등의 비정규화된 데이터 모델 설계방식으로 접근해야 한다.

참고도서 : [조대협의 서버 사이드, 대용량 아키텍처와 성능 튜닝]