# NoSQL 데이터 모델링

* NoSQL 모델링은 관계형 모델링과는 반대로, 어플리케이션 특징적인 쿼리들로부터 시작된다.
 - 관계형 모델링은 전형적으로 가용한 데이터의 구조에 기반을 둔다.
   데이터 모델링의 메인 테마는 "내가 가지고 있는 답이 무엇인가"이다.
   즉, 관계형 모델링에서는 데이터 모델을 정의한 이후에, 어플리케이션에 맞는 쿼리를 개발한다.

 - NoSQL 데이터 모델링은 전형적으로 어플리케이션 특징적인 데이터 접근 패턴에 따라 모델링 된다.
   이에 모델링의 메인 테마는 "내가 가지고 있는 질문이 무엇인가" 이다.
   즉, NoSQL 모델링에서는 어플리케이션의 필요한 쿼리와 성능을 정의한 이후에, 그 요구사항에 부합하도록 데이터 모델을 구성한다.

* NoSQL 모델링은 관계형 데이터베이스 모델링보다 더 깊은 데이터 구조 및 접근 알고리즘에 대한 이해가 요구된다.
 
* 관계형 DB는 계층적 구조나 그래프 구조와 같은 데이터 모델을 저장하고 처리하기에는 적합하지 못하거나 불편하다.
  이러한 구조에 가장 적합한 것은 Graph Data Model이며, 다른 대다수의 NoSQL 솔루션들 역시 다양한 데이터 모델링 기법을 통하여 해결할 수 있다.

 

# NoSQL 데이터 모델링 기본 개념

(1) 비정규화
(적용성) : Key-Value Stores, Document Databases, BigTable-style Databases

비정규화는 데이터의 중복을 허용하라는 것이다.
즉, 쿼리 프로세싱을 간단히 또는 최적화하거나 사용자의 데이터를 특정한 데이터 모델에 맞추기 위하여 같은 데이터를 다중의 도큐먼트나 테이블에 복제하여 중복을 허용한다는 것이다.
본 절에서 소개하고 있는 모든 데이터 모델링 기법은 이러한 비정규화 기법을 기본으로 한다.
일반적으로 비정규화는 아래의 트레이드-오프가 있음을 기본으로 한다.

쿼리당 I/O 또는 쿼리 데이터 사이즈 VS 전체 데이터 사이즈
비정규화를 통하면 쿼리를 수행하기 위한 모든 데이터를 한 곳에 모아 놓고 쿼리를 실행하기 때문에 쿼리 수행을 위한 전체 I/O의 숫자 자체를 줄여 전체 성능을 향상시킬 수 있다.
하지만, 해당 데이터는 다른 쿼리 수행을 위하여 다른 도큐먼트(document)나 테이블(table)에 중복 저장되기 때문에 전체 데이터 사이즈는 필연적으로 증가한다.

쿼리 수행의 복잡도 VS 전체 데이터 사이즈
데이터 모델링 시점에서 데이터 자체의 정규화(데이터 중복의 제거)나 쿼리 수행 시점에서 데이터 간 연속적인 조인(join)은 쿼리 프로세서의 복잡도를 증가시킨다.
더욱이 시스템과 데이터 사이즈가 큰 분산 환경에서는 그 복잡도가 더욱더 높아진다.
정규화는 반대로 데이터를 비정규화하면 쿼리에 필요한 모든 데이터를 한 곳(Document나 table)에 쿼리-친숙한 구조로 모아 놓을 수 있기 때문에 전체적인 쿼리 프로세싱을 단순화하고 수행 시간을 단축시킬 수 있다.


(2) 어그리게이션
(적용성) : Key-Value Stores, Document Databases, BigTable-style Databases

대부분의 NoSQL 솔루션들은 '유연한 스키마'를 아래와 같이 제공하고 있다.

* Key-Value Store와 Graph Database의 경우 일반적으로 저장되는 값(value)들과 데이터에 대하여 어떠한 제약조건을 가지고 있지 않기에 다양한 임의의 포멧들로 구성될 수 있다.
또한 Key를 디자인할 때, 조합키(composite key)를 활용하여 다수의 레코드들을 하나의 항목(entity)으로 구성할 수 있다.
예를 들어, 사용자 계정은 어플리케이션 요구에 따라 다수의 엔트리를 포함한 하나의 조합키로 표현되어 하나의 도큐먼트나 테이블로 구성될 수 있다.

* BigTable 모델은 Value 안의 다양한 컬럼 패밀리와 또 그 안에 복수 개의 컬럼의 셋을 통해 유연한 스키마를 제공한다.

* Document Database는 태생적으로 schema-less한 속성을 가진다.

'유연한 스키마' 속성은 복잡하고 다양한 구조의 내부 엔티티(nested entities)를 가지고 있는 데이터 클래스를 구성 가능하게 한다.
이러한 특징은 다음의 큰 이점을 제공한다.

* 다양한 구조의 내부 엔티티 지원으로 일대다(1:n) 관계를 최소화하여 결과적으로 조인(join) 연산을 줄인다.
  이는 곧 수행 시간의 단축과 대용량 데이터의 지원을 저렴한 비용으로 가능하게 한다는 것을 의미한다.

* 하나의 도큐먼트 형태 또는 테이블 데이터 구조를 통하여 복잡하고 다양한 비즈니스 엔티티들을 담을 수 있다.
  이는 추후 확장성 및 변동성에 대한 유연한 대응을 가능케 한다.


(3) 응용 프로그램상의 조인
(적용성) : Key-Value Stores, Document Databases, BigTable-style Databases, Graph Databases

NoSQL은 태생적으로 데이터 쿼리 타임 시 JOIN을 고려하지 않았으며, 오히려 많이 제약하는 편이다.
더 정확하게 표현하자면 NoSQL을 사용하여 데이터 스토어 구성 시에는 쿼리 타임 시 조인이 발생하지 않도록 데이터 모델에 대한 비정규화와 어그리게이션을 수행하여 구성함을 기본 전제로 하고 있다.
즉, NoSQL에서의 데이터 모델은 데이터 자체 간의 관계와 속성에 따라 구성하기보다는 해당 데이터를 이용하는 응용 프로그램이 그 데이터를 어떻게 이용(질의)하는가에 따라 구조화되고 구성된다.

이것이 데이터의 정규화를 통해 중복을 최소화하여 일관성 및 정합성 보장을 원칙으로 하고 응용 프로그램이 데이터 질의 시에 정규화 되어 있는 데이터를 상호 JOIN 하여 하나의 완전한 테이블을 만들어 내는 관계형 모델과의 가장 큰 차이이다.

대용량 데이터에서 빠른 응답 성능과 확장성, 가용성을 최우선 목적으로 하는 NoSQL에서는 이러한 쿼리-타임 조인을 최대한 피하여 데이터 모델을 구성하도록 함을 가정하고 있다.
이 가정에 따라, JOIN 대상 데이터와 비정규화와 어그리게이션을 수행할 때의 문제점이 바로 JOIN 대상 데이터가 자주 변동 될 때와 다대다(n:m) 관계일 때이다.

대상 데이터가 빈번히 변경되는 경우는, 비정규화와 어그리게이션을 통하여 많은 entity에 해당 데이터의 중복을 허용해 놓았으므로, 해다아 데이터의 업데이트 시 아무리 NoSQL이 'eventually consittency' 속성을 가진다고 하여도 이를 모두 찾아 하나씩 업데이트해야 하는 비용은 매우 커질 수밖에 없다.
이런 경우에는 차라리 빈번히 변경되는 데이터만을 추려내어 쿼리 타임 시에 조인을 수행하는 것이 오히려 저렴할 수 있다.


출처 : 대용량 데이터 분석 및 처리를 위한 Hadoop&NoSQL

경축! 아무것도 안하여 에스천사게임즈가 새로운 모습으로 재오픈 하였습니다.
어린이용이며, 설치가 필요없는 브라우저 게임입니다.
https://s1004games.com

[출처] http://develop.sunshiny.co.kr/882