NoSQL 데이터 모델링 2

NoSQL 데이터 모델링 패턴

NoSQL 데이터 모델링 패턴은 Key/Value Store 구조의 PUT/GET 밖에 없는 단순한 DBMS에 대해서 다양한 형태의 Query를 지원하기 위한 테이블을 디자인하기 위한 가이드이다.

특히, RDBMS에는 있는 기능들인,

1. Order by를 이용한 Sorting

2. Group by를 이용한 Grouping

3. Join 등을 이용하여,

Entity 간의 Relationship정의 그리고 Index 기능

을 활용하여 데이터를 쿼리하는데, 상당히 유용하게 사용합니다.

NoSQL은 이러한 기능들을 가지고 있지 않기 때문에, NoSQL 내에서 데이터 모델링을 통해서 이러한 기능들을 구현하는 방법에 대한 가이드를 제공합니다.

크게 3가지의 모델링 패턴에 대해서 설명합니다.

1. 기본적인 데이터 모델링 패턴

2. 확장된 데이터 모델링 패턴

3. 계층 데이터 구조에 대한 모델링 패턴

기본적인 데이터 모델링 패턴

다음은 NoSQL의 데이터 모델링을 할 때, 가장 기본적으로 많이 사용되는 패턴들이다.

1) DeNormalization

Denormalization은 같은 데이터를 중복해서 저장하는 방식이다.  Normalization이 정규화라는 의미로 중복되서 사용하는 경우를 방지해 질의의 효율을 높이는 방식이므로,

반대되는 방식이 바로 Denormalization이다.

 Denormalization을 하면, 테이블 간의 JOIN을 없앨 수 있다.

NoSQL에서는 JOIN을 지원하지 않기 때문에, 두 테이블을 JOIN해서 데이터를 가지고 오는 로직을 구현하려면,

각 테이블에서 데이터를 각각 가져와서 애플리케이션에서 합쳐야 하기 때문에, 2번의 I/O가 발생한다.

Denormalization을 적용하여, 하나의 테이블에 JOIN될 데이터를 중복 저장하게 되면 1번의 I/O로도 데이터를 가지고 올 수 있다.

예를 들어, 사용자 정보를 저장하는 User테이블과, 도시 이름을 저장하는 City테이블이 있다고 하자.

이런 테이블 구조에서 사용자 별로 "이름, 나이, 성별, 우편번호"를 출력하는 쿼리는 다음과 같다.

select u.name, u.age, u.sex, c.zipcode, from user u, city c where u.city=c.city

위 테이블 구조를 그대로 NoSQL에서 똑같은 쿼리를 보내려면 두번이 필요합니다.

select $city, name, age, sex from user where userid="사용자ID"

select zipcode from city where city=$city

식으로 구현을 해야합니다.

User테이블에서 city값을 읽어온 후에 다시 city table에 해당 city값을 가지고 다시 zipcode를 가져와야합니다.

단순한 예로는 한번더 발생을 하지만 테이블이 복잡해지면 복잡해질 수록 점점더 JOIN에 대한 테이블 수는 NoSQL로의 I/O수가 엄청 나게 늘러가기 때문에,

이를 해결하면서 NoSQL로 테이블을 구현하려면, 아예 처음부처 Join이 되어 있는 테이블을 하나 더 만들어 버리면 됩니다.

위 그래프처럼 아예 JOIN시 가져오려고 했던 Value들을 모아놓은 하나의 테이블을 만들어서 요청시 사용하면 된다.

이런 식으로 Denomalization하여 데이터의 중복을 허용했을 때의 장단점은 다음과 같습니다.

장점은

성능향상 - JOIN을 위해서 몇번씩 쿼리를 하지않아도 되기 때문에, 당연히 쿼리 성능이 올라간다.

쿼리 로직의 복잡도가 낮아짐 - JOIN에 대한 로직이 필요 없이, 한번에 데이터를 가지고 오기 때문에, 쿼리 로직이 단순해 집니다.

단점은

데이터 일관성 문제 발생 가능 - age, sex, zipcode 등을 insert하거나 update했을 때, User, City Table뿐만 아니라 UserZipCode 테이블도 업데이트해야함.

- 같은 User 테이블을 업데이트 하다가 에러가 나는 경우, UserZipCode 테이블은 업데이트가 안된 상태이면, 데이터 불일치 발생.

스토리지 용량 증가 - 당연하게 Denormalization으로 데이터의 중복이 늘어나기 때문에 용량이 증가할 수 있다

NoSQL은 JOIN이 어렵고 애플리케이션 상에서 구현을 하여 RDBMS에서 사용하는 기능을 커버한다고 해도 성능이 안나오거나 구현이 어려운 경우가 많기에,

사실상 사람들은 Denormaliztion을 통해서 중복한 테이블을 만들어서 전용으로 사용하여 성능과 로직의 단순화라는 효과적인 모델링으로 사용합니다.

2) Aggregation

DropBox, SugarSink와 같은 파일을 저장하는 개인 스토리지 서비스가 있다고 가정하자.

이 서비스는 파일에 대한 정보를 저장하고, 음악 동영상, 사진 등의 파일의 종류에 따라서 추가적인 메타 정보를 저장합니다.

ERD(Entity-Relationship Diagram)를 기준으로 개체를 표현해보면 다음과 같다.

NoSQL의 재미있는 특성 중의 하나가 Scheme-less 또는 Soft Scheme라는 특성인데,

RDBMS의 경우 테이블에 데이터를 넣을때, 반드시 테이블의 구조에 맞도록 넣어야 한다.

컬럼수와 이름도 지켜야 하고, 각 컬럼에 해당 하는 데이터 타입도 맞추어야합니다.

또한, 테이블 안의 모든 ROW는 같은 컬럼을 가져야합니다.

반면, NoSQL의 경우에는 Key만 똑같다면 , 각 ROW는 제멋대로라도 상관이 없습니다.

제멋대로 라는 의미는 컬럼에 들어가 있는 데이터도 있고 안들어가 있는 데이터도 있다라는 이야기입니다.

그래서 테이블을 보다보면, 데이터가 없어서 해당하는 컬럼이 아예 존재 하지 않는 경우가 있습니다.

물론 데이터를 넣어서 저장하는 쿼리가 오면 다시 컬럼은 생깁니다.

테이블 안에 컬럼은 원하는 방식으로 저장할 수도 있고 데이터 타입도 다르게 해도 됩니다.

이를 데이터가 구조는 가지고 있지만 , 구조가 각각 다를 수도 있는 것은 허용하는 것으로 하여 Soft-Scheme or Schemeless라고 표현합니다.

이 특성을 이용하면, 위의 데이터 모델을 하나의 테이블로 합칠 수 있다.

1:N과 같은 복잡한 엔터티들의 관계를 손쉽게 하나의 테이블로 바꿀 수 있고, 이는 결과적으로 JOIN의 수를 줄여서 Query 성능을 높이는 방법이 됩니다.

3) Application Side Join

NoSQL은 JOIN이 거의 불가능합니다. 지원하는 NoSQL 제품도 있지만, 거의 없다고 보시면 되고 데이터 모델링을 JOIN이 없는 것을 고려해서 해야합니다.

그래서 사용하는 것이 Denormalization 과 Aggregation 입니다.

그리고 앞으로 설명할 데이터 모델링 패턴을 사용하는 것인데, 그래도 JOIN이 사용되어야만 하는 경우가 있습니다.

이때는 NoSQL의 쿼리로는 불가능하고, NoSQL을 사용하는 클라이언트 Application단에서 로직으로 처리해줘야합니다.

예를 들면, TABLE 1,2 두개에서 TABLE 1의 컬럼 중 하나가 Foreign Key로써 TABLE 2의 데이터를 가리키고 있다면,

Application Join을 하려면, Table 1에서 Primary Key로 한 ROW 를 읽어온 후에, TABLE 2를 가리키는 컬럼 값을 Key로 해서 다시 TABLE 2에 쿼리를 합니다.

Application Side Join 은 필요한 테이블 수 만큼 NoSQL로의 Request/Response I/O가 발생하는 만큼 다소 Application 단에서 부담이 있지만,

반대로, Denormalization등에 비해서는 스토리지 사용량을 절약할 수 있습니다.

* 추가적으로 Map & Reduce 기능을 이용한 Server Side Join 의 방법으로 JOIN기능을 할 수도 있습니다.

 Application Side Join의 반대기능으로 Server Side Join 이라고 부릅니다.

NoSQL에는 기본적으로 Join기능이 없습니다.

Server Side Join이라는 것은  Riak이나 MongoDB와 같은 일부 NoSQL DB들은 RDBMS의 Stored procedure를 지원합니다.

Stored Procedure이라는 것은 일련의 어떠한 작업을 하기위해서 구현된 쿼리들의 집합을 마치 하나의 함수 처럼 실행하기 위한 집합입니다.

예를 들면, 아래의 (1) 정의 부분은 일련의 쿼리들로 약 20줄정도로 집합되어 있습니다.

하지만 이것들을 가지고 사용할 때에는 (2) 실행 부분처럼 단 하나의 함수처럼 사용을 합니다.

이렇게 단 하나의 함수처럼 사용하는 형식을 저장 프로시저를 지원한다고도 표현하고,

사용하는 SELECT 함수를 저장 프로시저라고도 합니다.

이 Stored Procedure 중에 Map & Reduce라는 이름으로 이 기능을 지원합니다.

위 Application Side Join의 Application 안에서 JOIN을 위해서 했던 과정들을 서버에서 똑같이 대신해서 리턴하는 방식입니다.

리턴하기 위해서 사용되는 로직들은 NoSQL에서 지원하는 언어 형식으로 통해서 구현되고 변환되어 사용되고, NoSQL Engine 위에서 수행됩니다.

NoSQL을 실행시키는 엔진 쪽에서 이러한 처리를 하기 때문에, 물론 장점은 Application 측면에서 프로그램의 로직을 걱정하지 않아도 되고, 부담이 없지만,

반대로 그 부담은 서버와 서버에 속해있는 NoSQL의 리소스를 사용하는 측면에서 부담이 가중됩니다.

확장된 데이터 모델링 패턴

1) Atomic aggregation

NoSQL에서 고민해야할 것 중에 하나가 두개이상의 테이블을 업데이트할 때, 무엇부터 어떤 작업을 먼저해야되는지에 대해서 정리하는 트랜잭션 관리 문제가 있다.

그림에서 두개의 테이블을 업데이트 하는 경우,

1번 테이블을 업데이트 한 후에, 애플리케이션 로직이나 NoSQL의 장애로 인해서 2번 테이블이 업데이트되지 않을 수 있습니다.

이 경우 데이터의 일관성 문제를 발생시킬 수 있습니다. 그래서 솔루션으로 테이블을 합쳐버리는 방법이 있을 수 있습니다.

하나의 테이블에 대해서는 NoSQL도 atomic operation(원자성)을 보장하기 때문에 트랜잭션을 보장하기 때문에, 트랜잭션을 보장 받을 수 있습니다.

구현 패턴상으로는 Aggregation과 동일한데, Aggregation은 1:N의 Relationship 관계에서 Join을 업애서 쿼리의 성능향상을 하기 위한 것이고,

Atomic Aggregation은 트랜잭션 보장을 통한 데이터 불일치성을 해결하기 위함입니다.

예를 들어 사용자 정보가 UserAddress, UserProfile, UserId 라는 이름의 3개의 테이블로 분산되어 있을 때,

사용자를 생성하는 경우, 이 3개의 테이블에 Insert를 해줘야합니다. 그러나 테이블이 3개로 분산되어 있기 때문에,

동시에 테이블에 저장을 하는 경우, 장애시 트랜잭션에 대한 보장이 되지 않습니다.

이를 해결해야하는데 이를 해결하기 위해서는 atomic aggregation 패턴을 적용하여,

이 3개의 테이블을 User 테이블의 필드로 집어 넣게 되면 하나의 테이블이 되어지기 때문에, 장애나 에러로 인한 트랜잭션 불일치 문제를 방지할 수 있습니다.

2) Index Table

NoSQL은 RDBMS처럼 Index가 있지 않기 때문에 , Key 이외의 필드를 이용하여 Search를 하면, 

전체 Table을 Full Scanning하거나 아니면 Key 이외의 필드에 대해서는 아예 Search가 불가능합니다.

이 문제를 해결하기 위해서 Index를 위한 별도의 Index Table을 만들어서 사용할 수 있는데, 상당히 많이 쓰는 솔루션 중에 하나입니다.

예를 들어, 파일 시스템을 NoSQL에 저장한다고 했을 때, 파일 테이블은 다음과 같은 구조를 같습니다.

여기서 특정 디렉토리에 있는 파일만을 리스트업 하고 싶다면, 별도의 Index Table을 다음과 같이 만들면 됩니다.

Cassandra 또는 Riak과 같은 일부 NoSQL에서는 제품적으로 Secondary Index라는 이름으로 Key이외의 필드를 Index로 지정하는 기능이 있습니다.

그런데 이 기능들은 Index Table을 사용하는 것보다 성능이 떨어집니다.

만약에 Secondary Index를 사용하는 사용자라면 반드시 Index Table 패턴과의 성능 비교를 해보고 사용하면 됩니다.

당연히 Secondary Index를 사용하면 이미 구현되어 있는 SaaS형태의 서비스이기 때문에 편하지만,

성능면에서 봤을 때는 무시 못할 정도로 Index Table과 차이가 날 수 있습니다.

3) Composite Key

NoSQL에서는  Key를 어떻게 정의하느냐가 매우 중요합니다.

특히, Ordered Key-Value Store의 경우에는 이를 이용하여 order by와 같은 Sorting 기능이나, Grouping을 구현할 수 있습니다.

Composite Key는 하나 이상의 필드를 deliminator를 이용하여 구분지어 사용하는 방법으로 RDBMS의 복합키(Composite primary key)와 같은 개념.

단, RDBMS는 여러개의 컬럼을 묶어서 PK로 지정을 하지만, NoSQL은 한 컬럼에 deliminator를 이용하여 여러개의 키를 묶어서 넣습니다.

아해 예제를 보겠습니다. PC의 디렉토리를 Ordered Key-Value Store에 저장한다고 하면,

Windows 하위 디렉토리를 가지고 올 때, "windows:etc:부터 쿼리를 해서, 다음 row를 반복적으로 쿼리해서,

Key가 windows로 시작하지 않을 때까지 읽어오면, windows 디렉토리의 하위 디렉토리를 모두 가지고 올 수 있습니다.

노드가 추가, 삭제되더라도, 내부적으로 Sorting이 되기 때문에, 문제없이 사용이 가능합니다.

단, Key값을 선택할 때 주의해야할 사항은 "특정 서버로의 몰림 현상"을 들 수 있습니다. 설명해보겠습니다.

NoSQL은 특성상, N개의 서버로 구성된 클러스터입니다. 

(여기서 클러스터가 갑자기 나온이유는 NoSQL은 샤딩을 통해서 무한히 확장할 수 있는 손쉬은 확장 구조를 가질 수 있습니다.)

그리고 데이터는 Key를 기준으로 N개의 서버에 나눠서 저장을 합니다.

예를 들어, Key Range가 A~Z 26개라고 가정하고 , 클러스터의 서버의 수가 26대라고 하면,

각 서버는 알파벳 하나씩 1번 서버-A, 2번 서버-B 이런 식으로 총 26개의 알파벳을 서버가 하나씩 맞을 수 있습니다.

이 Key 값을 "City:User Name"으로 했다고 가정하면,

우리나라에서는 5000만의 인구라고 가정하면, 1000만의 인구가 서울에 살고 있으니까 1/5가 살고 있고 있으니,

총 데이터중 20%는 "Seoul:XXX"로 시작하는 Key 값을 가지게 될 것입니다.

즉, 서버 26대 중에서 알파벳 S를 담당하는 서버 한대에서 20%의 부하를 처리하게 됩니다.

서버가 26대이니, 각 서버에서 처리해야하는 부하의 기준은 평균 100/26 = 약 4%정도가 되어야하는데,

예상치보다 5배가 넘는 많은 로드를 처리해야하기 때문에 성능 저하를 유발 할 것입니다.

이러한 이유로 "특성서버로의 몰림 현상"을 유발시키지 않을 부하가 골고루 분산될 수 있는 Key를 선정하는 것이 좋습니다.

4) Inverted Search Index

검색 엔진에서 많이 사용하는 방법입니다.

검색 엔진은 사이트의 모든 페이지를 검색 로봇이 검색해서 문서내의 단어들을 색인하여 URL에 맵핑해서 저장해 놓습니다.

key에는 해당 URL, Value에는 해당 URL에서 나온 단어들을 저장합니다.

검색은 단어를 키로 검색이 되기 때문에, 위의 테이블 구조에서는 Value에 검색 키워드들이 들어가 있기 때문에,

효과적으로 검색할 수 없습니다. 왜냐면 Key값을 기준으로 value를 찾아서 그 값들을 비교해야하는 데 그러면 연산이 두번이 생겨버립니다.

그래서 여기서 해결해야하는 것은 Value에 들어있는 단어들을 효과적으로 활용하기 위해서는 어떤 방식으로 데이터를 저장해야하는 가입니다.

여기서의 솔루션은 반대로 Key-키워드(단어), Value-해당 키워드들이 저장된 URL

로 저장을 반대로 하여 키워드가 맞으면 Value에 저장되어 있는 URL를 꺼내다 쓰는 식으로 저장해서 활용합니다.

이렇게 Value 내용은 Key에 저장하고, Key의 내용을 Value에 저장하는 패턴은 Inverted Search Index라고 합니다.

5) Enumerable Keys

셀 수 있는 Key라고 생각하면 됩니다. Key에 대해서 자동으로 카운터를 올려주는 기능입니다.

이 기능을 가지고 첫번째 키는 자동으로 1번, 100번째 저장된 키는 100번으로 자동으로 키의 숫자를 셀 수 있게 붙여주어서,

데이터에 대한 traverse 기능을 제공합니다. 즉, 100번키를 가지고 왔는데 이 앞뒤의 값을 알 수 있습니다. Sequential한 키를 사용했기 때문에,

당연히 앞 뒤 값은 99 101번 키로 해서 Value를 가지고 올 수 있습니다.

계층 데이터 구조에 대한 모델링 패턴

NoSQL들은 데이터모델이 Key-Value, Ordered Key-Value, Document 등 여러가지가 있지만, 기본적으로 row, column을 가지고 있는 테이블 저장구조입니다.

어플리케이션 개발 중에는 이런 테이블 구조뿐만 아니라 Tree와 같은 계층형 데이터 구조를 저장해야할 경우가 있는데,

테이블 구조의 저장 구조를 갖는 NoSQL의 경우에는 이러한 계층형 구조는 저장하는 작업이 쉽지는 않습니다.

RDBMS의 경우에도 이런 계층형구조를 저장하기 위해서 많은 고민을 했는데, RDBMS는 솔루션에서 기능적으로, 데이터모델링을 해서도 모두 계층형 구조를 지원합니다.

여기서 소개하는 NoSQL에서 계층형 구조를 저장하는 기법은 RDBMS에서 사용하는 기법들을 많이 참고 했습니다.

추가적인 기법은 RDBMS에서 사용하는 기법들을 많이 참고했고, RDBMS의 Tree구조 저장 기법을 참고 했습니다.

1) Tree Aggregation

Tree 구조 자체를 하나의 Value에 저장하는 방식입니다. JSON이나 XML 등을 이용해서, 트리구조를 정의하고, Value를 저장하는 방식입니다.

Tree에 저장할 데이터의 종류가 많이 않고, 변경이 많이 없는 경우 사용하기 좋습니다.

2) Adjancent Lists

Adjacent List 구조는, 전통적인 자료 구조에서 사용하는 Linked List와 같은 자료 구조형을 사용합니다.

각 Tree의 노드에 parent node에 대한 포인터와 child node들에 대한 포인터를 저장하는 방식입니다.

Tree의 내용을 검색하려면, root 노드에서 시작해서 child node 포인터를 이용하여, 값을 가져오는 방식입니다. 이를 Tree Traversing이라고 합니다.

특정 노드를 알면, 해당 노드의 상위, 하위 노드를 자유롭게 Traversing 할 수 있어서 Traversing 에는 장점을 가지고 있지만,

반대로 하나의 노드를 이동할 때마다, 포인터를 이용해서 매번 쿼리를 요청해야하기 때문에, Tree의 크기가 크다면 NoSQL로의 I/O가 엄청나게 많이 발생합니다.

트리의 노드 수가 N이면, 다 이동시마다 이동 요청을 해야하기 때문에 N번 쿼리가 발생합니다.

아래 그림을 보면 파일 디렉토리를 저장하는 자료 구조를 만든다고 했을 때, Directory라는 테이블을 정의하고,

이 테이블에는 디렉토리 명과 상하위에 있는 디렉토리의 이름을 저장하도록 합니다.

구현이 쉬운 편이긴 하지만 Tree 구조 Traverse에 많은 I/O를 유발하기 때문에, 큰 Tree구조를 저장하거나 잦은 Read가 있을 때는 권장하지 않습니다.

즉 단점은 찾아서 쓰려고 움직이는 리소스가 더 많이 쓰이기때문에, 빈번한 접근으로 사용하는 DB는 적합하지 않다는 것입니다.

물론 여기서도RDBMS에서는 이런 Tree 구조 Traversing을 지원하기 위해서 Recursive 쿼리에 대해서 native recursive function을 지원함으로써,

Tree 구조에 저장을 지원합니다. 여기서 Recursive Query는 반복적으로 사용하는 쿼리를 말합니다.

3) Materialized Path

Materialized Path는 Tree 구조를 저장할 때, root에서 부터 현재 노드까지 전체 경로를 key로 저장하는 방법입니다.

이 방법은 구현은 어렵지 않고, 그에 비해 효율적인 저장 방식입니다.

특히 Key에 대한 Search를 할 때, Regular Expression을 사용할 수 있으면 다양한 기능을 하는 쿼리를 만들 수 있습니다.

일반적인 Key-Value 데이터 모델은 적용하기 힘들고, MongoDB와 같은 Document DB는 Regular Expression을 지원하기 때문에, 효과적으로 사용할 수 있습니다.

4) Nested Sets

Nested Sets의 기본 원리는 Node가 포함하는 모든 Child Node에 대한 범위 정보를 가지고 있습니다.

먼저 예를 보고 설명하자.

각 Node는 배열이나 리스트에 Sorting된 형태로 저장되어있습니다.

각 Node는 자신이 포함하는 모든 Sub Tree(Child Node)들이 포함된 Start와 End Index를 저장합니다.

아래 A는 전체 Sub Tree를 포함하기 때문에 2~9번에는 A Sub Tree의 내용이 됩니다.

C노드의 경우, 자신이 포함하는 모든 Child Node는 4~9에 포함되어 있기 때문에, Index를 4~9로 저장합니다.

즉, 위에서 아래로, 왼쪽에서 오른쪽으로 순서로 진행되면서, 각 노드의 자손(자식, 손자 등)의 Index를 기록합니다.

각 노드만 안다면, Sub Tree를 start, end Index만 있으면 쭈욱 읽어서 가져오면 되기 때문에 매우 빠른 성능을 보장합니다.

단, 이 데이터 구조는 update에 취약해서 update가 발생했을 경우, Index를 다시 재배열해야하는 최악의 경우가 발생합니다.

예를 들면, 위의 예제에서 B 노드 아래에 J노드를 추가하는 경우, J 노드의 Index는 3이 되어야하고, 3번 Index부터는 모두 +1씩 더해져야하며,

Child Node의 값 역시 모두 변화해야 합니다.

트리 생성 후에, 변화가 없는 대규모 트리등을 저장하는데 유용하게 사용될 수 있습니다.

결론

지금까지 NoSQL 적용시 사용할 수 있는 데이터 모델링 패턴에 대해서 살펴보았습니다.

기본 패턴은 대부분의 NoSQL 솔루션에 적용할 수 있고,

확장된 모델링 패턴의 경우에는 NoSQL이 지원하는 기능이나 데이터 구조(KV, Ordered KV, Document 등)에 다라서 적용될 수 있습니다.

NoSQL을 이용한 시스템을 개발할 때는

1. 데이터 모델링이 80%이상이다. 선정한 NoSQL과 애플리케이션의 특성에 맞는 데이터 모델링에 집중하자.

2. NoSQL은 어떤 솔루션이 좋고 나쁨이 없다. 어떤 솔루션이 특성이 어떻다는 것만 있기 때문에 반드시 데이터 모델과 내부 아키텍쳐 두가지를

파악한 후에, 애플리케이션의 특성에 맞는 NoSQL을 선정해야 합니다.

3. 하나의 NoSQL로 전체 데이터를 저장하려고 하면 안됩니다. NoSQL은 데이터 구조가 다양하지만, 애플리케이션들은 하나의 단순한 데이터 구조로

저장할 수 없는 데이터가 반드시 존재하기 때문입니다.

 RDBMS와 혼용하거나, 다른 NoSQL과 혼용하거나하여 성능면에서는 캐싱 솔루션과 혼용하여 사용할 수 있도록 고려해야한다.

NoSQL은 놀라운 성능과 확장성을 제공하지만, 많은 연구와 노력이 필요합니다.

Oracle과 같은 데이터베이스를 사용할 때에서, 전문 DBA를 두고, 튜닝에 시간을 두고, 데이터 모델을 만들고, 튜닝을 합니다.

그만큼 공을 들여서 하는 것과 마찬가지로 NoSQL도 오픈소스지만 쉽지않은 데이터베이스이기 때문에 그만큼 많은 노력과 연구가 필요합니다.

* Reference

1. NoSQL 데이타 모델링 #2-데이터 모델링 패턴 - http://bcho.tistory.com/666