NoSQL 데이타 모델링 #1-데이타모델과, 모델링 절차

NoSQL 데이타 모델링 #1

Facebook Server Side Architecture Group
http://www.facebook.com/groups/serverside
조대협

빅데이타,클라우드,NoSQL은 요즘 기술적인 화두중에 하나이다. 그중에서도 NoSQL은 많은 사람이 관심을 갖고 있음에도 불구하고, 기존의 RDBMS 데이타 모델링 관점에서 접근을 하기 때문에, 많은 문제를 유발한다. NoSQL은 데이타 베이스이기도 하지만 RDBMS와는 전혀 다른 성격을 가지고 있고, 접근 방식도 틀리다.

특히 테이블 구조를 정의 하는 데이타 모델에 따라서 NoSQL의 성능은 하늘과 땅차이만큼 차이가 난다. 이 글에서는 NoSQL의 데이타 모델링 기법에 대해서 소개하고자 한다.

※ 깨지는 그림은 클릭해서 봐주세요.

NoSQL 데이타 모델

데이타 모델링에 앞서서 NoSQL이 어떤 구조로 데이타를 저장하는지를 먼저 이해할 필요가 있다. NoSQL의 데이타 모델링 패턴은 아래와 같이 크게 3가지 패턴정도로 구분된다.

1.     Key/Value Store

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

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

예를 들어, 사용자 프로필을 저장하는 시나리오가 있을 때, 사용자의 이름을 KEY로 한다면, 성별,주소,나이들은 각각의 Column이 될 수 있다. 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와 데이타 저장 방식은 동일하나, 데이타가 내부적으로 Key를 순서로 Sorting되서 저장된다.

Sorting이 별거 아닌것 같지만, NoSQL 관점에서는 대단히 중요한 기능을 제공하게 된다. 뒤에 데이타 모델링 기법에서도 다루겠지만, NoSQL은 RDBMS의 Order By와 같은 기능을 제공하지 않기 때문에 결과값을 업데이트 날짜등으로 소팅해서 보여주는 것은 이 Ordered Key/Value Store가 절대적으로 유리하다.

대표적인 제품으로는 Apache의 Hbase, Cassandra 등이 있다.

3.     Document Key/Value Store

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

아울러, Document Store 기반의 NoSQL은 제품에 따라 다르기는 하지만 대부분 추가적인 기능 (Sorting,Join,Grouping)등의 기능을 제공한다.

대표적인 제품으로는 MongoDB,CouchDB,Riak 등이 있다.

그리고 여기서는 구체적으로 다루지 않지만 Graph나 Tree구조와 같은 데이타 구조를 저장하기 위해서 최적화된 Neo4J등의 NoSQL이 있다. 만약에 테이블 구조의 데이타가 아니라 Graph 구조의 데이타를 저장하고자 한다면 Neo4J를 한번 체크해보기 바란다.

RDBMS와 NoSQL의 차이

NoSQL이 DBMS라고 생각해서 RDBMS와 같은, 또는 떨어지지만 유사한 기능을 제공할것이라고 생각하면 큰 오산이다. NoSQL은 데이타를 저장한다. 그리고 Key에 대한 Put/Get만 지원한다. RDBMS로 치자면

Put : Insert into TABLE VALUES(KEY,value1,value2,…,valuen)

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

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

Ÿ   Sorting (SQL의 Order By)

Ÿ   Join (RDBMS에서 두개의 Table을 Foreign Key를 이용하여 join)

Ÿ   Grouping (SQL문의 group by)

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

Ÿ   Index (RDBMS에 Index를 지정하여 select query 성능을 높이는 기능)

이다. RDBMS에서는 너무나도 익숙하게 사용했던 기능들이기 때문에, 막상 이 기능들을 빼고 데이타를 다루고자 하면 매우불편하다. 여기서는 이러한 기능들을 “NoSQL 데이타 모델링 패턴” 소개를 통해서 NoSQL에서 어떻게 구현할 수 있는지 알아볼 것 이다.

NoSQL 데이타 모델링 시작하기

NoSQL 데이타 모델링이란, NoSQL에 저장할 데이타들의 구조, 즉 테이블 설계를 하는 것을 정의한다. NoSQL도 DBMS이기는 하지만, 우리가 지금까지 익숙하게 사용해왔던, RDBMS와는 그 특성이 매우 다르기 때문에 접근 방법을 바꿔야 한다.

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

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

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

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

NoSQL의 경우에는 이 접근 방법을 역순으로 진행해야 한다.

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

2)     정규화(Normalization)에서 비정규화(Denormalization)

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

NoSQL 데이타 모델링 절차

그러면, RDBMS와 NoSQL의 두가지 결정적인 차이를 인식하고, NoSQL 기반의 데이타 모델링 절차를 살펴보자.

1.     도메인 모델 파악

먼저 저장하고자하는 도메인을 파악한다. 어떤 데이타 개체가 있는지 개체간의 관계는 어떻게 되는지등을 분석하고 ERD를 그려서 도식화 한다. RDBMS의 모델링 접근 방법이고, NoSQL에서는 이렇게 하지 않고 바로 애플리케이션 관점으로 접근하는 경우도 많은데, 도메인 모델 분석 없이 필자의 경우에는 이런 방식에는 반대이다. NoSQL도 데이타베이스이고 저장할 데이타에 대한 명확한 이해 없이는 제대로된 데이타 모델이 나올 수 없다.

다음은 간단한 블로그 시스템의 데이타 도메인 모델이다. 이 블로그 시스템은

Ÿ   사용자 ID 기반으로 블로그의 분류(Category)를 가지고 있고,

Ÿ   분류별로 글을 작성할 수 있으며,

Ÿ   글에 파일을 첨부할 수 있고,

Ÿ   댓글을 달 수 있는 블로그이다.

Ÿ   이번 예제에서는 검색이나 페이징 기능은 제외한다. (단순화 하기 위해서)

2.     쿼리 결과 디자인 (데이타 출력형태 디자인)

다음으로 가장 중요한 과정인 쿼리 결과 디자인이다. “도메인 모델”을 기반으로 애플리케이션에 의해서 쿼리 되는 결과값을 먼저 정해야 한다.

앞서 예를 든 블로깅 시스템을 다시 살펴보자

①     화면 좌측 상단에는 블로그 사용자의 포스팅 분류명들을 목록 식으로 출력한다.

②     포스팅 출력 화면에는 상단에, 포스팅의 분류명과 제목을 출력하고 다음에는 포스팅 날짜, 본문 내용을 출력한다.

③     다음에는 첨부파일들을 출력하는데, 첨부파일 업로드 날짜와 파일명을 차례대로 출력하고, 파일에 대한 링크를 출력한다.

④     마지막으로 댓글을 출력하는데, 댓글에는 작성일과, 작성자 이름과 댓글 내용을 출력하고, 작성자 이름에는 이메일을 링크한다.

이 출력 형식을 기반으로, 어떤 쿼리가 필요한지를 정의해보자

①     전체 분류 출력

select categoryID,name from Category where userID=”사용자ID”

②     포스팅의 분류,제목,날짜,본문 출력

select po.postID,po.Contents,po.date,ca.name
from Category ca,Post po
where userID=”사용자ID”
order by date desc

③     첨부 파일 출력

select fileID,filename,date,fileLocation
from Attachment
where userID=”사용자ID” and postID=”현재 포스팅 ID”
order by date desc

④     댓글 출력
select userID,email,Contents,date
from Comment
where userID=”사용자ID” and postID=”현재 포스팅 ID”
order by date desc

대략적으로 4개의 쿼리가 필요하다. (물론 RDBMS 실제 구현에서는 좀더 최적화 할 수 있겠지만, 이해를 돕기 위해서 단순 구현하였다.) 그러면, 어떤 형태의 데이타 테이블들이 출력되는가?

위와 같이 애플리케이션의 출력형태에 따른 데이타를 정리할 수 있다. 사실 이것이 가장 중요하다. 앞에서도 설명했듯이, NoSQL의 데이타 모델링은 도메인 모델을 중심으로 하는 것이 아니라, 이 애플리케이션의 데이타 출력 내용을 기반으로 하기 때문이다.

3.     패턴을 이용한 데이타 모델링

애플리케이션 데이타 출력 내용을 디자인 했으면, 이제 이 내용을 가지고 NoSQL에 정의될 데이타 모델링을 들어간다. NoSQL은 Sorting,Grouping,Join 등의 RDBMS 기능을 제공하지 않기 때문에 이를 배제하고 Put/Get으로만 데이타를 가지고 올 수 있는 형태로 데이타 모델 즉 NoSQL내의 테이블을 재 정의 해야 한다.

이 데이타 모델링을 돕기위해서 다음 챕터에서는 NoSQL 데이타 모델링 기법을 다시 설명한다. 이 때 가장 중요한것은 Demoralization이다. 데이타를 가급적 중복으로 저장하여, 한번에 데이타를 읽어오는 횟수를 줄이도록 한다. (이 IO자체가 엄청난 부담이기 때문에)

위의 블로깅 시스템 데이타를 일반적인 NoSQL 스타일로 바꾸면 다음과 같다.

특히 Key 부분을 주목해 볼 필요가 있는데, Join을 없애기 위해서, 아예 userID나 postID를 “:”로 구분되는 deliminator로 하여 Key에 포함시켜 버렸다. 이는 Join을 없애는 것 이외에 다른 이유가 또 있는데, Ordered Key/Value Store의 경우에는 Key를 기반으로 소팅을 하기 때문에 첫번째, 포스트 ID를 Sequential하게 증가 시켜 나가면, 같은 사용자의 글의 경우에는 Sorting 이 가능하다. 두번째, Grouping인데, 포스팅을 출력하는 사용자에 대해서 posting을 쭈욱 출력해 나가면, 순차적으로 Post가 출력이 되다가, 해당 사용자의 포스팅 데이타가 끝이나면, Key의 맨앞 userID가 다른 사용자id로 바뀌기 때문에 where문장이 없이도, 특정 사용자의 포스팅을 순차적으로 출력할 수 있다. 뒤에서 설명한 데이타 모델링 패턴에서 Enumerable Key와 Composite Key Index 패턴을 참고하기 바란다.

4.     최적화를 위한 필요한 기능들을 리스팅

자아 이제 약간은 NoSQL스럽게 디자인이 되었다. 이제는 NoSQL의 특성을 반영하여, 조금 더 디테일한 디자인을 할 수 있다. 다시 애플리케이션 및 데이타의 특성을 다시 한번 들여다 보자

첨부 파일 (Attachment) 파일의 경우에는 포스팅이 작성되었을 때 레코드가 추가되며, 변경이 거의 없다. 그리고 첨부파일의 수는 그리 많지 않기 때문에, 하나의 필드에 모두 몰아서 저장할 수 있다. 이렇게 하나의 필드에 여러개의 데이타를 저장할 경우에는 Document Store를 고려해 볼 수 있다.

그리고 앞에서도 언급했지만 블로그 포스트,첨부파일,댓글은 소팅이 되어야 하기 때문에, Ordered Key 형태가 필요하다.

현재 데이타 모델은 포스팅이 포스트된 순서대로만 출력하는 형태인데, 분류 개념이 있기 때문에, 분류에 따라서 포스팅을 출력하려면 분류 필드가 별도 필드로 들어가야 하고, 이 필드에 따라 where문으로 select할 수 있는 기능이 있어야 한다. 마치 RDBMS의 Index같은 개념이 필요한데, 이러한 기능을 NoSQL에서는 Secondary Index라고 한다.

이런 옵션등을 적용해보면 Posting 테이블은 위와 같이 변경해볼 수 있다.

여기서 고려해야 할점 하나를 짚고 넘어가자..!!

NoSQL 제품들은 KV, Ordered KV, Document Store등 데이타 모델로는 3가지 분류로 분리가 되긴 하지만, 세세한 내부 아키텍쳐나 기능들은 매우 다르다.  아주 자세하게는 아니더라도, 어떤 NoSQL 제품군이 있고, 대략적인 기능이 어떻게 되는지를 알아야, 이 정도 수준의 설계를 할 수 있다. 물론 이 단계까지 설계되더라도 아직까지 완벽하지 않다.

솔루션들이 스펙상에 “OOO 기능이 있다.” 하더라도, 그 기능이 제대로 돌아가는 건 아니다. Secondary Index의 경우 Cassandra나 Riak에서 지원은 하지만 실제 부하를 줘 가면서 테스트를 해보면 성능이 잘 안나오는 경우가 많고, 내부 구조상으로도 고성능을 내기가 어려운 구조이다. 그래서 이런 부가 기능들은 직접 내부 구조를 분석하고, 테스트를 해봐야 사용 가능 여부를 판단할 수 있다.

예전의 RDBMS야, 워낙 레퍼런스도 많고, 벤더 지원도 있기 때문에, 써야할, 쓰지 말아야할 기능이 명확하지만 NoSQL의 경우는 제품도 많을 뿐더라, 기술도 신기술이기 때문에 서적조차 드물다. 직접 분석하고 테스트해보는 방법 밖에 없다.

5.     후보 NoSQL을 선정 및 테스트

앞에서 언급한 바와 같이, 모델링한 데이타 구조를 효과적으로 실행할 수 있는 NoSQL을 찾아야 한다. 이는, NoSQL에 대한 구조 및 특성 분석 후에, 실제로 부하 테스트, 안정성, 확장성 테스트를 거친 후에, 가장 적절한 솔루션을 선택해야 한다.

경우에 따라서는 하나의 NoSQL이 아니라, 여러개의 NoSQL을 복합해서 사용할 경우도 있다. 트위터나,페이스북같은 대규모 서비스들은 하나의 NoSQL만을 사용하지 않고 데이타의 성격과 업무의 목적에 맞는 다수의 NoSQL을 선정하여 사용한다.

6.     데이타 모델을 선정된 NoSQL에 최적화 및 하드웨어 디자인

마지막으로 선정된 NoSQL을 기반으로 다시 데이타 모델을 최적화 하고, 이에 맞는 애플리케이션 인터페이스 설계와 하드웨어에 대한 디자인을 진행해야 한다.

지금까지 간단하게나마 NoSQL의 데이타 모델링 절차에 대해서 알아보았다. 다시 한번 강조하지만 NoSQL의 데이타 모델링 방식은 RDBMS가 데이타 자체의 관계를 중요시 하고, 데이타에서부터 출발한다면, NoSQL은 애플리케이션이 출력하고자 하는 데이타 출력 내용에 따라서 데이터 모델링이 완성된다. RDBMS와 역순으로 진행되어야 하고, 데이타 중심이 아니라, 애플리케이션 중심으로 모델링을 진행해야 한다.

그리고 NoSQL은 신 기술 분야이면서 오픈 소스 진영이 주를 이르고 있기 때문에, 기술 지원을 받기가 매우 어렵다. 물론 외국에는 NoSQL에 대해서 유상으로 기술 지원을 해주는 업체들이 있기는 한데, (Cassandra의 경우 DataStax가 기술 지원을 하고, Riak은 Basho, MongoDB는 10gen 등이 기술 지원을 한다.). 국내 실정상 외국엔지니어를 불러다가 기술 지원을 받기도 힘들뿐더러, 기술 지원 회사의 규모가 작기 때문에 숙력된 엔지니어를 필요할때 마다 부르기도 어렵다.

그리고, Amazon등에서 검색해보면 알겠지만, NoSQL에 대한 서적도 그리 많지 않은 편이기 때문에 공부하기도 어렵다. 해외에서 이러한 NoSQL류를 쓰는 업체들은 스스로 내부 개발자들을 역량을 키워서 공부하고, 테스트해서 내재화된 기술을 기반으로 NoSQL을 운용하기 때문에, 단순하게 솔루션 도입 관점에서만 볼 것이 아니라, 기술 내재화 관점에서도 NoSQL 도입을 고려해야 한다.

다음글에서는 NoSQL의 데이타 모델링을 하기 위한 일반적은 데이타 모델링 패턴에 대해서 소개하기로 한다.